Re: Reipl support

[Jeremy Katz <katzj redhat com>]

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:
> >> 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.
> >
> > 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