Re: DASD assignment different between SLES10 and SLES11

2011-09-30 Thread Peter E. Abresch Jr. - at Pepco
Added ?dasd_mod.dasd=0.0.150-0.0.15f? to the zipl.conf and ran zipl. These 
caused massive I/O errors and I had to back out. I analyzed this problem 
further and realized that I had two virtual DASD addresses mapped to this 
z/VM guest, leftover from a previous Reiserfs to EXT3 conversion. I had 
taken them off with the dasd_configure command months previouz. In other 
words, these I/O errors were ok and made now made sense. I updated the 
z/VM guest?s configuration and removed these DASD devices. I then added 
updated zipl.conf as follows:

[ipl]
image = /boot/image
target = /boot/zipl
ramdisk = /boot/initrd,0x200
parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 
dasd_mod.dasd=0.0.0150-0.0.015f TERM=dumb

I ran zipl and rebooted. Now everything is in its normal predictable slot 
as follows:

linuxm02:~ lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   2347MB600840
0.0.0151   active  dasdb 94:4ECKD  4096   2347MB600840
0.0.0152   active  dasdc 94:8ECKD  4096   2347MB600840
0.0.0153   active  dasdd 94:12   ECKD  4096   2347MB600840
0.0.0154   active  dasde 94:16   ECKD  4096   2347MB600840
0.0.015f   active  dasdp 94:60   ECKD  4096   589MB 150840

Thanks to everyone that responded. Enjoy your weekend.

Peter



From:   Ronald van der Laan nl50...@gmail.com
To: LINUX-390@vm.marist.edu
Date:   09/29/2011 04:26 PM
Subject:Re: DASD assignment different between SLES10 and SLES11
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



Peter,

Have you tried:
parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1
dasd=0.0.0150-0.0.015f TERM=dumb

Ronald van der Laan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates (PHI).  This Email is
intended solely for the use of the person(s) to which it is addressed.  If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited.  If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies.  PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication.  PHI will not accept any liability in respect of such
communications.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Peter E. Abresch Jr. - at Pepco
Under SLES10, we see the following:

0.0.0150(ECKD) at ( 94:  0) is dasda  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0151(ECKD) at ( 94:  4) is dasdb  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0152(ECKD) at ( 94:  8) is dasdc  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0153(ECKD) at ( 94: 12) is dasdd  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0154(ECKD) at ( 94: 16) is dasde  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.015f(ECKD) at ( 94: 60) is dasdp  : active at blocksize 4096,
150840 blocks, 589 MB

Notice that 0.0.015f is dasdp


Under SLES11, we see the following:

Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   2347MB600840
0.0.0151   active  dasdb 94:4ECKD  4096   2347MB600840
0.0.0152   active  dasdc 94:8ECKD  4096   2347MB600840
0.0.0155   active  dasdd 94:12   ECKD  4096   2347MB600840
0.0.0156   active  dasde 94:16   ECKD  4096   2347MB600840
0.0.015f   active  dasdf 94:20   ECKD  4096   589MB 150840

Notice that 0.0.015f is dasdf rather than dasdp. How can I insure that
0.0.015f is always dasdp?

I read that this behavior had change but naturally now that I need this
doc, I cannot find it anywhere. I do not remember where I read it. E.

Can anyone point me in the right direction? Thanks as always.

Peter

This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates (PHI).  This Email is
intended solely for the use of the person(s) to which it is addressed.  If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited.  If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies.  PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication.  PHI will not accept any liability in respect of such
communications.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Christian Paro
Is this for a program or fstab entry which is expecting that disk to always
appear at /dev/dasdp?

Because if you can edit your source, it would be safer to refer to your
disks by path (such as /dev/disk/by-path/ccw-0.0.0154) rather than by their
dasd[a-z][a-z]* names. The path will always correspond to the underlying
virtual device number, while the by-letter names are dependent on the order
in which they happen to be brought online.

Also, if you need to find the associated dasd* name for a disk whose vdev
you know, you can use the following:

readlink -f /dev/disk/by-path/ccw-0.0.${vdev}

...like this:

myhostname:/etc/udev/rules.d # readlink -f /dev/disk/by-path/ccw-0.0.0100
/dev/dasda

