John Summerfield wrote: > Mark Hamzy wrote: >> I am working on a feature for the 390 architecture called reipl. It >> allows >> the vm to be rebooted into a specific partition. On scenario where this >> would be usefull is after the initial install, the vm should boot from >> the >> newly installed partition and not from the reader (where it initially >> booted from). I'd like to add, that this not only supports z/VM environments but also LPARs, i.e. any environment Linux may run on s390/s390x. > One feature of LILO I miss is the ability to run the lilo command to > select a menu entry to be used for the next boot and only the next boot. I suppose you mean ZIPL (the s390 bootloader) instead of LILO, since I think I remember LILO already having such an option. > I think I would like to see something akin to this on intellish > hardware: rather than interacting with firmware (which _I_ don't > understand and am not sure that it's sufficiently standard), I'd see it > being done on the first disk used to boot: usually, the MBR of the > partition containing /boot. s390 does not have a default boot device determined by the BIOS/firmware. Hence, there is nothing to load the bootloader from automatically. Therefore, we cannot use the bootloader to boot from a certain device, e.g. the one where we just installed to during the 1st installation phase. The backend of reipl support for s390 is upstream in the kernel and instructs the firmware where to boot from after the kernel has finished its reboot preparation. The user interface to reipl support is through sysfs. A less feature complete installer support for reipl has already been done before by Brad Hinson, David Cantrell, and Jan Glauber: https://bugzilla.redhat.com/show_bug.cgi?id=432416 referenced at the end of http://kbase.redhat.com/faq/FAQ_49_12902 The code can already be found in anaconda.git. However, this code does not support reipl from FCP SCSI and also misses to check if the reipl configuration worked and do a shutdown instead of reboot if it didn't work, to prevent an endless loop rebooting the installation image over and over again. One more detail: If reipl configuration (i.e. writing values into the sysfs entries) fails, a Linux reboot will happen from the device it has previously booted from (see /sys/firmware/ipl/). Such a failure in configuration happens if the version of either the hardware or the software (z/VM) does not support an automatic reipl from the requested device, e.g. from FCP. In such a case, the manual ipl by the user after a shutdown of the Linux install image still works perfectly and is the way to go (as it used to be before there was reipl support in the installer). For the sake of completeness the corresponding documentation: http://www.ibm.com/developerworks/linux/linux390/development_documentation.html Device Drivers, Features, and Commands - SC33-8411-00, May 2008 http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26ddd00.pdf Regards, Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Schönaicher Straße 220 D-71032 Böblingen e-Mail: maier@xxxxxxxxxx Phone: +49-(0)7031-16-2354 Fax: +49-(0)7031-16-3456 IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
