Carlos E. R. wrote:
Specifically, on virtually every system, at times, messages just wiz
by on a bootup (especially after upgrades). Problem is that these
init-boot-script error messages are not saved anywhere.
No? Did you look in /var/log/boot.msg?
---
Yes. It contains some of the output, but I'm not sure it's complete
-- it certainly isn't "the same" -- i.e. boot.msg contains any other kernel
output as well as specificcontent (like full argument lists of each service
-- a bit over 400 characters each.
It is possible the error messages are all in boot.msg, but its just
hard to see them buried in the other kernel-log messages and the different
formatting used to relate information (for example, color red for failures).
What I'd __like__, is a log of exactly what appears on the console
that is generated by the boot scripts. I don't know for sure, but I don't
think it is trivial since when the boot-scripts start and switch all
output to "/dev/console", there are no r/w file systems available to
to, say, log to using "tee".
If 'tee' works then, I think the 'boot' script might have to
try "assuming" that it could mount a temporary "ramdisk" and log to
it until the file systems are available. Then a boot process could
copy what's on the ram disk, then append the rest of the console output
up to the point of displaying the login prompt.
I first tried logging to the current disk, but it's still mounted
'r/o' at that point. Rather than going off and trying to find my own
hack^h^h^h^hworkaround, I thought surely someone else has wanted
to be able to view and/or store the console (without redirecting it over
a serial line, which is one way of getting what I want, but isn't always
convenient to setup) -- and I should ask on list...otherwise, I'm
guessing that I could try the ramdisk "workaround", or just
remount my rootfs "rw" (I'm not sure why I'm booting it "R/O" -- habit
I suppose -- and that's the default in most setups). But if one is
using a journalling filesystem like "XFS", where "fsck" is a "noop",
there isn't alot of reason to start up "R/O" that I can think of.
But but but -- its just so "non-standard" -- it feels "wrong" -- but I
can't think of any reason why not to make it "R/W" from the start
anyway (in the case of "fsck" being a 'noop" on a file system).
Thanks for the suggestion(s)...
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
