RFC - bootscript error reporting

Nathan Coulson conathan at conet.dyndns.org
Wed Jan 28 11:08:17 PST 2004

> Sorry for the top-post.
> All of the suggested ideas are good.
> Now, I'll throw in a new one in (didn't say it's a good one):  an initrd
> with
> enough utilities to (try to) "auto-correct" a broken lfs?
> The scenario is as follows:
> The system is not shutdown properly, it reboots and tries to fsck itself,
> but
> fails.  It writes a /fatal (or something like that) file, and reboots
> itself,
> after running lilo -R "linux initrd=/boot/<initrd.image>
> (Yeah, I'm still using lilo!  This can be adapted for grub, can't it?).
> Only
> problem right now is that if you have a lilo password (shame on you if you
> don't :-) ), you will be prompted for a password.  This defeats the whole
> purpose of the exercise.  I wonder if I pass 'bypass' to lilo -R if it'll
> bypass the password prompt...  gotta try that.
> After the reboot, the initrd does the fsck thingie.  For example something
> like this:
> for disk in /dev/[h,s]d[a-h];do for partition in `fdisk -l $disk | grep
> "Linux
> $" | awk '{print $1}'`;do echo -ne "Checking $partition... " && echo -ne
> "fsck -a -C -T $partition\n";done;done
> (get rid of the second echo to run the fsck.  This is only to verify the
> command)
> Extending this idea, /fatal could be a directory with files in it with
> enough
> information for the rescue mini-system to correct the problems.
> If we want to be clever, we can even check if all modules in
> /etc/modules.conf
> are present in /lib/modules/`uname -r` (especially the driver for eth0),
> etc.
> A whole world of possibilities?
> Now as far as logging goes, I'm of the opinion we should be capturing as
> much
> as possibe of every warning/corrected problem/uncorrected problem to, say,
> /
> var/log/init.log.  But this is tricky because if /var could not be mounted
> rw, where do we write the log? Perhaps write to the ram disk, and if it
> can
> correct /var (or /), mount it rw and dump the log into place?
> This could be the ravings of a lunatic, but it is *possible*
> And on another note, I retract my question regarding rhgb.  Even though
> I've
> made some "progress" in porting it to lfs, I realize it's better dealt
> with
> in a hint than in lfs-book, or even blfs-book.
> IvanK.

I like the idea, but it sounds like a big project...  [I'll look at it
again later], and a bit out of our boundries...  [and yet...]

I do admit, I never did play with initrd's at all, but what I looked at,
was almost a image that was mounted in place of root?

More information about the lfs-dev mailing list