On Thu, Sep 29, 2011 at 10:59 AM, Peter E. Abresch Jr. - at Pepco 
peabre...@pepco.com wrote:

 Under SLES10, we see the following:

 0.0.0150(ECKD) at ( 94:  0) is dasda  : active at blocksize 4096,
 600840 blocks, 2347 MB
 0.0.0151(ECKD) at ( 94:  4) is dasdb  : active at blocksize 4096,
 600840 blocks, 2347 MB
 0.0.0152(ECKD) at ( 94:  8) is dasdc  : active at blocksize 4096,
 600840 blocks, 2347 MB
 0.0.0153(ECKD) at ( 94: 12) is dasdd  : active at blocksize 4096,
 600840 blocks, 2347 MB
 0.0.0154(ECKD) at ( 94: 16) is dasde  : active at blocksize 4096,
 600840 blocks, 2347 MB
 0.0.015f(ECKD) at ( 94: 60) is dasdp  : active at blocksize 4096,
 150840 blocks, 589 MB

 Notice that 0.0.015f is dasdp


 Under SLES11, we see the following:

 Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks

 ==
 0.0.0150   active  dasda 94:0ECKD  4096   2347MB600840
 0.0.0151   active  dasdb 94:4ECKD  4096   2347MB600840
 0.0.0152   active  dasdc 94:8ECKD  4096   2347MB600840
 0.0.0155   active  dasdd 94:12   ECKD  4096   2347MB600840
 0.0.0156   active  dasde 94:16   ECKD  4096   2347MB600840
 0.0.015f   active  dasdf 94:20   ECKD  4096   589MB 150840

 Notice that 0.0.015f is dasdf rather than dasdp. How can I insure that
 0.0.015f is always dasdp?

 I read that this behavior had change but naturally now that I need this
 doc, I cannot find it anywhere. I do not remember where I read it. E.

 Can anyone point me in the right direction? Thanks as always.

 Peter

 This Email message and any attachment may contain information that is
 proprietary, legally privileged, confidential and/or subject to copyright
 belonging to Pepco Holdings, Inc. or its affiliates (PHI).  This Email is
 intended solely for the use of the person(s) to which it is addressed.  If
 you are not an intended recipient, or the employee or agent responsible for
 delivery of this Email to the intended recipient(s), you are hereby
 notified
 that any dissemination, distribution or copying of this Email is strictly
 prohibited.  If you have received this message in error, please immediately
 notify the sender and permanently delete this Email and any copies.  PHI
 policies expressly prohibit employees from making defamatory or offensive
 statements and infringing any copyright or any other legal right by Email
 communication.  PHI will not accept any liability in respect of such
 communications.

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Ron Foster at Baldor-IS
Peter,

Actually we observed this behavior as far back as SLES10 SP3.  We started using 
persistent device names and forgot about it.

The documentation for this is in the release notes.  From the release notes: 

  Installation using Persistent Device names
If you plan to add additional storage devices to your system after the OS
installation, we strongly recommend to use persistent device names for all
storage devices during installation. The installer by default uses the
kernel device names.

There is additional information in the SLES11 device driver manual on the 
developerworks site.
From the Device Drivers, Features, and Commands manual
SC34-2595-01

(from page 35)
autodetect
causes the DASD device driver to allocate device names and the
corresponding minor numbers to all DASD devices and set them online
during the boot process. See “DASD naming scheme” on page 31 for the
naming scheme.
The device names are assigned in order of ascending subchannel numbers.
Auto-detection can yield confusing results if you change your I/O
configuration and reboot, or if you are running as a guest operating system
in VM because the devices might appear with different names and minor
numbers after rebooting.

What may have changed is how dasd= is specified and/or how it works.  It is 
different between the SLES10 and SLES11 manuals.

Ron Foster





From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E. Abresch 
Jr.   - at Pepco [peabre...@pepco.com]
Sent: Thursday, September 29, 2011 9:59 AM
To: LINUX-390@VM.MARIST.EDU
Subject: DASD assignment different between SLES10 and SLES11

Under SLES10, we see the following:

