bootscript logging conundrum

DJ Lucas dj at
Tue Apr 19 21:36:30 PDT 2005

Archaic wrote:
> Presently, the only logging that happens seems to be post-sysklog
> starting up. This seems to have very limited usefulness as it will miss
> any errors about why the net may not have come up or why fsck may have
> failed. So this email is meant to ascertain if there is any support for
> continuing the maintenance of extra code logic, and if there is a way to
> extend it to actually logging all or most of the bootscript action, or
> if it should go away in favor of cleaner and smaller code.
> Does anyone have opinions?

I would like to see it stay as it has actually proven useful on both
headless and remote systems.  The hack that I had proposed off list,
after further review and slight modification, is actually a legitimate
way of handling the events prior to sysklogd starting.  rc mounts it's
own tmpfs, used to capture the temporary bootlog file, which is then
appended directly to the existing bootlog just before syslogd starts,
after which, it can still be used for other bootscript accounting info
and umounted when rc finishes it's job.  BTW, just to clarify, I had
refered to it as a 'hack' myself, not Archaic.

Assuming that users follow the FHS, /mnt is the perfect location for a
tmpfs during boot.  IOW: /mnt is used for a single temporary mount
point.  Unfortunately, the spec contradicts itself saying that /mnt is
the mount point, but the content of the directory is a local issue. :-)
 Not to mention it's common misuse according to today's newer spec (IE:
multiple mount points).

Of course, it could really be any directory located on the rootfs.
Unfortunatly, the logical placement for my taste, a subdirectory under
/etc/rc.d/, would _not_ be FHS compliant.  It'd have to go elsewhere
unless we educate users as to /mnt's purpose according to the FHS.  As
an additional bonus, it ditches the real filesystem write that I had
used for the first interactive rc which did not work with a read only
root.  Not many people showed interest in the interactive boot
capability, so it was not modified furthur except for my own use.

-- DJ Lucas

More information about the lfs-dev mailing list