[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: making bootup fsck more user-friendly



On Sun, Jun 15, 2008 at 4:46 PM, Andrew Reid <reidac@bellatlantic.net> wrote:
> On Sunday 15 June 2008 06:16, David wrote:
[...]
>> Finally, Exim MTA was setup by default on my PC, but I disabled it's
>> init.d script. Reason: My PC is not connected to the internet a lot of
>> the time, so I get a "MTA starting..." message that stalls the startup
>> for a long time. I really hate long delays during startup :-) (see
>> also: Apple Talk service installed by default. wth?)
>
>  Now that you've admitted editing an init.d script, I can no longer
> resist mentioning my rather involved and hack-ish solution.
>

Thanks for the suggestion.

I researched it a bit more.

>From the bootparams(7) manpage:

       Anything  of the form 'foo=bar' that is not accepted as a setup
function as described above is then interpreted as an environment
variable to be
       set.  A (useless?) example would be to use 'TERM=vt100' as a
boot argument.


Therefore, a kernel arg like this in menu.list should work:

WIZZARDX_FASTBOOT=1

And in /etc/init.d/checkroot.sh (after /fastboot check):

    if [ "$WIZZARDX_FASTBOOT" == "1" ]; then
        [ "$rootcheck" = yes ] && log_warning_msg "WizzardX Fast boot
enabled, so skipping file system check."
        rootcheck=no
    fi

And in /etc/init.d/checkfs.sh, change:

        #
        # Check the rest of the file systems.
        #
        if [ ! -f /fastboot ] && [ ! "$BAT" ] && [ "$FSCKTYPES" != "none" ]

To:

        #
        # Check the rest of the file systems.
        #
        if [ ! -f /fastboot ] && [ ! "$BAT" ] && [ "$FSCKTYPES" !=
"none" ] && [ "WIZZARDX_FASTBOOT" != "1" ]


While not very clean (imagine if every boot variation had it's own
grub/lilo line), it sounds like a good work-around until (if) sysvinit
has an official way of bypassing fsck during the boot. The main
supported method seems to be to run 'shutdown -f' to create /fastboot.
The assumption being that you're running a server which is on 99% of
the time, rather than a desktop where you don't always know (during
shutdown) if you will need to bypass harddrive scans on the next boot.

I think that with the uptake of more Debian (and Debian-derived)
installations on desktops, this becomes a more important
consideration.

David.


Reply to: