You know the by-path name before you ever create the Linux image. It will always be /dev/disk/by-path/ccw-0.0.CCUU.part1 (for SuSE SLES 10), where CCUU is the virtual address of the minidisk, if you're running as a z/VM guest, or the real CCUU of the device if you're running in an LPAR. (This also assumes that you've formatted the disk with a single partition.) This is the name that you have absolute control over, and will not change, as long as you do not change the virtual address of the minidisk, and there is absolutely no requirement to do that under normal circumstances. And, it is not dependant on the order in which the Linux image finds and brings the devices online, which is the problem the /dev/dasdxx names suffer from.
-- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 2/29/08 2:19 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Just wondering outloud. So in this environment (mainframe) there is no > reason to worry about whether the dasd come online at the same time since > they are already spinning and ready. I think I will stick to the > conventional naming /dev/dasdx unless otherwise corrected. Anyway, I don't > really know what the by-path name should be at this point, do I? I know > the by-id name! Just dont want to do another install since I have my image > pretty much where I want it. It would be nice if someone could summerize > the different conventions, differences between them, how they work at IPL > time, how cloning is impacted and especially how they should be used in a > mainframe environment. Thanks. > > > > > "Romanowski, John > (OFT)" > <John.Romanowski@ To > oft.state.ny.us> [email protected] > Sent by: The IBM cc > z/VM Operating > System Subject > <[EMAIL PROTECTED] Re: error bringing up cloned system > ARK.EDU> > > > 02/29/2008 02:11 > PM > > > Please respond to > The IBM z/VM > Operating System > <[EMAIL PROTECTED] > ARK.EDU> > > > > > > > I see your point, I was think of the other case where the filesystem is > on a mdisk and cloned copy's mdisk is on another pack. > I think each z/vm dasd pack has a unique hardware "id"; your cloned > copy's pack has an id different from its parent's id; if /etc/fstab > isn't adjusted after cloning to mount the copy's by-id value then the > server has trouble booting when it tries to mount using the parent's > by-id/ value. > > If by old naming conventions you mean /dev/dasda,b,c,.. they're not > persistent/consistent device names unless you can guarantee the same set > of disk addresses come online in the same order. I'm not knocking 'em; > I use 'em. > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Friday, February 29, 2008 1:33 PM > To: [email protected] > Subject: Re: error bringing up cloned system > > Managled is understated. If it said partitions instead of disks it might > make more sense to me. But in my case, I have only one volume/dasd/disk > with 1 boot partition and 1 logical volume partition. So when you bring > a > cloned volume/dasd/disk online he must compare the NEW "real addr" to > the > by-id label. But, if use by-path he doesn't? Sorry still a little > confused > about this. What is wrong with old naming conventions? > > > > > > > "Romanowski, John > > (OFT)" > > <John.Romanowski@ > To > oft.state.ny.us> [email protected] > > Sent by: The IBM > cc > z/VM Operating > > System > Subject > <[EMAIL PROTECTED] Re: error bringing up cloned > system > ARK.EDU> > > > > > > 02/29/2008 11:53 > > AM > > > > > > Please respond to > > The IBM z/VM > > Operating System > > <[EMAIL PROTECTED] > > ARK.EDU> > > > > > > > > > > Novell's sles 10 sp1 release notes actually give a mangled attempt to > alert one to this z/VM mdisk issue. > When they ran the original text thru the translator to English it must > have substituted 'disk' for the non-dictionary 'mdisk' words in these > sentences: > > "Using Disks in z/VM > If SLES 10 is installed on disks in z/VM, which reside on the same > physical disk, the created access path (/dev/disk/by-id/) is not unique. > The ID of a disk is the ID of the underlaying disk. So if two or more > disk are on the same physical disk, they all have the same ID. > > To avoid this ambiguity, please use the access path by-path. This can be > specified during the installation when the mount points are definied. > > To change from by-id to by-path please perform the following steps: > > > Modify /etc/zipl.conf to use by-path names, example: > parameters = "root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb" > Have the boot configuration pick up the changes: > mkinitrd > zipl -V > Change all by-id entries in /etc/fstab to by-path entries as well, > example: > /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 > reboot to pick up changes" > > > > > -------------------------------------------------------- > This e-mail, including any attachments, may be confidential, privileged > or > otherwise legally protected. It is intended only for the addressee. If > you > received this e-mail in error or from someone who was not authorized to > send it to you, do not disseminate, copy or otherwise use this e-mail or > its attachments. Please notify the sender immediately by reply e-mail > and > delete the e-mail from your system. > > > -----Original Message----- > > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Hilliard, Chris > Sent: Friday, February 29, 2008 8:14 AM > To: [email protected] > Subject: Re: error bringing up cloned system > > I ran into this problem as well. I went back and re-installed my master > image. When I got to the partitioning step, I changed the FSTAB options > for dev/dasdx to use "device-name" instead of "device-id". I'm not sure > what one selection has over the other but it sure makes cloning a lot > easier. > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Thursday, February 28, 2008 5:49 PM > To: [email protected] > Subject: error bringing up cloned system > > Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and > now receive the following IPL errors.. After the DDR I correctly relabel > the pack to reflect its real addr as usual, define the pack to another > guest machine and modify the mdisk to match the original. This time it > does not work. I took the SLES defaults for installation for storage > Device > names. If I knew if this info was in a Yast log I could try to find it, > if > it would help. > > Waiting for udev to settle... > Scanning for LVM volume groups... > Reading all physical volumes. This may take a while... > Found volume group "system" using metadata type lvm2 > Activating LVM volume groups... > 1 logical volume(s) in volume group "system" now active > ..done > Waiting for /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1 . > no more events > Checking file systems... > fsck 1.38 (30-Jun-2005) > Checking all file systems. > error on stat() /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: No > such f > [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a > /dev/disk/by-id/ccw-IBM.75000000029 > error on stat() /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: No > such f > fsck.ext3: No such file or directory while trying to open > /dev/disk/by-id/ccw-I > /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: > /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate > superblock: > e2fsck -b 8193 <device> > fsck.ext3 /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1 failed > (status 0 > [1A..failedblogd: no message logging because /var file system is not > accessible > fsck failed for at least one filesystem (not /).
