Actually - Volker is right - you *do* have to rebuild the ramdisk when your
root filesystem is on a SCSI volume.

The example in chapter 6.3.1 is for adding volumes to an existing system,
but it shows you the basics of the process. The reason you dont have to
rebuild the ramdisk in that example is that once the system IPLs and has
the root filesystem mounted, it looks through the /etc/sysconfig/hardware
directory for devices that should be brought online. This happens before it
tries to mount other things from /etc/fstab - so as long as the disks that
are being added are for things like /opt, /var or whatever it works fine.

Since you'll be IPLing from this newly cloned SCSI disk you will have to
recreate the ramdisk with the updated SCSI config so that after the kernel
and ramdisk are loaded the kernel is able to find your new SCSI root
volume.

Sorry for not pointing this out earlier.

A more specific version of my previous recipe follows:

a) Use ESS Copy services to clone a LUN - much faster than dd and uses less
z CPU time

b) on an existing SLES-9 system ( possibly the Source system ) dynamically
add the target LUN using the instructions in 6.3.1 ( echo stuff into
/sys/bus/ccw... like Neal said )

c) mount the target somewhere ( mount /dev/sd? /mnt )
   also mount up /proc and /sys
   mount -t proc none /mnt/proc
   mount -t sysfs none /mnt/sys

d) chroot into the target system ( chroot /mnt /bin/bash )

e) edit the zipl and scsi configuration files for the target system.  might
as well edit the network config while youre at it...
   scsi config in /etc/sysconfig/hardware
   zipl config in /etc/zipl.conf
   network config in /etc/???

f) make a new initrd with mkinitrd ( or mk_initrd which is the smarter SuSE
version )
   make sure that it adds your new scsi volume

g) run zipl to write the new IPL text out to disk. ( zipl -V )
   make sure it uses the new ramdisk

h) exit chroot

i) unmount target ( unmount /mnt/sys and /mnt/proc first )

j) target is now IPLable

Jay Brenneman

Linux Test and Integration Center

T/L:       295 - 7745
Extern: 845 - 435 - 7745
[EMAIL PROTECTED]





             "Seader, Cameron"
             <[EMAIL PROTECTED]
             er.com>                                                    To
             Sent by: Linux on         [EMAIL PROTECTED]
             390 Port                                                   cc
             <[EMAIL PROTECTED]
             IST.EDU>                                              Subject
                                       Re: FW: Cloneing Linux Guests on
                                       FCP SCSI
             27/10/2004 08:12
             AM


             Please respond to
             Linux on 390 Port






if you look at previous postings you should not have to build the ram disk
this way.
-Cameron

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Volker Sameske
Sent: Wednesday, October 27, 2004 01:06
To: [EMAIL PROTECTED]
Subject: Re: FW: Cloneing Linux Guests on FCP SCSI


The problem is the ramdisk on your SCSI disk. This ramdisk contains
the information, where to find your root file system (adapter devno,
WWPN and LUN). Hence you have to change this information on the
ramdisk. A simple mk_initrd will do the job on the mounted SCSI disk.
But make sure, not to overwrite your ramdisk from the system, where
you have mounted the SCSI disk.

I have tried this out and here are the steps:
- attach your SCSI disk (target SLES9) to a working SLES9 system
  (source SLES9) (SCSI or DASD) and mount it
- rename the ramdisk (/boot/initrd-...) from the source system to
  save it, make sure to rename the ramdisk and not only the link
- call mk_initrd without any parameter and the system will build
  a new ramdisk, using all active modules including the zfcp device
  driver and the current path to your target SCSI disk
- move the new build ramdisk to your target disk (/mnt/boot/) and
  set the link accordingly
- run zipl on your mounted target disk to make the SCSI disk bootable
  with the new ramdisk
- finally restore your source system by copying the originally
  saved ramdisk back, make sure to use the original initrd with
  its original name!

Maybe there is an easier way to do this, e.g. building the ramdisk
directly on the target disk and not on the source disk, but I had
not the time to try this out.

regards,
Volker

Linux on zSeries Development
Tel.: +49-(0)7031-16-2019
IBM Deutschland Entwicklung GmbH

> What do i change in zipl.conf, and what scsi config files do i need to
change?
> -Cameron

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390



[INFO] -- Access Manager:
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law.  If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format.  Thank you.   A2

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to