Re: error bringing up cloned system
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 IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [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: 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
Re: error bringing up cloned system
But, if you're cloning an image, and you're running beneath z/VM, then why would you ever need to change the CUU of any of the cloned disks? Generate your clone to match your master image, using the same virtual devices. Since one doesn't know about the other, from the guest standpoint, there is no conflict of addresses. -- 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:33 PM, Romanowski, John (OFT) [EMAIL PROTECTED] wrote: The by-path/ name is straight-forward , like /dev/disk/by-path/ccw-0.0.0201-part1 is partituion 1 on virtual dasd address 0201 If your cloning process makes each server run with different virtual addresses I can see what you mean by I don't really know what the by-path name should be at this point and /dev/dasdx is a good choice
Re: error bringing up cloned system
On Mon, Mar 3, 2008 at 8:57 AM, in message [EMAIL PROTECTED], RPN01 [EMAIL PROTECTED] wrote: 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. It won't always be ccw-0.0 in the future, with the advent of multiple channel subsets. It might be ccw-0.1, for example. Without any experience in this, I have no idea if you'll be able to tell ahead of time if that's the case. Mark Post
Re: error bringing up cloned system
Back in business. Thanks to everyone for the answers. I used by-path for the boot partition. For the LVL the suse default was NOT uuid. I changed that to use uuid. I created another userid and successfully cloned the image. By the way I missed the part about needing 500 meg to install this(used NFS). Used 256 meg instead and although it worked, kinda, I had very bad thruput problems. Took a while to figure out. If I remember right they were not network errors, I think they showed as tcpip checksum errors on the trace. RPN01 [EMAIL PROTECTED] edu To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: error bringing up cloned system 03/03/2008 08:57 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU 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 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 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
Re: error bringing up cloned system
On Fri, Feb 29, 2008 at 7:24 PM, in message [EMAIL PROTECTED], Patrick Spinler [EMAIL PROTECTED] wrote: -snip- And another way to get round this is to mount /boot or other static filesystems by filesystem label: Until you get to the point where you want to work with a volume from another system, and the file system has the same label on it. Bad things can happen, so I don't recommend that. Mark Post
Re: error bringing up cloned system
On Thu, Feb 28, 2008 at 6:10 PM, in message [EMAIL PROTECTED], Adam Thornton [EMAIL PROTECTED] wrote: -snip- SLES10, stupidy, chooses its filesystems by disk-ID. SLES10 SP1, actually. SLES10 GA acted the same as previous releases. One of the reasons so many people got surprised, I think. Mark Post
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.7500029217.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.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.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 /).
Re: error bringing up cloned system
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.75000CYCY1.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.7500029217.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.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.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 /).
Re: error bringing up cloned system
Zipl.conf is probably fine. Change fstab, not necessarily to /dev/dasda1, but to the /dev/disk/by-path for the CCUU of dasda1, so that, should its order in the list of disks ever change and it were to become, say, /dev/dasdb1 instead, you'll still find it correctly. That's the whole point of the /dev/disk/by- stuff. -- 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 8:40 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Before I trash my system.: ( ..I found the line to change in fstab; from (/dev/disk/by-id...) to (/dev/dasda1/boot ext3 ...) but what to change in zipl.conf? Thanks. zipl.conf # Modified by YaST2. Last modification on Wed Feb 27 17:32:34 EST 2008 [defaultboot] defaultmenu = menu [SLES_10_SP1] image = /boot/image-2.6.16.54-0.2.5-default target = /boot/zipl ramdisk = /boot/initrd-2.6.16.54-0.2.5-default,0x100 parameters = root=/dev/system/lv1 TERM=dumb :menu default = 1 prompt = 1 target = /boot/zipl timeout = 10 1 = SLES_10_SP1 2 = ipl ###Don't change this comment - YaST2 identifier: Original name: ipl### [ipl] image = /boot/image target = /boot/zipl ramdisk = /boot/initrd,0x100 parameters = root=/dev/system/lv1 TERM=dumb Adam Thornton [EMAIL PROTECTED] mine.net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: error bringing up cloned system 02/28/2008 06:10 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU On Feb 28, 2008, at 4:48 PM, [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. SLES10, stupidy, chooses its filesystems by disk-ID. This is no good if you want to clone, because you will end up with different real underlying IDs on your disk. Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 Convert the basic system to use a different scheme that IS OK to use across different disks (I like to use by-path, as I tend to use the same device address conventions on all guests), change zipl.conf and / etc/fstab to reflect that scheme, rerun zipl/mkinitrd, and then clone the resulting system. Adam
Re: error bringing up cloned system
Before I trash my system.: ( ..I found the line to change in fstab; from (/dev/disk/by-id...) to (/dev/dasda1/boot ext3 ...) but what to change in zipl.conf? Thanks. zipl.conf # Modified by YaST2. Last modification on Wed Feb 27 17:32:34 EST 2008 [defaultboot] defaultmenu = menu [SLES_10_SP1] image = /boot/image-2.6.16.54-0.2.5-default target = /boot/zipl ramdisk = /boot/initrd-2.6.16.54-0.2.5-default,0x100 parameters = root=/dev/system/lv1 TERM=dumb :menu default = 1 prompt = 1 target = /boot/zipl timeout = 10 1 = SLES_10_SP1 2 = ipl ###Don't change this comment - YaST2 identifier: Original name: ipl### [ipl] image = /boot/image target = /boot/zipl ramdisk = /boot/initrd,0x100 parameters = root=/dev/system/lv1 TERM=dumb Adam Thornton [EMAIL PROTECTED] mine.net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: error bringing up cloned system 02/28/2008 06:10 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU On Feb 28, 2008, at 4:48 PM, [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. SLES10, stupidy, chooses its filesystems by disk-ID. This is no good if you want to clone, because you will end up with different real underlying IDs on your disk. Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 Convert the basic system to use a different scheme that IS OK to use across different disks (I like to use by-path, as I tend to use the same device address conventions on all guests), change zipl.conf and / etc/fstab to reflect that scheme, rerun zipl/mkinitrd, and then clone the resulting system. Adam
Re: error bringing up cloned system
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.7500029217.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.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.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 /).
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 SystemSubject [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
Re: error bringing up cloned system
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.7500029217.2500.2e-part1
Re: error bringing up cloned system
The problem all this is trying to get around is that, if you define a system that brings up, say, minidisks at 391, 392 and 393, they become /dev/dasda, dasdb and dasdc. Now you add a new minidisk at 291 If the system puts this at the end of the list, then it would become /dev/dasdd, and this would happen when you add the disk into the running system. But, what if, when you re-boot the entire image, it now finds this disk first? It could become /dev/dasda, pushing the other disks each up one letter, and causing your fstab and other things to fail miserably. But, minidisk 391 is (or at least, should be) always 391, no matter if it is /dev/dasda or /dev/dasdb. Which ever it is, you know you want it to be your root filesystem (or your /boot, or whatever). You don't care a smidge about the letter it lives at. This is where /dev/disk/by-path comes in. You can use this to identify the disk by its CUU address in the virtual machine. Suddenly, you're immune to new disks added at random addresses. The /dev/disk/by-id would be used for the wild and insane among us, that want to change around the minidisk addresses randomly between boots. There's also by-uuid... I think this one is looking at some internal field in the disk's label, but I've no research to back up that statement. Note that if you use LVM for the majority of your system, then this whole issue is only relevant for the /boot disk (and possibly the root filesystem; depends on whose rules you follow). LVM uses the disk's uuid to locate the physical volumes that make up a volume group, and sets everything up accordingly. -- 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 12:33 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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 SystemSubject [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
Re: error bringing up cloned system
From: RPN01 The problem all this is trying to get around is that, if you define a system that brings up, say, minidisks at 391, 392 and 393, they become /dev/dasda, dasdb and dasdc. Now you add a new minidisk at 291 If the system puts this at the end of the list, then it would become /dev/dasdd, and this would happen when you add the disk into the running system. But, what if, when you re-boot the entire image, it now finds this disk first? It could become /dev/dasda, pushing the other disks each up one letter, and causing your fstab and other things to fail miserably. We solved this problem by including dasd=292-2FF with the ipl parameters in zipl.conf -- I inherited this configuration and I suspect it was put into place before there was a mount by-path option. With this in zipl.conf, 292 is always dasda, 2A9 is always dasdx, etc. I have been aware of other installations where parameters like dasd=293,292,294-2FF were specified, so that 293 is dasda, 292 is dasdb, 294 is dasdc, and so on. No doubt they had their reasons, although it seems somewhat gratuitous to me. Solaris handles this problem very well, IMO---especially with the addition of Veritas Volume Manager. The Linux mount by-path does come close to giving Solaris-like behavior, but when I look sideways at it there's something I can't put my finger on which makes me not entirely sure I should convert my systems to it. Perhaps there's nothing there after all, but without our having a real problem to solve here, there's little reason to look closer. ok r.
Re: error bringing up cloned system
The by-path/ name is straight-forward , like /dev/disk/by-path/ccw-0.0.0201-part1 is partituion 1 on virtual dasd address 0201 If your cloning process makes each server run with different virtual addresses I can see what you mean by I don't really know what the by-path name should be at this point and /dev/dasdx is a good choice -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system 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 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 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: 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
Re: error bringing up cloned system
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 IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [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: 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
Re: error bringing up cloned system
On Feb 29, 2008, at 12:33 PM, [EMAIL PROTECTED] wrote: 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? By-id has *nothing* to do with the device address. It's a terrible idea in a virtualized environment--it tries to synthesize a unique ID from characteristics of the real device it can figure out. This makes cloning impossible. It should not have been the default in SLES for s390x. By-path is the one that corresponds to the device address. You can clone *that* and as long as your device definitions don't change across guests you're fine. It's the one most of us here are recommending. /dev/dasdXp1 is fine, except that if you add a device with a lower device address and aren't very careful about how you force device detection order in zipl.conf, then you will end up being very sorry when your new device shows up as /dev/dasda and bumps your older devices down the chain so that /etc/fstab no longer works. In a VM environment, by-path is usually the addressing method most likely to stay constant. Adam
Re: error bringing up cloned system
Ok, just started another install for a golden image. So far I use device-path for /dev/dasda (/boot) but now I am sitting on the screen for setting fstab options for the lvl. It won't let me chose device-id or device-path (faded out). The default setting is for device-name. I could also choose volume-label or uuid. Should I choose uuid? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 03:33 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU The by-path/ name is straight-forward , like /dev/disk/by-path/ccw-0.0.0201-part1 is partituion 1 on virtual dasd address 0201 If your cloning process makes each server run with different virtual addresses I can see what you mean by I don't really know what the by-path name should be at this point and /dev/dasdx is a good choice -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system 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 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 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: 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
Re: error bringing up cloned system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RPN01 wrote: | | Note that if you use LVM for the majority of your system, then this whole | issue is only relevant for the /boot disk (and possibly the root filesystem; | depends on whose rules you follow). LVM uses the disk's uuid to locate the | physical volumes that make up a volume group, and sets everything up | accordingly. | And another way to get round this is to mount /boot or other static filesystems by filesystem label: ~ mke2fs -j -L SOMEFILESYS /dev/dasd... in fstab: ~ LABEL=SOMEFILESYS /somefilesys ext3 ... I do this on my distributed platforms which have SAN, and may change disk order when SAN disk is added or removed. - -- Pat -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyKIyNObCqA8uBswRAqZEAJ95xfLcqqHLh7dghF7lQbkWNKttMgCfSvBF PF5a7uAQUM5R3Xsuj7GFFq8= =nSXJ -END PGP SIGNATURE-
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.7500029217.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.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.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.7500029217.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 /).
Re: error bringing up cloned system
On Feb 28, 2008, at 4:48 PM, [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. SLES10, stupidy, chooses its filesystems by disk-ID. This is no good if you want to clone, because you will end up with different real underlying IDs on your disk. Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 Convert the basic system to use a different scheme that IS OK to use across different disks (I like to use by-path, as I tend to use the same device address conventions on all guests), change zipl.conf and / etc/fstab to reflect that scheme, rerun zipl/mkinitrd, and then clone the resulting system. Adam