0.0.0150(ECKD) at ( 94:  0) is dasda  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0151(ECKD) at ( 94:  4) is dasdb  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0152(ECKD) at ( 94:  8) is dasdc  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0153(ECKD) at ( 94: 12) is dasdd  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0154(ECKD) at ( 94: 16) is dasde  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.015f(ECKD) at ( 94: 60) is dasdp  : active at blocksize 4096,
150840 blocks, 589 MB

Notice that 0.0.015f is dasdp


Under SLES11, we see the following:

Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   2347MB600840
0.0.0151   active  dasdb 94:4ECKD  4096   2347MB600840
0.0.0152   active  dasdc 94:8ECKD  4096   2347MB600840
0.0.0155   active  dasdd 94:12   ECKD  4096   2347MB600840
0.0.0156   active  dasde 94:16   ECKD  4096   2347MB600840
0.0.015f   active  dasdf 94:20   ECKD  4096   589MB 150840

Notice that 0.0.015f is dasdf rather than dasdp. How can I insure that
0.0.015f is always dasdp?

I read that this behavior had change but naturally now that I need this
doc, I cannot find it anywhere. I do not remember where I read it. E.

Can anyone point me in the right direction? Thanks as always.

Peter

This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates (PHI).  This Email is
intended solely for the use of the person(s) to which it is addressed.  If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited.  If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies.  PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication.  PHI will not accept any liability in respect of such
communications.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Peter E. Abresch Jr. - at Pepco
Yes, our root is always dasda and our swap is always dasdp. This is what 
our original automated Linux cloning process expects and we wish to not 
re-engineer our cloning process at this time.

Under SLES10, in /etc/zipl.conf we have the following:

parameters = root=/dev/dasda1 dasd=150-15f TERM=dumb

Under SLES11, in /etc/zipl.conf we have the following:

parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 TERM=dumb

I am thinking this is where I need to make my change, but my own memory is 
slow to swap back in for me to remember all of it.

But . . . 

readlink -f /dev/disk/by-path/ccw-0.0.$15F
reveals /dev/disk/by-path/ccw-0.0.5F  - it seems to strip the 1 from the 
15f.

In my SLES10 cloning script, where I have the following:

echo Creating DASD swap space on /dev/dasdp1
swapoff -a
echo Formatting DASD swap space on /dev/dasdp1
dasdfmt -vy -f /dev/dasdp -d cdl -l swap01 -b 4096
echo Partitioning DASD swap space on /dev/dasdp1
fdasd -l swap01 -a /dev/dasdp
echo Making DASD swap space on /dev/dasdp1
sleep 5
mkswap /dev/dasdp1
echo Activating DASD swap space on /dev/dasdp1
swapon -a
echo Verifying DASD swap space on /dev/dasdp1
swapon ?s

I can change in my SLES11 cloning script to:

echo Creating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapoff -a
echo Formatting DASD swap space on /dev/disk/by-path/ccw-0.0.5F
dasdfmt -vy -f /dev/disk/by-path/ccw-0.0.5F -d cdl -l swap01 -b 4096
echo Partitioning DASD swap space on /dev/disk/by-path/ccw-0.0.5F
fdasd -l swap01 -a /dev/disk/by-path/ccw-0.0.5F
echo Making DASD swap space on /dev/disk/by-path/ccw-0.0.5F
sleep 5
mkswap /dev/disk/by-path/ccw-0.0.5F
echo Activating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapon -a
echo Verifying DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapon ?s

Is this what I should do? I am hesitant as there might me other scripted 
mounts that do /dev/dasdx# . Should I eat the bullet now or defer?



Peter



From:   Ron Foster at Baldor-IS rfos...@baldor.com
To: LINUX-390@vm.marist.edu
Date:   09/29/2011 11:38 AM
Subject:Re: DASD assignment different between SLES10 and SLES11
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



Peter,

Actually we observed this behavior as far back as SLES10 SP3.  We started 
using persistent device names and forgot about it.

The documentation for this is in the release notes.  From the release 
notes: 

  Installation using Persistent Device names
If you plan to add additional storage devices to your system after the 
OS
installation, we strongly recommend to use persistent device names for 
all
storage devices during installation. The installer by default uses the
kernel device names.

