Hello,
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).
It constists of three peices.
1) A Python module, Reipl.py, which reads and writes the settings from the firmware (among other things). 2) A patch to anaconda main python module. At the end of the installation, it will call Reipl.py with the boot partition. It will then write the success of reipl into a file called /var/run/sigusr. 3) A patch to anaconda's loader to read the file /var/run/sigusr and send the appropriate signal (either shutdown or reboot) to linuxrc process.
Open issues: 1) Currently, Reipl.py is hard installed into /usr/sbin. I would like to create an rpm package for Reipl consisting of just that file. Is /usr/sbin a good place for it?
2) /usr/sbin is not in sys.path. I have to append sys.path before importing Reipl. Is this okay?
Are there any other issues with this code?
(See attached file: anaconda-11.1.2.113.patch) (See attached file: Reipl.py)
Mark
Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/ Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/
Mark Hamzy wrote:
Hello,
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).
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 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. It might be worth having a chat with your other server groups to see whether this addresses a problem the have, with the idea of coming up with a solution that looks, as much as possible, the same on all IBM platforms.
It constists of three peices.
- A Python module, Reipl.py, which reads and writes the settings from the
firmware (among other things). 2) A patch to anaconda main python module. At the end of the installation, it will call Reipl.py with the boot partition. It will then write the success of reipl into a file called /var/run/sigusr. 3) A patch to anaconda's loader to read the file /var/run/sigusr and send the appropriate signal (either shutdown or reboot) to linuxrc process.
Open issues:
- Currently, Reipl.py is hard installed into /usr/sbin. I would like to
create an rpm package for Reipl consisting of just that file. Is /usr/sbin a good place for it?
It's not clear to me _when_ this program is used. If you package it as an rpm and installed on the target system, then Anaconda can run it from there, but should chroot() to do so.
If it might be used during the ordinary use of a Linux guest (as it might be, if you have a recovery disk to IPL, repair something, then IPL that something in the same VM), then packaging it and installing to /usr/sbin or /usr/bin is sensible. If it's only to be used at install time, then you need to consider how it gets into the install image. Someone else might address that, I'm not very good with that snake either.
/sbin and /bin should be used for executables required before /usr gets mounted. See www.pathname.com where the FHS might be found.
Your Anaconda patch looks to me (see below for my snake-handling skills) like it expects a Python module, but the code looks like an ordinary executable.
- /usr/sbin is not in sys.path. I have to append sys.path before
importing Reipl. Is this okay?
I could not see where reipl executes any external program (but my python is strictly limited). If it's not executing other programs, PATH is unimportant.
Did you get the idea I'm writing this backwards? You should have:-)
Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/
I did, when it was new and (I think) hosted at IBM. I don't any more use any of the printers it supports, but I was really glad to see it.
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
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.h...
Device Drivers, Features, and Commands - SC33-8411-00, May 2008 http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26ddd00...
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@de.ibm.com 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
On Jul 21, 2008, at 11:36 AM, Mark Hamzy wrote:
Hello,
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).
It constists of three peices.
- A Python module, Reipl.py, which reads and writes the settings
from the firmware (among other things).
Can Reipl.py's functionality be incorporated in to booty rather than making a new tool? Booty is the cross-platform python tool for making the system bootable, which usually means installing a boot loader.
- A patch to anaconda main python module. At the end of the
installation, it will call Reipl.py with the boot partition. It will then write the success of reipl into a file called /var/run/sigusr. 3) A patch to anaconda's loader to read the file /var/run/sigusr and send the appropriate signal (either shutdown or reboot) to linuxrc process.
Open issues:
- Currently, Reipl.py is hard installed into /usr/sbin. I would
like to create an rpm package for Reipl consisting of just that file. Is /usr/sbin a good place for it?
- /usr/sbin is not in sys.path. I have to append sys.path before
importing Reipl. Is this okay?
Are there any other issues with this code?
Comments:
As stated above, can the functionality of Reipl.py become part of booty rather than making a new system-specific tool? I'm thinking about maintenance in the future and if Reipl.py is its own tool, it could easily be forgotten.
1) For the command portion of Reipl, if you were to move the knowledge of how to do things in to booty so we can centralize that sort of code, I would suggest finding a home for the frontend program in s390utils.
2) rhpl.getArch() has been replaced in rawhide with functions in iutil. iutil.isS390() would be my preferred method to test if you are on an s390 platform.
3) We don't generally leave 'import pdb ; pdb.set_trace()' statements in the code we commit, so make sure those aren't around.
4) I would wrap the open/write/close to /var/run/sigusr in a try- except block since that could fail. Also, I suggest using fp.write() to write lines to a file rather than print. Two reasons. First is consistency with the rest of the anaconda code. Second is that the print statement will go away in Python 3000 and the fewer of those we have to rewrite in the future, the better.
5) If you see a use of atoi() in loader's code, feel free to change it to strtol() with error checking. I mention this because I see the first atoi() in this patch and notice it could be zero if atoi() fails, which means kill() is called with pid value 0 sending SIGUSR1 to all processes currently running.
Beyond that, making sure the patch applies against rawhide is key. I realize for s390x, we have a unique situation. Feel free to continue working against RHEL5, but make sure the patch ports to rawhide (at least until we have a rawhide s390 playground).
Thanks,
On Tue, 2008-07-22 at 09:26 -1000, David Cantrell wrote:
- I would wrap the open/write/close to /var/run/sigusr in a try-
except block since that could fail. Also, I suggest using fp.write() to write lines to a file rather than print. Two reasons. First is consistency with the rest of the anaconda code. Second is that the print statement will go away in Python 3000 and the fewer of those we have to rewrite in the future, the better.
Also, it's not entirely clear to me why this is really needed. What would lead to setting the reipl failing? The cases that I see are all cases where the answer is "doomed" and so we might as well just always do the reboot. And that then makes things always act the same rather than adding yet another bogon weird code path for s390
Jeremy
On Jul 22, 2008, at 10:48 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 09:26 -1000, David Cantrell wrote:
- I would wrap the open/write/close to /var/run/sigusr in a try-
except block since that could fail. Also, I suggest using fp.write() to write lines to a file rather than print. Two reasons. First is consistency with the rest of the anaconda code. Second is that the print statement will go away in Python 3000 and the fewer of those we have to rewrite in the future, the better.
Also, it's not entirely clear to me why this is really needed. What would lead to setting the reipl failing? The cases that I see are all cases where the answer is "doomed" and so we might as well just always do the reboot. And that then makes things always act the same rather than adding yet another bogon weird code path for s390
I think some of this falls back on s390 using linuxrc.s390 rather than init like the other platforms. If that could be changed (eventually), I think we'd be in better shape. Right now, the linuxrc case on s390 means a lot of special handling for that platform.
The reipl tool failing isn't really a doomed case. If it fails, it's worth noting it somewhere (so we might have some hope of debugging...maybe) and continuing. If we can't reipl automatically, we should just shutdown and expect the console operator to load the magic stack of cards to get it going again.
On Tue, 2008-07-22 at 11:49 -1000, David Cantrell wrote:
On Jul 22, 2008, at 10:48 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 09:26 -1000, David Cantrell wrote:
- I would wrap the open/write/close to /var/run/sigusr in a try-
except block since that could fail. Also, I suggest using fp.write() to write lines to a file rather than print. Two reasons. First is consistency with the rest of the anaconda code. Second is that the print statement will go away in Python 3000 and the fewer of those we have to rewrite in the future, the better.
Also, it's not entirely clear to me why this is really needed. What would lead to setting the reipl failing? The cases that I see are all cases where the answer is "doomed" and so we might as well just always do the reboot. And that then makes things always act the same rather than adding yet another bogon weird code path for s390
I think some of this falls back on s390 using linuxrc.s390 rather than init like the other platforms. If that could be changed (eventually), I think we'd be in better shape. Right now, the linuxrc case on s390 means a lot of special handling for that platform.
Yeah, but that shouldn't require some magic new /var/run/sigusr stuff...
The reipl tool failing isn't really a doomed case. If it fails, it's worth noting it somewhere (so we might have some hope of debugging...maybe) and continuing. If we can't reipl automatically, we should just shutdown and expect the console operator to load the magic stack of cards to get it going again.
Instead this is the case. But really, *WHY* would the reipl tool fail? Because if it's the bogon case of weirdness, then it's no different than grub failing to install[1] in which case we should just reboot and when they see that they booted back into the installer rather than the installed system, the thought process goes "oh, whoops".
Jeremy
[1] Arguably, we should catch that case as well as this case and let the user know with a dialog saying so. But I'm pretty certain that the right answer isn't to just behind the covers decide whether to do a reboot vs a halt
On Jul 22, 2008, at 11:55 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 11:49 -1000, David Cantrell wrote:
On Jul 22, 2008, at 10:48 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 09:26 -1000, David Cantrell wrote:
- I would wrap the open/write/close to /var/run/sigusr in a try-
except block since that could fail. Also, I suggest using fp.write() to write lines to a file rather than print. Two reasons. First is consistency with the rest of the anaconda code. Second is that the print statement will go away in Python 3000 and the fewer of those we have to rewrite in the future, the better.
Also, it's not entirely clear to me why this is really needed. What would lead to setting the reipl failing? The cases that I see are all cases where the answer is "doomed" and so we might as well just always do the reboot. And that then makes things always act the same rather than adding yet another bogon weird code path for s390
I think some of this falls back on s390 using linuxrc.s390 rather than init like the other platforms. If that could be changed (eventually), I think we'd be in better shape. Right now, the linuxrc case on s390 means a lot of special handling for that platform.
Yeah, but that shouldn't require some magic new /var/run/sigusr stuff...
There's got to be a better way to do this. I mean, it's stage 2 "ipc" to loader so loader knows whether to send SIGUSR1 or SIGUSR2 to init so it can do a shutdown or reboot. All of this is automatic, but sloppy.
Mark, can we just always reboot in linuxrc.s390 and skip the logic to figure out if we should reboot or shutdown? This does bring s390 closer to behavior we see on other platforms. Reboot after installation. If reipl sets things up correctly, it should reboot in to the installed system. If, for whatever reason, it failed, we get a failure on boot, but the system is still shut down.
The reipl tool failing isn't really a doomed case. If it fails, it's worth noting it somewhere (so we might have some hope of debugging...maybe) and continuing. If we can't reipl automatically, we should just shutdown and expect the console operator to load the magic stack of cards to get it going again.
Instead this is the case. But really, *WHY* would the reipl tool fail? Because if it's the bogon case of weirdness, then it's no different than grub failing to install[1] in which case we should just reboot and when they see that they booted back into the installer rather than the installed system, the thought process goes "oh, whoops".
Jeremy
[1] Arguably, we should catch that case as well as this case and let the user know with a dialog saying so. But I'm pretty certain that the right answer isn't to just behind the covers decide whether to do a reboot vs a halt
Why would it fail? That I don't know because I don't know enough about the reipl capability on s390 via sysfs. However, all it really does is take values from one part of sysfs and writes them to another part of sysfs. Should sysfs presentation for this information change, I could see reipl failing. Device name renaming too could affect this.
But you are right, the less we present and the more it does in the background, the better. I would like anaconda (or booty or whatever) to set up the reipl bits on the system and we just always reboot on s390.
David Cantrell wrote:
On Jul 22, 2008, at 11:55 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 11:49 -1000, David Cantrell wrote:
On Jul 22, 2008, at 10:48 AM, Jeremy Katz wrote:
On Tue, 2008-07-22 at 09:26 -1000, David Cantrell wrote:
I think some of this falls back on s390 using linuxrc.s390 rather than init like the other platforms. If that could be changed (eventually), I think we'd be in better shape. Right now, the linuxrc case on s390 means a lot of special handling for that platform.
IMHO reboot vs. shutdown is not related to linuxrc.s390 vs. init.
Yeah, but that shouldn't require some magic new /var/run/sigusr stuff...
There's got to be a better way to do this. I mean, it's stage 2 "ipc" to loader so loader knows whether to send SIGUSR1 or SIGUSR2 to init so it can do a shutdown or reboot. All of this is automatic, but sloppy.
Mark, can we just always reboot in linuxrc.s390 and skip the logic to figure out if we should reboot or shutdown? This does bring s390 closer to behavior we see on other platforms. Reboot after installation. If reipl sets things up correctly, it should reboot in to the installed system. If, for whatever reason, it failed, we get a failure on boot, but the system is still shut down.
Problem here is, that the system won't fail on boot but rather reboot from the previous boot device, which brings up the installer again. Hence, the system won't be shut down. Therefore, we have to do it explicitly on a case by case basis.
The reipl tool failing isn't really a doomed case. If it fails, it's worth noting it somewhere (so we might have some hope of debugging...maybe) and continuing. If we can't reipl automatically, we should just shutdown and expect the console operator to load the magic stack of cards to get it going again.
Exactly.
Device name renaming too could affect this.
Interesting new point. Could you please give some example scenario, because I don't fully understand yet?
Steffen Maier
Linux on System z Development IBM Deutschland Research & Development GmbH Scho"naicher Stra?e 220 D-71032 Bo"blingen
e-Mail: maier@de.ibm.com Phone: +49-(0)7031-16-2354 Fax: +49-(0)7031-16-3456
Internal address: Kst. 3282, 71032-06-022
IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Gescha"ftsfu"hrung: Herbert Kircher Sitz der Gesellschaft: Bo"blingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Hi all,
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?
Steffen
Linux on System z Development
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
Hi David, Jeremy, John,
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?
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
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
Steffen Maier wrote:
sensible error message to the user. IMHO, there should just be no uncaught exceptions throwing backtraces, that are meaningless for the user.
Hic!!
I'm drinking to that!
I really do not like errors being reported by traceback.
Steffen Maier wrote:
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.
At present, one can specify whether to automatically reboot (on any platform) or sit there looking stupid. It shouldn't be hard to add an option to halt instead at that point. Maybe on S390, the choice would be between reboot and halt? Or should there be three choices for all?
On 08/28/2008 04:06 AM, John Summerfield wrote:
Steffen Maier wrote:
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.
At present, one can specify whether to automatically reboot (on any platform) or sit there looking stupid. It shouldn't be hard to add an option to halt instead at that point.
Linuxrc.s390 (or probably init respectively on the other platforms) already handles the choice between reboot and halt. There's a do_reboot and a do_shutdown function, which are called as trap on receiving SIGUSR2 or SIGUSR1 respectively.
During installation, the user logs in through ssh, which starts the loader and in turn anaconda. The configuration of reipl and hence the detection if it was successful happens in anaconda. Loader waits for its child anaconda to exit. On anaconda's exit, loader decides how to proceed. On s390, loader has been sending a SIGUSR1 to linuxrc.s390 to initiate a halt unconditionally so far. This is exactly the place where Mark's posted patch introduces the functionality of doing a dependent reboot or halt:
Anaconda writes the number 1 or 2 as ASCII text into the file /var/run/sigusr depending on the success of reipl configuration. Loader reads this file and sends the appropriate signal to linuxrc.s390.
So this is our proposed and tested mechanism for doing a dependent reboot or halt. Of course, we are open to suggestions on how to best model this "backwards interprocess communication" between anaconda and loader or linuxrc.s390 respectively.
Maybe on S390, the choice would be between reboot and halt? Or should there be three choices for all?
Exactly, it's just between the two choices of reboot and halt.
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@lists.stg.fedoraproject.org