First of all, let me say that the resumable on-error shell in the latest
preview is made of purest awesome. It makes troubleshooting so much easier.
FTW! :D
But this got me thinking - when something goes wrong with the rootfs, it's
still hard to debug. The machine will just stop, even if the initroot is
still hapilly ticking away underneath, albeit with a broken finalroot
somewhere off it.
So, how about having a getty running on, say, VT12, pointing straight at
the initroot strap? The extension of this would also be, for ease of use,
having sshd listening on an alternate port in the initroot. Granted, sshd
would add to the undesirable bloat of the initrd so it should be optional,
but it would be useful for those of us who are both lazy enough to not want
to walk to the rack when things go wrong and at the same time poor enough
to not have remote console cards in all the servers.
I know the feature creep inevitably ends up with thoughts of "Wouldn't it
be cool to also add X and [KDE | Gnome]", but is the getty at least deemed
reasonable? I'm happy to look into implementing such a thing, but will need
some pre-emptive pointers on where best to hook it and suchlike. I would
guess it would best be fired up just before chrooting into the final root.
The main reason I'm thinking about all this is because I have a really
annoying lock-up and shutdown with glusterfs root - it all stops just after
"Sending all processes the TERM signal...", even though I have added
exclusions for the glusterfs daemon, and it's impossible to debug without a
lower level handle to see what is running and what isn't.
On a separate note - at what point does the initroot get dumped to the
designated disk partition? The reason I ask is because I can't seem to find
the logs I expect in /var/comoonics/chroot/var/log/gluster so I'm guessing
that it gets shifted after the glusterfs daemon starts up, but I'm not
sure. Again, having an initroot getty might help get to the bottom of the
problem...
Gordan
|
