On 08/26/2008 06:38 AM, David Cantrell wrote: > On Aug 25, 2008, at 6:04 AM, Steffen Maier wrote: >> do you have any new comments on our discussion? >> >> On 08/11/2008 10:45 AM, Steffen Maier wrote: >>> any news or new opinions from your side concerning Mark's work on >>> supporting automatic reboot after the 1st install phase by integrating >>> the s390 reipl feature into anaconda? > > Is Reipl.py a new command for the distribution? It contains option > parsing and other things that you'd find in a command line tool. If it > is, where is it to live? Actually Reipl.py is both a python module for use from within anaconda (calling processOptions()) and a command line tool. The main intention was IMHO to integrate it into anaconda, all the rest is just added value. For the integration into anaconda, I would say, we can strip off the main part and Usage(). > If it's not a command and the functionality is to be added to anaconda, > is there anyway it can be significantly reduced? All of the sanity > checking code and sysfs finding code....is any of that really necessary? > In anaconda we can assume sysfs is mounted to /sys, for example. You're right, meanwhile I'm convinced that we don't need to find, where sysfs is mounted. First, because in our special case within anaconda it's fixed to /sys anyway. Secondly, because I found out that linux/Documentation/sysfs-rules.txt says: "- sysfs is always at /sys". With regard to the sanity checks, I would say they are a nice way of defensive programming style. Kind of like a little integrated unit test, that will alert us immediately should the sysfs kernel interface for reipl change from the way it currently is and we rely on. If those few additional lines hurt too much for integration with anaconda, I would be fine with removing SanityCheck() since possible failures on all actual reads and writes on the sysfs attributes are still caught and give a sensible error message to the user. IMHO, there should just be no uncaught exceptions throwing backtraces, that are meaningless for the user. > But, > if Reipl.py is a new system command, I can see how you'd want it to hunt > around for sysfs. I mean, what needs to happen in anaconda for reipl to > work? We need to transform the boot device (which we know in anaconda) > to the special format to write to the sysfs files, right? Yes, that is step one of two: Converting the device name of the mount point /boot, or if that doesn't exist /, to the naming conventions of the s390 I/O subsystem and using it to write to sysfs. > Going back to what Jeremy was saying a while back, this should be a > simple task for anaconda. Try to write the reipl device, nothing more. > If it fails, it fails. Now to step two of two. Imagine customers, running in LPAR on hardware older then z9 or in z/VM older than version 5.3 and they want to install RHEL on SCSI disks attached via zFCP. The involved versions of firmware/software do not support reipl in such a setting. Still the installation works perfectly fine including the writing of the zipl bootloader. If we now just fail, because we could not configure reipl due to the involved versions, _and_ we unconditionally reboot, then the system will reboot exactly the same thing as it did before (on z/VM at least and there it is the VM reader most probably still having the kernel, parm file, and install initrd punched into it) and that would be the install environment. IMO, it would not be a good idea to throw our customers into an endless loop, rebooting into the install environment, starting from scratch all over again, although the 1st install phase went perfectly fine. If the reipl configuration did not work, it is only due to versions of involved software, and we should do a halt/shutdown as has always been done on s390. This gives the user the possibility to manually ipl the newly installed system and continue to the 2nd install phase. We should reboot, if (and only if) the reipl configuration went fine. Then the customer would see improved usability, since the system reboots automatically from the correct device. > As he noted, we don't do anything special for > grub failures because we can't really. I'm perfectly fine with your suggested behavior on failures installing the bootloader, which is zipl on s390. However, our automatic reipl support in the installer has got nothing to do with the configuration of the bootloader. As mentioned above, installing the bootloader works fine, even though the configuration of reipl might not due to versions of involved software. So, yes, this is a special case which probably just exists on s390. All other platforms happen to have a BIOS/firmware telling them where to boot from on default. We don't have such default boot device on s390 and therefore need to tell our firmware, if we want to reboot from a different device than on previous boot. > On s390 we do gain a little more, >From an ease of use perspective we do gain a lot on s390, namely the reboot between install phase 1 and 2 works automatically with our reipl support. Hence, s390 would behave as all other platforms already do! This brings s390 in line with all other platforms. > but to keep the installer in line with other platforms, let's keep > the failure handling to logging a message in anaconda and continuing anyway. I wish this would work out and would result in user-friendly behavior, but please consider the above mentioned consequences of an endless install loop for customers. Please understand, that this is not about us insisting on our standpoint. It is rather about the resulting user experience, if we implemented reipl support as you suggest. I doubt, users would like seeing the installer redo from start even though everything installed fine during the previous 1st phase. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier 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
