Re: Re: Reipl support (David Cantrell)

[Jeremy Katz <katzj redhat com>]

(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