There is additional information in the SLES11 device driver manual on the 
developerworks site.
From the Device Drivers, Features, and Commands manual
SC34-2595-01

(from page 35)
autodetect
causes the DASD device driver to allocate device names and the
corresponding minor numbers to all DASD devices and set them online
during the boot process. See ?DASD naming scheme? on page 31 for the
naming scheme.
The device names are assigned in order of ascending subchannel numbers.
Auto-detection can yield confusing results if you change your I/O
configuration and reboot, or if you are running as a guest operating 
system
in VM because the devices might appear with different names and minor
numbers after rebooting.

What may have changed is how dasd= is specified and/or how it works.  It 
is different between the SLES10 and SLES11 manuals.

Ron Foster





From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E. 
Abresch Jr.   - at Pepco [peabre...@pepco.com]
Sent: Thursday, September 29, 2011 9:59 AM
To: LINUX-390@VM.MARIST.EDU
Subject: DASD assignment different between SLES10 and SLES11

Under SLES10, we see the following:

0.0.0150(ECKD) at ( 94:  0) is dasda  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0151(ECKD) at ( 94:  4) is dasdb  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0152(ECKD) at ( 94:  8) is dasdc  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0153(ECKD) at ( 94: 12) is dasdd  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0154(ECKD) at ( 94: 16) is dasde  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.015f(ECKD) at ( 94: 60) is dasdp  : active at blocksize 4096,
150840 blocks, 589 MB

Notice that 0.0.015f is dasdp


Under SLES11, we see the following:

Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   2347MB600840
0.0.0151   active  dasdb 94:4ECKD  4096   2347MB600840
0.0.0152   active  dasdc 94:8ECKD  4096   2347MB600840
0.0.0155   active  dasdd 94:12   ECKD  4096   2347MB600840
0.0.0156   active  dasde 94:16   ECKD

Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Ron Foster at Baldor-IS
Peter,
We do not have SLES11, but from the manual, on page 21 (Module parameters on 
the kernel parameter line),  it appears that the appropriate format of the 
dasd= parameter might be:

dasd_mod.dasd=0.0.150-0.0.15f

so your parameter line would be:

parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 
dasd_mod.dasd=0.0.150-0.0.15f
 TERM=dumb

Ron Foster



From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E. Abresch 
Jr.   - at Pepco [peabre...@pepco.com]
Sent: Thursday, September 29, 2011 11:09 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: DASD assignment different between SLES10 and SLES11

Yes, our root is always dasda and our swap is always dasdp. This is what
our original automated Linux cloning process expects and we wish to not
re-engineer our cloning process at this time.

Under SLES10, in /etc/zipl.conf we have the following:

parameters = root=/dev/dasda1 dasd=150-15f TERM=dumb

Under SLES11, in /etc/zipl.conf we have the following:

parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 TERM=dumb

I am thinking this is where I need to make my change, but my own memory is
slow to swap back in for me to remember all of it.

But . . .

readlink -f /dev/disk/by-path/ccw-0.0.$15F
reveals /dev/disk/by-path/ccw-0.0.5F  - it seems to strip the 1 from the
15f.

In my SLES10 cloning script, where I have the following:

echo Creating DASD swap space on /dev/dasdp1
swapoff -a
echo Formatting DASD swap space on /dev/dasdp1
dasdfmt -vy -f /dev/dasdp -d cdl -l swap01 -b 4096
echo Partitioning DASD swap space on /dev/dasdp1
fdasd -l swap01 -a /dev/dasdp
echo Making DASD swap space on /dev/dasdp1
sleep 5
mkswap /dev/dasdp1
echo Activating DASD swap space on /dev/dasdp1
swapon -a
echo Verifying DASD swap space on /dev/dasdp1
swapon ?s

I can change in my SLES11 cloning script to:

echo Creating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapoff -a
echo Formatting DASD swap space on /dev/disk/by-path/ccw-0.0.5F
dasdfmt -vy -f /dev/disk/by-path/ccw-0.0.5F -d cdl -l swap01 -b 4096
echo Partitioning DASD swap space on /dev/disk/by-path/ccw-0.0.5F
fdasd -l swap01 -a /dev/disk/by-path/ccw-0.0.5F
echo Making DASD swap space on /dev/disk/by-path/ccw-0.0.5F
sleep 5
mkswap /dev/disk/by-path/ccw-0.0.5F
echo Activating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapon -a
echo Verifying DASD swap space on /dev/disk/by-path/ccw-0.0.5F
swapon ?s

