Last updated on: Sunday, July 06, 2008
Software
Information
Community
News
Fun
Credits
|
This information was originally posted to the
Linux-390 mailing list on February 16, 2002, by Michael Coffin.
- Clone the existing system to new dasd using tar. I broke mine up into a
2,300 3390 cylinder /usr (which will be linked R/O by other Linux machines)
and a 200 3390 cylinder / with all of the other directories. For the
purposes of this example, my disk layout is:
150 dasda Existing big Linux system (bootable)
151 dasdb Existing swap space
15e dasdo New Linux system's /usr disk (to become dasdc at virtual 153 on new system)
15f dasdp New Linux system's / disk (bootable - to become dasda at virtual 150 on new sys)
- Mount your target device (dasdp) which will become the IPLable boot disk (dasda)
of the new system. In my case it was mounted as /mnt/temp.
- Backup and then remove (rm) /etc/zipl.conf and /mnt/temp/etc/zipl.conf to make
sure zipl doesn't read either of these!
- Change to your new /boot directory (i.e. cd /mnt/temp/boot)
- Run the following zipl command:
zipl --target=/mnt/temp/boot \
--image=/mnt/temp/boot/vmlinuz-2.4.9-13.4 \
--parmfile=/mnt/temp/boot/parmfile
where "vmlinuz-2.4.9-13.4" is the fileid of the linux image (don't use the
"vmlinuz symlink, remember that it points to /boot on dasda!) and "parmfile"
is your kernel parameter file.
- Edit /mnt/temp/etc/fstab and change the device for "/" from "LABEL=/" to
"dev/dasda1". On at least one attempt when this was left as "LABEL=/" the
new system would boot but fail on this record - not entirely sure why.
Assuming you use the addressing stated above, add the following to
/mnt/temp/etc/fstab:
/dev/dasdc1 /usr ext2 auto,ro 0 1
If you want /usr linked R/W modify this accordingly.
- Shutdown your existing big disk Linux system, give your two newly
created disks (along with a swap disk) to the virtual machine that will run
the shared /usr distribution of Linux (150 is /, 151 is a swap disk, 152 is the
read-only /usr) and IPL 150.
That's what I did and it finally worked. I'm convinced that there is
something wrong with zipl when using the config file. I ran zipl at least 6
or 7 times in the past day or two. I recall when using zipl to update the
current production disk (dasda) it seemed to work ok. But when trying to
create a second bootable disk and providing the parameters as operands on
the command line, strange things would happen (no errors would be reported,
but in many attempts the new boot disk AND on some occasions the existing
production boot disk were destroyed requiring a complete re-install).
So the moral of the story SEEMS to be when using zipl against your
production boot disk mounted as dasda it seems to work OK, but when
providing command line parameters to point the image somewhere else
"anything can happen".
|