Tux on VM

Last updated on:
Sunday, July 06, 2008

Software

Information

Community

News

Fun

Credits




Valid HTML 4.01! 		Linux for Big Iron
This information was originally posted to the Linux-390 mailing list on February 16, 2002, by Michael Coffin.


  1. 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)
  2. 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.
  3. Backup and then remove (rm) /etc/zipl.conf and /mnt/temp/etc/zipl.conf to make sure zipl doesn't read either of these!
  4. Change to your new /boot directory (i.e. cd /mnt/temp/boot)
  5. 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.
  6. 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.
  7. 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".
 

Site hosting courtesy of Velocity Software