Is this what I should do? I am hesitant as there might me other scripted
mounts that do /dev/dasdx# . Should I eat the bullet now or defer?



Peter



From:   Ron Foster at Baldor-IS rfos...@baldor.com
To: LINUX-390@vm.marist.edu
Date:   09/29/2011 11:38 AM
Subject:Re: DASD assignment different between SLES10 and SLES11
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



Peter,

Actually we observed this behavior as far back as SLES10 SP3.  We started
using persistent device names and forgot about it.

The documentation for this is in the release notes.  From the release
notes:

  Installation using Persistent Device names
If you plan to add additional storage devices to your system after the
OS
installation, we strongly recommend to use persistent device names for
all
storage devices during installation. The installer by default uses the
kernel device names.

There is additional information in the SLES11 device driver manual on the
developerworks site.
From the Device Drivers, Features, and Commands manual
SC34-2595-01

(from page 35)
autodetect
causes the DASD device driver to allocate device names and the
corresponding minor numbers to all DASD devices and set them online
during the boot process. See ?DASD naming scheme? on page 31 for the
naming scheme.
The device names are assigned in order of ascending subchannel numbers.
Auto-detection can yield confusing results if you change your I/O
configuration and reboot, or if you are running as a guest operating
system
in VM because the devices might appear with different names and minor
numbers after rebooting.

What may have changed is how dasd= is specified and/or how it works.  It
is different between the SLES10 and SLES11 manuals.

Ron Foster





From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E.
Abresch Jr.   - at Pepco [peabre...@pepco.com]
Sent: Thursday, September 29, 2011 9:59 AM
To: LINUX-390@VM.MARIST.EDU
Subject: DASD assignment different between SLES10 and SLES11

Under SLES10, we see the following:

0.0.0150(ECKD) at ( 94:  0) is dasda  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0151(ECKD) at ( 94:  4) is dasdb  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0152(ECKD) at ( 94:  8) is dasdc  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0153(ECKD) at ( 94: 12) is dasdd  : active at blocksize 4096,
600840 blocks, 2347 MB
0.0.0154(ECKD) at ( 94: 16) is dasde  : active at blocksize 4096,
600840 blocks, 2347

Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Christian Paro
On the readlink example, the $ indicates a variable. So in a script you
could set vdev='015f' and then reference that value as ${vdev}. Or you could
just hard code in the 015f.

...also note that the by-path disk nodes always zero-pad the beginning of a
virtual device number, so it'll be four characters in length.

It's stripping out the 1 in $15f because it's assuming you mean $1 as a
variable, and (since you never initialized a $1 or passed it in as an
argument/parameter) interpreting it as an empty string.

If your script is always dealing with the same virtual device numbers,
though, and not dealing with something that *has* to use the dasd* format,
you may as well just hard-code the by-path name of the disk.

You can find other mounts by /dev/dasd* in your scripts by running a grep
through them, if that's a concern. Unlike network interfaces (which have a
configurable persistent mapping in
/etc/udev/rules.d/70-persistent-net.rules), there is not any way I'm aware
of to force the assignment of a virtual disk to a particular letter in the
/dev/dasd* scheme. Those assignments happen to usually remain stable - but,
as you've seen, they can change if something changes the order in which they
are brought on line.

