Re: IBM / SUSE Issues udev name change
Grand Day Mark, Yes the old names are still the "after" the ipl. But at ipl time "old name" are not there, don't know when they pop up. The SR is closed, one can work-a-round by switching to \dev\disk\by-id but if you have \dev\disk\by-path you do not get passed the re-boot ipl. Please have a try your voice behind this will give it a better push. This is using zypper migrate and you have a working SP-1 and you migrate to sp-2. As extra names that would be grand, if you could get the machine booted. Many thanks for the good words, it has taken a lot of words to SUSE to get a work-a-round but I hope the bug report will mean we do not have to amend machine from /by-path to /by-id the former being the better visual of what the device is. I did try hard during the Beta to get this looked at but __R From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Mark Post [mp...@suse.com] Sent: 03 January 2017 21:19 To: LINUX-390@VM.MARIST.EDU Subject: Re: IBM / SUSE Issues udev name change >>> On 12/30/2016 at 09:42 AM, "Waite, Dick (External)" >>> <dick.wa...@softwareag.com> wrote: > Grand Foggy Day in Darmstadt, > > I wanted to know who's bright idea it was to change between SP-1 and SP-2 I don't believe this is completely accurate. See below. > the format of the udev... This amend and "zypper migration" gives you a good > SP-2 but where is the /boot/zipl ? it's got a SP-1 udev interface so can not > be found and it's a real PITA to get your system back. -snip- > Now I'm all in favour of making better interfaces, but the old interface > should still work, at least between And that is how it should be with SLES12 SP2. > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/l > hdd_c_scsi_nodes.html > > An IBM paper that says: > > SCSI device names are assigned in the order in which the devices are > detected. In a typical SAN environment, this can mean a seemingly arbitrary > mapping of names to actual devices that can change between boots. Therefore, > using standard device nodes of the form /dev/ where > is > the device name that the SCSI stack assigns to a device, can be a challenge. > > SUSE Linux Enterprise Server 12 SP2 provides udev to create device nodes for > you. Use the device nodes to identify the corresponding actual device. > > Device nodes that are based on bus IDsEnd of changeStart of changeudev > creates device nodes of the form > > /dev/disk/by-path/ccw--fc--lun- > > for whole SCSI device and > > /dev/disk/by-path/ccw--fc--lun--part > > for the th partition, where is the worldwide port number of the > target > port and is the logical unit number that represents the target SCSI > device. > Note: The format of these udev-created device nodes has changed and now > matches the common code format. Device nodes of the prior form, > ccw--zfcp-: or > ccw--zfcp-:-part, > are no longer created. I see those names as _additional_ names, not replacements. One one of my test systems, I booted SP2 and see this: 0:s390vsl133:~ # ll /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001 -> ../../sda lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part3 -> ../../sdc3 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011 -> ../../sdd lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part2 -> ../../sdd2 lrwxrwxrwx 1 root root 9 Jan
Re: IBM / SUSE Issues udev name change
>>> On 12/30/2016 at 09:42 AM, "Waite, Dick (External)" >>>wrote: > Grand Foggy Day in Darmstadt, > > I wanted to know who's bright idea it was to change between SP-1 and SP-2 I don't believe this is completely accurate. See below. > the format of the udev... This amend and "zypper migration" gives you a good > SP-2 but where is the /boot/zipl ? it's got a SP-1 udev interface so can not > be found and it's a real PITA to get your system back. -snip- > Now I'm all in favour of making better interfaces, but the old interface > should still work, at least between And that is how it should be with SLES12 SP2. > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/l > hdd_c_scsi_nodes.html > > An IBM paper that says: > > SCSI device names are assigned in the order in which the devices are > detected. In a typical SAN environment, this can mean a seemingly arbitrary > mapping of names to actual devices that can change between boots. Therefore, > using standard device nodes of the form /dev/ where > is > the device name that the SCSI stack assigns to a device, can be a challenge. > > SUSE Linux Enterprise Server 12 SP2 provides udev to create device nodes for > you. Use the device nodes to identify the corresponding actual device. > > Device nodes that are based on bus IDsEnd of changeStart of changeudev > creates device nodes of the form > > /dev/disk/by-path/ccw--fc--lun- > > for whole SCSI device and > > /dev/disk/by-path/ccw--fc--lun--part > > for the th partition, where is the worldwide port number of the > target > port and is the logical unit number that represents the target SCSI > device. > Note: The format of these udev-created device nodes has changed and now > matches the common code format. Device nodes of the prior form, > ccw--zfcp-: or > ccw--zfcp-:-part, > are no longer created. I see those names as _additional_ names, not replacements. One one of my test systems, I booted SP2 and see this: 0:s390vsl133:~ # ll /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001 -> ../../sda lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40104001-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630500873a-lun-0x40114011-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40104001-part3 -> ../../sdc3 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011 -> ../../sdd lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-fc-0x500507630510473a-lun-0x40114011-part2 -> ../../sdd2 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001 -> ../../sda lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40104001-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011 -> ../../sdb lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630500873a:0x40114011-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 9 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001 -> ../../sdc lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Jan 3 20:11 ccw-0.0.fa00-zfcp-0x500507630510473a:0x40104001-part3 -> ../../sdc3 lrwxrwxrwx 1 root root 9 Jan 3 20:11
Re: IBM / SUSE Issues udev name change
Grand Foggy Day in Darmstadt, I wanted to know who's bright idea it was to change between SP-1 and SP-2 the format of the udev... This amend and "zypper migration" gives you a good SP-2 but where is the /boot/zipl ? it's got a SP-1 udev interface so can not be found and it's a real PITA to get your system back. IBM I thinks it's pints all round. From a company who's z/OS JCL from the 1970's still run you blow a hole in a SP update Makes one think, "how was this tested by IBM ?" not using standard end user tools like zypper migration that for sure. Now I'm all in favour of making better interfaces, but the old interface should still work, at least between SP's Maybe between SLES 12 and SLES 13 with a loud drum roll so that local folk know it's happening, but an interface change like this at SP time, Big Blue you should be ashamed... http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_c_scsi_nodes.html An IBM paper that says: SCSI device names are assigned in the order in which the devices are detected. In a typical SAN environment, this can mean a seemingly arbitrary mapping of names to actual devices that can change between boots. Therefore, using standard device nodes of the form /dev/ where is the device name that the SCSI stack assigns to a device, can be a challenge. SUSE Linux Enterprise Server 12 SP2 provides udev to create device nodes for you. Use the device nodes to identify the corresponding actual device. Device nodes that are based on bus IDsEnd of changeStart of changeudev creates device nodes of the form /dev/disk/by-path/ccw--fc--lun- for whole SCSI device and /dev/disk/by-path/ccw--fc--lun--part for the th partition, where is the worldwide port number of the target port and is the logical unit number that represents the target SCSI device. Note: The format of these udev-created device nodes has changed and now matches the common code format. Device nodes of the prior form, ccw--zfcp-: or ccw--zfcp-:-part, are no longer created. __R From: Waite, Dick (External) Sent: 29 December 2016 21:44 To: Linux on 390 Port Subject: RE: SUSE Issues udev name change For interest to good people migrating from SLES12 SP-1 to SP-2 I have looked at the Release Notes of SP-2 for key word "udev" and did not find any words. If you do not do one of the options below your migration runs grand until the new IPL and your boot disk is not there any more. Grand work by a West Coast SUSE support chap. OkI see what the problem is now. In SP1 udev named the devices in /dev/disk/by-path like this: fc15-zfcp-0x500507630413d46b:0x40eb4002-part1 In SP2 it's named like this: ccw-0.0.fc15-fc-0x500507630413d46b-lun-0x40eb4002-part1 There are 2 ways to fix this on your existing SP1 servers: 1. Since you are using scsi devices and not DASD you could use the /dev/disk/by-id device in the /etc/fstab instead of the /dev/disk/by-id So you would replace the /dev/disk/by-path/fc15-zfcp-0x500507630413d46b:0x40eb4002-part1with /dev/disk/by-id/scsi-36005076304ffd46beb02-part1 or 2. Before the update edit the /etc/fstab and change the name of the by-path device by replacing the ":" in the name with "-lun-" __R From: Waite, Dick (External) Sent: 23 December 2016 12:18 To: Linux on 390 Port Subject: RE: Goldimage Redhat 7.1 Good Morning, I have SR 101040685023 with SUSE, open against issues with /dev not there after, in my case, an update/migration from SP-1... but I understand from support it can occur under other circumstance. Seem you have found one of the circumstances... It's not just /dev/root this is missing, it's /dev I was told by support yesterday morning then have repro'ed the issue and are working on it... We have seen this with RHEL but not so often as with SUSE With SUSE and a LVM environment with /usr as part of "/" it can happen each time you migrate a SP-1 to SP-2. In our case a new install does work Okay, only update/migration has this missing /dev Have a grand day. __R From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Kumar [kumarsyste...@gmail.com] Sent: 23 December 2016 11:54 To: LINUX-390@VM.MARIST.EDU Subject: Re: Goldimage Redhat 7.1 I retried the installation and i didnt miss all messages this time *[ [32m OK [0m] Started Show Plymouth Boot Screen. * *[ [32m OK [0m] Reached target Paths. * *[ [32m OK [0m] Reached target Basic System. * * Starting Dracut Emergency Shell... * *dracut-initqueue[680]: Warning: Could not boot. * *dracut-initqueue[680]: Warning: /dev/root does not exist * *Warning: /dev/ro
Re: SUSE Issues udev name change
For interest to good people migrating from SLES12 SP-1 to SP-2 I have looked at the Release Notes of SP-2 for key word "udev" and did not find any words. If you do not do one of the options below your migration runs grand until the new IPL and your boot disk is not there any more. Grand work by a West Coast SUSE support chap. OkI see what the problem is now. In SP1 udev named the devices in /dev/disk/by-path like this: fc15-zfcp-0x500507630413d46b:0x40eb4002-part1 In SP2 it's named like this: ccw-0.0.fc15-fc-0x500507630413d46b-lun-0x40eb4002-part1 There are 2 ways to fix this on your existing SP1 servers: 1. Since you are using scsi devices and not DASD you could use the /dev/disk/by-id device in the /etc/fstab instead of the /dev/disk/by-id So you would replace the /dev/disk/by-path/fc15-zfcp-0x500507630413d46b:0x40eb4002-part1with /dev/disk/by-id/scsi-36005076304ffd46beb02-part1 or 2. Before the update edit the /etc/fstab and change the name of the by-path device by replacing the ":" in the name with "-lun-" __R From: Waite, Dick (External) Sent: 23 December 2016 12:18 To: Linux on 390 Port Subject: RE: Goldimage Redhat 7.1 Good Morning, I have SR 101040685023 with SUSE, open against issues with /dev not there after, in my case, an update/migration from SP-1... but I understand from support it can occur under other circumstance. Seem you have found one of the circumstances... It's not just /dev/root this is missing, it's /dev I was told by support yesterday morning then have repro'ed the issue and are working on it... We have seen this with RHEL but not so often as with SUSE With SUSE and a LVM environment with /usr as part of "/" it can happen each time you migrate a SP-1 to SP-2. In our case a new install does work Okay, only update/migration has this missing /dev Have a grand day. __R From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Kumar [kumarsyste...@gmail.com] Sent: 23 December 2016 11:54 To: LINUX-390@VM.MARIST.EDU Subject: Re: Goldimage Redhat 7.1 I retried the installation and i didnt miss all messages this time *[ [32m OK [0m] Started Show Plymouth Boot Screen. * *[ [32m OK [0m] Reached target Paths. * *[ [32m OK [0m] Reached target Basic System. * * Starting Dracut Emergency Shell... * *dracut-initqueue[680]: Warning: Could not boot. * *dracut-initqueue[680]: Warning: /dev/root does not exist * *Warning: /dev/root does not exist * *Generating "/run/initramfs/rdsosreport.txt" * *Entering emergency mode. Exit the shell to continue. * *Type "journalctl" to view system logs. * *You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot* *after mounting them and attach it to a bug report. * *dracut:/# * *dracut:/# journalctl * *journalctl * * [?1h = -- Logs begin at Fri 2016-12-23 10:39:14 UTC, end at Fri 2016-12-23 10:42:41 UTC [m * *Dec 23 10:39:14 localhost systemd-journal[63]: Runtime journal is using 6.1M (ma [m * *Dec 23 10:39:14 localhost systemd-journal[63]: Runtime journal is using 6.1M (ma [m * *Dec 23 10:39:14 localhost kernel: Initializing cgroup subsys cpuset [m * *Dec 23 10:39:14 localhost kernel: Initializing cgroup subsys cpu [m * *Dec 23 10:39:14 localhost kernel: Initializing cgroup subsys cpuacct [m * *Dec 23 10:39:14 localhost kernel: [1;39mLinux version 3.10.0-229.el7.s390x (mockbuild@ [m* *Dec 23 10:39:14 localhost kernel: setup: Linux is running as a z/VM guest operat [m * *Dec 23 10:39:14 localhost kernel: [1;39mZone ranges: [0m [m * *Dec 23 10:39:14 localhost kernel: [1;39m DMA [mem 0x-0x7fff] [0m [m* *Dec 23 10:39:14 localhost kernel: [1;39m Normal empty [0m [m * *Dec 23 10:39:14 localhost kernel: [1;39mMovable zone start for each node [0m [m * *Dec 23 10:39:14 localhost kernel: [1;39mEarly memory node ranges [0m [m * *Dec 23 10:39:14 localhost kernel: [1;39m node 0: [mem 0x-0x3fff] [0m [m * *Dec 23 10:39:14 localhost kernel: On node 0 totalpages: 262144 [m * *Dec 23 10:39:14 localhost kernel: DMA zone: 4096 pages used for memmap [m * *Dec 23 10:39:14 localhost kernel: DMA zone: 0 pages reserved [m * *Dec 23 10:39:14 localhost kernel: DMA zone: 262144 pages, LIFO batch:31 [m *