I ran into this same problem. The /dev/disk/by-id name for the disk was different on the cloned system from the master image on some (not all) of the clones. I didn't find the source of the difference, but I did switch to /dev/disk/by-path/ccd-0X0391-part1 instead of using the by-id name that the system had chosen on its own.
I have no idea what generates the by-id names. Ours look like ccw-IBM.750000000CYCY1.c700.2d, and on several of the clones, the c700 portion changed to something else. The by-path names remain consistent from system to system, and would seem to me to be a better choice, if your virtual CCUU addresses will remain the same. Hope this helps. -- 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/28/08 4:48 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 /).
