Absolutely agree with that! There is also what I consider a bug in SLES 9 - if the address ends in a A-F as opposed to a 0-9, the "p" is left off. We've coded around it where needed. (See 900A-900F below).
[EMAIL PROTECTED]:/dev/disk/by-path> uname -a Linux zlinivs1 2.6.5-7.311-s390x #1 SMP Mon Mar 10 13:12:16 UTC 2008 s390x s390x s390x GNU/Linux [EMAIL PROTECTED]:/dev/disk/by-path> cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (s390x) VERSION = 9 PATCHLEVEL = 4 [EMAIL PROTECTED]:/dev/disk/by-path> ls -al total 8 drwxr-xr-x 2 root root 4096 May 25 02:07 . drwxr-xr-x 4 root root 4096 May 25 02:07 .. lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0100 -> ../../dasda lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0100p1 -> ../../dasda1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0101 -> ../../dasdb lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0101p1 -> ../../dasdb1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0102 -> ../../dasdc lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0102p1 -> ../../dasdc1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0103 -> ../../dasdd lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0103p1 -> ../../dasdd1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0104 -> ../../dasde lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0104p1 -> ../../dasde1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.0105 -> ../../dasdf lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.0105p1 -> ../../dasdf1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.8001 -> ../../dasdg lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.8001p1 -> ../../dasdg1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.8002 -> ../../dasdh lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.8002p1 -> ../../dasdh1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.8003 -> ../../dasdi lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.8003p1 -> ../../dasdi1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9000 -> ../../dasdn lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9000p1 -> ../../dasdn1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9001 -> ../../dasdo lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9001p1 -> ../../dasdo1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9002 -> ../../dasdp lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9002p1 -> ../../dasdp1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9003 -> ../../dasdq lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9003p1 -> ../../dasdq1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9004 -> ../../dasdr lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9004p1 -> ../../dasdr1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9005 -> ../../dasds lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9005p1 -> ../../dasds1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9006 -> ../../dasdt lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9006p1 -> ../../dasdt1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9007 -> ../../dasdu lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9007p1 -> ../../dasdu1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.9009 -> ../../dasdv lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9009p1 -> ../../dasdv1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.900a -> ../../dasdw lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900a1 -> ../../dasdw1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.900b -> ../../dasdx lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900b1 -> ../../dasdx1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.900c -> ../../dasdy lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900c1 -> ../../dasdy1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.900d -> ../../dasdz lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900d1 -> ../../dasdz1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900e -> ../../dasdaa lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.900e1 -> ../../dasdaa1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.900f -> ../../dasdab lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.900f1 -> ../../dasdab1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9010 -> ../../dasdac lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.9010p1 -> ../../dasdac1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9011 -> ../../dasdad lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.9011p1 -> ../../dasdad1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9012 -> ../../dasdae lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.9012p1 -> ../../dasdae1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9013 -> ../../dasdaf lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.9013p1 -> ../../dasdaf1 lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.9014 -> ../../dasdag lrwxrwxrwx 1 root root 13 May 25 02:07 ccw-0.0.9014p1 -> ../../dasdag1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.ff00 -> ../../dasdj lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.ff00p1 -> ../../dasdj1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.ff01 -> ../../dasdk lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.ff01p1 -> ../../dasdk1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.ff02 -> ../../dasdl lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.ff02p1 -> ../../dasdl1 lrwxrwxrwx 1 root root 11 May 25 02:07 ccw-0.0.ff03 -> ../../dasdm lrwxrwxrwx 1 root root 12 May 25 02:07 ccw-0.0.ff03p1 -> ../../dasdm1 Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Tuesday, May 27, 2008 12:57 PM To: [email protected] Subject: Re: [LINUX-390] Sles9 to 10 upgrades and disk naming I've noticed that the naming of the devices is very inconsistent. Just within SuSE SLES 9, I see /dev/disk/by-path/ccw-0.0.07ffp1 and /dev/disk/by-path/ccw-0.0.07ff1. And as noted, this is different from SLES 10 which had /dev/disk/by-path/ccw-0.0.07ff-part1. Isn't the point of this to have predictable names for the devices? But if you can't predict what the predictable name will be, how is it any better than /dev/dasda and /dev/dasdb? On 5/27/08 2:13 PM, "Mark Post" <[EMAIL PROTECTED]> wrote: >>>> On Thu, May 22, 2008 at 10:14 PM, in message > <[EMAIL PROTECTED]>, > Marcy Cortes <[EMAIL PROTECTED]> wrote: >> We use /dev/disk/by-path >> >> names to label all of our disks on sles9 rather than the /dev/dasda.. >> In zipl.conf for the root= as well as in /etc/fstab. >> >> Now.. Sles10 has decided that instead of >> /dev/disk/by-path/ccw-0.0.0100p1 >> It will call the disk >> /dev/disk/by-path/ccw-0.0.0100-part1 >> >> So the upgrade process doesn't work. >> Is there a better way other than reverting back to /dev/dasda.. And >> then changing it backup again when we're doing upgrading? > > What exactly happens during the upgrade? I haven't tried this myself, > so I don't know. > > > Mark Post > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
