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: