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: IBMVM@LISTSERV.UARK.EDU 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> IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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: IBMVM@LISTSERV.UARK.EDU 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 /).
