On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:
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 reason why s390 does a shutdown is to stop it from looping. The 390 reader is loaded with an install image of Redhat. And the reipl information points to that reader image. So, when a reboot is performed, it has the effect of booting into the installer again. Which is not what we want.
What you do not see is a failure on reboot. It reboots. The system administrator sees a linux system booting up. It is just not the correct system.
So, what issues are we against? The error checking on writing out reipl information? The additional "ipc" to the loader to shutdown on an error?
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/
(A couple of helpful hints: please fix your mail client so that replies are properly threaded and also don't send html mail to the list)
On Wed, 2008-07-23 at 15:00 -0500, Mark Hamzy wrote:
On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:
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 reason why s390 does a shutdown is to stop it from looping. The 390 reader is loaded with an install image of Redhat. And the reipl information points to that reader image. So, when a reboot is performed, it has the effect of booting into the installer again. Which is not what we want.
And if you have a failure to install the bootloader on a lot of other platforms, you end up booting back into the installer also. So s390 isn't special here.
What you do not see is a failure on reboot. It reboots. The system administrator sees a linux system booting up. It is just not the correct system.
Again, this isn't different from other architectures
So, what issues are we against? The error checking on writing out reipl information? The additional "ipc" to the loader to shutdown on an error?
I'm against adding architecture specific codepaths when, realistically, there's no good reason to. This sounds like a case where the behavior on s390 is no different from that of any other platform. And so we should let it follow the code paths that we use everywhere else.
And then, if we're concerned about possible (uncommon) errors there, let's add something *COMMON* to handle informing the user about the error rather than one-offs for s390
Jeremy
Jeremy Katz wrote:
And if you have a failure to install the bootloader on a lot of other platforms, you end up booting back into the installer also. So s390 isn't special here.
What you do not see is a failure on reboot. It reboots. The system administrator sees a linux system booting up. It is just not the correct system.
Again, this isn't different from other architectures
So, what issues are we against? The error checking on writing out reipl information? The additional "ipc" to the loader to shutdown on an error?
I'm against adding architecture specific codepaths when, realistically, there's no good reason to. This sounds like a case where the behavior on s390 is no different from that of any other platform. And so we should let it follow the code paths that we use everywhere else.
And then, if we're concerned about possible (uncommon) errors there, let's add something *COMMON* to handle informing the user about the error rather than one-offs for s390
It's becoming less a problem on intellish hardware these days, as one can commonly interrupt the BIOS and make a one-off choice to boot something different.
I've not seen the problem on Apples or on the Sparcs I've had my hands on.
It's a _very_ long time since I had my hands on a mainframe; those with long memories might recall the System/370 range (I played with models 135, 145 and 168) and Facom (Fujitsu) M-series (I had my hands on a M190, which was a little newer). On real hardware, one set a dial (or screen selection) to the boot device, and it stayed on that selection; under VM one might say "IPL 180."
I'm curious as to how the boot loop occurs on the modern zSeries.
fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people generally don't use the vendor's install procedure very much, atm they're discussing procedures to clone and customise systems, and some discussion as to whether it's better done in VM or in Linux: the Linux proponent has just said he can have a new system on the network in under a minute.
There are people from RH (Brad Hinson) and Novell subscribed to the list just now.
John Summerfield wrote:
fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people generally don't use the vendor's install procedure very much, atm they're discussing procedures to clone and customise systems, and some discussion as to whether it's better done in VM or in Linux: the Linux proponent has just said he can have a new system on the network in under a minute.
Absolutely. However, those are experienced users having a framework for doing their Linux cloning. Think of potential new customers doing a proof of concept or similar installing RHEL for the first time. IMHO, chances are quite high, they use the distro installer anaconda and we should make their life as easy as possible.
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
Internal address: Kst. 3282, 71032-06-022
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
Steffen Maier wrote:
John Summerfield wrote:
fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people generally don't use the vendor's install procedure very much, atm they're discussing procedures to clone and customise systems, and some discussion as to whether it's better done in VM or in Linux: the Linux proponent has just said he can have a new system on the network in under a minute.
Absolutely. However, those are experienced users having a framework for doing their Linux cloning. Think of potential new customers doing a proof of concept or similar installing RHEL for the first time. IMHO, chances are quite high, they use the distro installer anaconda and we should make their life as easy as possible.
Certainly, and part of that would be the friendly fellow from IBM pointing out the Red Books and the Linux-390 list.
Additionally, for such folk Novell has a starter system. I expect it's like the starter systems and such I used 20+ years ago for OS/VS VS1 (or its successor, I recall something more complete, but forget what IBM called it. Express something, I think). Almost anyone with VM, OS/DOS-type experience should be able to restore to disk and IPL it.
Jeremy Katz wrote:
On Wed, 2008-07-23 at 15:00 -0500, Mark Hamzy wrote:
On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:
Mark, can we just always reboot in linuxrc.s390 and skip the logic to
And if you have a failure to install the bootloader on a lot of other platforms, you end up booting back into the installer also. So s390 isn't special here.
The reipl support is not about the installation of a bootloader. IMHO, these are two different things. I agree that in case of failure to install the bootloader it makes sense to boot into the installer again. However, reipl configuration may fail due to certain versions of hardware and software (in case of z/VM) as explained in one of my other postings. Even in the case of failing reipl config, manual reboot by the user still works and should be done.
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
Internal address: Kst. 3282, 71032-06-022
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@lists.stg.fedoraproject.org