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:
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...
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 <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
