RFC - bootscript error reporting
Bill's LFS Login
lfsbill at nospam.dot
Thu Jan 29 12:18:10 PST 2004
On Thu, 29 Jan 2004, James Robertson wrote:
> Jeremy Utley wrote:
> > On Wed, 2004-01-28 at 15:11, James Robertson wrote:
> >>I really like this. As others have posted, not all errors are the same.
> >> We would need to come up with some kind of system to trap errors from
> >>the different programs that are called within boot scritps. Or if that
> >>is too hard, then at least some system to agree on a "criticality" of
> >>certain Sxx scripts. Kxx scritps are important, but not as critical IMO
> >>as Sxx scripts when entering a certain rc level.
> >>Also, there needs to be a mechanism in place (in the bootscritps) to
> >>notify the administrator when he/she came back to the console that a
> >>reboot occured at such-and-such a date and time and what the result of
> >>any messages were. This is especially important for the ones that get a
> >>timeout value and move on. Can we use mail for that? I don't know, I
> >>am not _that_ smart with Linux yet.
mail may not be available at the time the error is detected. So some
logic for temporary storage of the post would be needed. If FS
corruption is the problem, that may not be available.
> > My thought was actually much simpler, but it can only be done after the
> > system is in a read/write mode. Have the bootscripts, as part of the
> > boot process, write to /var/log/bootscripts.log, any failures or
> > warnings that come about as part of the boot process.
Same FS corruption concern.
> > Actually, now that I think about it...someone with more knowledge than
> > me answer this - would it be possible to have a fifo device (via mkfifo)
> > set up someplace where we could write messages to prior to the
> > filesystem being mounted in r/w mode, then at S99log, cat the contents
> > to that fifo into a log file?
> That seems like a good idea. Also, can we take advantage of sysklogd?
> >>On the simple pause idea, the time to pause needs to be easily
> >>changeable in a /etc/sysconfig file of some kind. Everyone will have a
> >>different opinion as to how long they want the boot process to pause
> >>before continuing.
Just as an alternative, I also suggested that the time can be set in the
script itself if creating it from a "here" document. The config file is
better for the lfs-bootscripts component though.
> > Good idea - will definately file that one away for future reference!
> >>I am also not sure that LFS needs to be concerned with headless or
> >>non-administrator-local machines. I would love it in my production
> >>environment, but most of our readers reboot at the console. The issues
> >>Jeremy brought up are more about that. The easiest thing is simply to
> >>fix the scritps to support the enter key or change the text to say CRTL-J.
> >>I am only throwing this out for thought. I actually would love to see
> >>Jeremy's idea put into the scripts.
> > While in a lot of ways, I agree, James, there are a number of people who
> > are actually using LFS-based systems in a production enviornment. I
> > know that I myself have gotten bit by this one on a number of occasions,
> > and it's very annoying when you have to drive 45 minutes to the
> > datacenter, or drag a NOC technician away from their TV long enough to
> > punch the reset button. One of the key advantages to Linux (at least
> > for me) is the ability to remotely administer the machine, and making
> > this change to LFS actually makes that possible.
> That is why I stuck it inside an opinion. I was looking for a scope
> topic. I also use LFS in a production data center, so I am on the same
> page as you on that. The features you are looking for are awesome.
> Don't get me wrong. I probably should not have even mentioned it at all
> as I want the same features you want and since you are writing the
> new/updated scripts, you can add those "enterprise" class features in.
> I know I will love the chance to test them out. I just wanted to make
> sure we stayed in scope. Looks like we are.
Not really. LFS does not *target* headless machines, workstations,
gateways, content servers or any of that. If the enhancements apply to
what LFS does target and others benefit as a sife-effect, I see no
But in all honesty, much of what we see being discussed here is BLFS
IMO, the lfs-bootscript goals for this effort should be confined to
getting the basic bug resolved: letting a boot process proceed in a
rational fashion and properly handle the user interface so that the user
can more easily proceed.
> >I can see now we could
> > actually integrate an option like this into your previous request, like
> > so:
> > if [$PAUSE_DURATION == 0]
> > then
> > read $i
> > else
> > sleep $PAUSE_DURATION
> > fi
> > Comments?
> Yea, like it.
NOTE: I'm on a new ISP, if I'm in your address book ...
Fix line above & use it to mail me direct.
More information about the lfs-dev