Re: IBM / SUSE Issues udev name change

2017-01-04 Thread Waite, Dick (External) 
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

2017-01-03 Thread Mark Post 
>>> 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

2016-12-30 Thread Waite, Dick (External) 
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

2016-12-29 Thread Waite, Dick (External) 
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  *