Bootscripts and error handling

Nathan Coulson conathan at
Fri Jul 8 17:03:10 PDT 2011

On Fri, Jul 8, 2011 at 3:55 PM, Bruce Dubbs <bruce.dubbs at> wrote:
> I've been working on bootscripts.  Basically, I'm rewriting them to get
> a better understanding.  I may end up throwing them out completely but I
> want to discuss the issue of error handling.
> There are three bootscript files that use the
>   read ENTER
> construct:  checkfs, udev, and functions.
> In the case of functions, the construct is used in print_error_msg that
> is only called from the rc script.  It is not a fatal function.
> In checkfs, the construct is called in three different places.  In two
> places it is followed immediately by a halt and one place a reboot.
> In udev, the construct is called in two places. In both cases, it is
> followed by a halt.
> The question is how to handle these errors in a headless or keyboardless
>  system.  The problems identified are pretty serious and it's doubtful
> anything could be written to the disk.
> I'm thinking about moving the messages/halt/reboot to the functions
> script so they all can be handled in one place.   If we then have the
> functions script do:
> [ -e /etc/sysconfig/init_params ]  && . /etc/sysconfig/init_params
> then when we want to optionally stop for the user to read something:
> # Wait for the user by default
> [ "${HEADLESS=0}" = "0" ] && read ENTER
> To disable the need for a keyboard entry, the /etc/sysconfig/init_params
> file would define the following:
> --------
> The above would only apply to LFS bootscripts.  I can't think of
> anything from BLFS or a third party that would need to stop the boot
> sequence to wait for the user to read a message.
> Should we integrate this into the LFS bootscripts?
>   -- Bruce
> --
> FAQ:
> Unsubscribe: See the above information page

sounds like a sane approach.

BTW, In the far past, I recall it halting (w/o allowing us to
continue) with the stty sane.  Never did understand why, but that
issue seemed to have evaporated.

Nathan Coulson (conathan)
Location: British Columbia, Canada
Timezone: PST (-8)

More information about the lfs-dev mailing list