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 <
[email protected]> 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 [[email protected]] On Behalf Of Peter E.
> Abresch Jr.   - at Pepco [[email protected]]
> Sent: Thursday, September 29, 2011 11:09 AM
> To: [email protected]
> 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 <[email protected]>
> To:     [email protected]
> Date:   09/29/2011 11:38 AM
> Subject:        Re: DASD assignment different between SLES10 and SLES11
> Sent by:        Linux on 390 Port <[email protected]>
>
>
>
> 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 [[email protected]] On Behalf Of Peter E.
> Abresch Jr.   - at Pepco [[email protected]]
> Sent: Thursday, September 29, 2011 9:59 AM
> To: [email protected]
> 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:0    ECKD  4096   2347MB    600840
> 0.0.0151   active      dasdb     94:4    ECKD  4096   2347MB    600840
> 0.0.0152   active      dasdc     94:8    ECKD  4096   2347MB    600840
> 0.0.0155   active      dasdd     94:12   ECKD  4096   2347MB    600840
> 0.0.0156   active      dasde     94:16   ECKD  4096   2347MB    600840
> 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. Errrr.
>
> 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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/

Reply via email to