On Thu, Sep 29, 2011 at 12:59 PM, Ron Foster at Baldor-IS 
rfos...@baldor.com wrote:

 Peter,
 We do not have SLES11, but from the manual, on page 21 (Module parameters
 on the kernel parameter line),  it appears that the appropriate format of
 the dasd= parameter might be:

 dasd_mod.dasd=0.0.150-0.0.15f

 so your parameter line would be:

 parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1
 dasd_mod.dasd=0.0.150-0.0.15f
  TERM=dumb

 Ron Foster


 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E.
 Abresch Jr.   - at Pepco [peabre...@pepco.com]
 Sent: Thursday, September 29, 2011 11:09 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: DASD assignment different between SLES10 and SLES11

 Yes, our root is always dasda and our swap is always dasdp. This is what
 our original automated Linux cloning process expects and we wish to not
 re-engineer our cloning process at this time.

 Under SLES10, in /etc/zipl.conf we have the following:

 parameters = root=/dev/dasda1 dasd=150-15f TERM=dumb

 Under SLES11, in /etc/zipl.conf we have the following:

 parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 TERM=dumb

 I am thinking this is where I need to make my change, but my own memory is
 slow to swap back in for me to remember all of it.

 But . . .

 readlink -f /dev/disk/by-path/ccw-0.0.$15F
 reveals /dev/disk/by-path/ccw-0.0.5F  - it seems to strip the 1 from the
 15f.

 In my SLES10 cloning script, where I have the following:

 echo Creating DASD swap space on /dev/dasdp1
 swapoff -a
 echo Formatting DASD swap space on /dev/dasdp1
 dasdfmt -vy -f /dev/dasdp -d cdl -l swap01 -b 4096
 echo Partitioning DASD swap space on /dev/dasdp1
 fdasd -l swap01 -a /dev/dasdp
 echo Making DASD swap space on /dev/dasdp1
 sleep 5
 mkswap /dev/dasdp1
 echo Activating DASD swap space on /dev/dasdp1
 swapon -a
 echo Verifying DASD swap space on /dev/dasdp1
 swapon ?s

 I can change in my SLES11 cloning script to:

 echo Creating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapoff -a
 echo Formatting DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 dasdfmt -vy -f /dev/disk/by-path/ccw-0.0.5F -d cdl -l swap01 -b 4096
 echo Partitioning DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 fdasd -l swap01 -a /dev/disk/by-path/ccw-0.0.5F
 echo Making DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 sleep 5
 mkswap /dev/disk/by-path/ccw-0.0.5F
 echo Activating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapon -a
 echo Verifying DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapon ?s

 Is this what I should do? I am hesitant as there might me other scripted
 mounts that do /dev/dasdx# . Should I eat the bullet now or defer?



 Peter



 From:   Ron Foster at Baldor-IS rfos...@baldor.com
 To: LINUX-390@vm.marist.edu
 Date:   09/29/2011 11:38 AM
 Subject:Re: DASD assignment different between SLES10 and SLES11
 Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



 Peter,

 Actually we observed this behavior as far back as SLES10 SP3.  We started
 using persistent device names and forgot about it.

 The documentation for this is in the release notes.  From the release
 notes:

  Installation using Persistent Device names
If you plan to add additional storage devices to your system after the
 OS
installation, we strongly recommend to use persistent device names for
 all
storage devices during installation. The installer by default uses the
kernel device names.

 There is additional information in the SLES11 device driver manual on the
 developerworks site.
 From the Device Drivers, Features, and Commands manual
 SC34-2595-01

 (from page 35)
 autodetect
 causes the DASD device driver to allocate device names

Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Peter E. Abresch Jr. - at Pepco
Wow, you have to get that command just right:

linuxm02:~ readlink -f /dev/disk/by-path/ccw-0.0.15f
/dev/disk/by-path/ccw-0.0.15f
linuxm02:~ readlink -f /dev/disk/by-path/ccw-0.0.15F
/dev/disk/by-path/ccw-0.0.15F
linuxm02:~ readlink -f /dev/disk/by-path/ccw-0.0.Peter
/dev/disk/by-path/ccw-0.0.Peter
linuxm02:~ readlink -f /dev/disk/by-path/ccw-0.0.015f
/dev/dasdf

I am going to do some more analysis.

I also added the following to the zipl.conf:

parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1
dasd_mod.dasd=0.0.150-0.0.15f
 TERM=dumb

and ran a zipl but that generated pages of pages of errors during boot. I
will have to look into that a little deeper as well.

Coding the device path in the cloning script generated other errors.
Again, more analysis on my part.

Peter



From:   Christian Paro christian.p...@gmail.com
To: LINUX-390@vm.marist.edu
Date:   09/29/2011 01:23 PM
Subject:Re: DASD assignment different between SLES10 and SLES11
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



