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,0x1000000
>     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,0x1000000
>     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.75000000029217.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

Reply via email to