On the readlink example, the $ indicates a variable. So in a script you
could set vdev='015f' and then reference that value as ${vdev}. Or you
could
just hard code in the 015f.

...also note that the by-path disk nodes always zero-pad the beginning of
a
virtual device number, so it'll be four characters in length.

It's stripping out the 1 in $15f because it's assuming you mean $1 as
a
variable, and (since you never initialized a $1 or passed it in as an
argument/parameter) interpreting it as an empty string.

If your script is always dealing with the same virtual device numbers,
though, and not dealing with something that *has* to use the dasd* format,
you may as well just hard-code the by-path name of the disk.

You can find other mounts by /dev/dasd* in your scripts by running a grep
through them, if that's a concern. Unlike network interfaces (which have a
configurable persistent mapping in
/etc/udev/rules.d/70-persistent-net.rules), there is not any way I'm aware
of to force the assignment of a virtual disk to a particular letter in
the
/dev/dasd* scheme. Those assignments happen to usually remain stable -
but,
as you've seen, they can change if something changes the order in which
they
are brought on line.

On Thu, Sep 29, 2011 at 12:59 PM, Ron Foster at Baldor-IS 
rfos...@baldor.com wrote:

 Peter,
 We do not have SLES11, but from the manual, on page 21 (Module
parameters
 on the kernel parameter line),  it appears that the appropriate format
of
 the dasd= parameter might be:

 dasd_mod.dasd=0.0.150-0.0.15f

 so your parameter line would be:

 parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1
 dasd_mod.dasd=0.0.150-0.0.15f
  TERM=dumb

 Ron Foster


 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Peter E.
 Abresch Jr.   - at Pepco [peabre...@pepco.com]
 Sent: Thursday, September 29, 2011 11:09 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: DASD assignment different between SLES10 and SLES11

 Yes, our root is always dasda and our swap is always dasdp. This is what
 our original automated Linux cloning process expects and we wish to not
 re-engineer our cloning process at this time.

 Under SLES10, in /etc/zipl.conf we have the following:

 parameters = root=/dev/dasda1 dasd=150-15f TERM=dumb

 Under SLES11, in /etc/zipl.conf we have the following:

 parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1 TERM=dumb

 I am thinking this is where I need to make my change, but my own memory
is
 slow to swap back in for me to remember all of it.

 But . . .

 readlink -f /dev/disk/by-path/ccw-0.0.$15F
 reveals /dev/disk/by-path/ccw-0.0.5F  - it seems to strip the 1 from the
 15f.

 In my SLES10 cloning script, where I have the following:

 echo Creating DASD swap space on /dev/dasdp1
 swapoff -a
 echo Formatting DASD swap space on /dev/dasdp1
 dasdfmt -vy -f /dev/dasdp -d cdl -l swap01 -b 4096
 echo Partitioning DASD swap space on /dev/dasdp1
 fdasd -l swap01 -a /dev/dasdp
 echo Making DASD swap space on /dev/dasdp1
 sleep 5
 mkswap /dev/dasdp1
 echo Activating DASD swap space on /dev/dasdp1
 swapon -a
 echo Verifying DASD swap space on /dev/dasdp1
 swapon ?s

 I can change in my SLES11 cloning script to:

 echo Creating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapoff -a
 echo Formatting DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 dasdfmt -vy -f /dev/disk/by-path/ccw-0.0.5F -d cdl -l swap01 -b 4096
 echo Partitioning DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 fdasd -l swap01 -a /dev/disk/by-path/ccw-0.0.5F
 echo Making DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 sleep 5
 mkswap /dev/disk/by-path/ccw-0.0.5F
 echo Activating DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapon -a
 echo Verifying DASD swap space on /dev/disk/by-path/ccw-0.0.5F
 swapon ?s

 Is this what I should do? I am hesitant as there might me other scripted
 mounts that do /dev/dasdx# . Should I eat the bullet now or defer?



 Peter

Re: DASD assignment different between SLES10 and SLES11

2011-09-29 Thread Ronald van der Laan
Peter,

Have you tried:
parameters = root=/dev/disk/by-path/ccw-0.0.0150-part1
dasd=0.0.0150-0.0.015f TERM=dumb

Ronald van der Laan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/