Optimising Slackware Boot Time (part 2).

21 02 2009

Welcome to part two of my in depth guide to speeding up the Slackware boot time. Time to install the OS…

Installing the OS

I’m not going to walk you through this, as there are enough resources online for doing this (try here). Basically, I use the verbose mode, and carefully decide what I will and what I won’t need. Slackware comes with about 15 of everything by default, so just limit it to one text editor, no office suite, ignore all X Windows based networking components etc… I tend to include everything in the /l folder, because it adds up to very little usage of space, but allows the addition of packages without too much hassle if necessary. Like I say… If you don’t NEED it, don’t install it. If you are a newbie to Slackware be particularly careful with the x/ folder, as you can b0rk it extremely easily… If in doubt, say yes (that’s my motto, anyway!).

The interesting bit begins

Once you’ve booted your new system and logged in as root, the first step is to download a kernel, or at least reconfigure the existing source. Yet again, a full description of the process involved here is way beyond the scope of this article. Check out Alien Bob’s wiki page on it here if you’re not sure what you’re doing.

Ok… The key with building your kernel is ONLY compiling into the kernel things your system requires. The default kernel has support for almost everything – hence it’s name being vmlinuz-huge-smp. This may take a few attempts to get it spot on (for few attempts read BLOODY AGES), so make sure you leave the previous kernel selection in your lilo.conf. Generally, I’m happy when the kernel’s no bigger than about 1.5-2Mb, as the time LILO will take to load a kernel of this size is negligible.

InitRD/InitRAMFS

If you use such things as the bootsplash patch, you will require an InitRD or InitRAMFS. These are just as hackable as the rest of the operating system. The file you will want to look at in your InitRD is the file called simply “init”. This is the script which is run on loading of the initrd.

The idea with hacking apart your init script is to remove any lines in the script which you do not need. If you don’t need RAID support on boot take out the mdadm clause, if you’re not loading any kernel modules then delete the /lib/modules clause… All of these modifications will make a small difference… It may only be a tiny difference for each removal, but that’s all we need.

Also, when leaving sections in, try to avoid leaving sections within conditional clauses. As an example, if you require LUKS filesystem encryption in your initrd, then it is quite likely that the cryptsetup executable will be executable, and that you know that your enrypted volume is valid. The original section looks like this:

CRYPTDEV=""
if [ -x /sbin/cryptsetup ]; then
# If we find a LUKS device now, it is on a real block device:
if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
CRYPTDEV=$(basename $ROOTDEV)
echo "Unlocking LUKS crypt volume '${CRYPTDEV}' on device '$LUKSDEV':"
/sbin/cryptsetup luksOpen ${LUKSDEV} $CRYPTDEV /dev/systty 2>&1
if [ "$CRYPTDEV" == "$ROOTDEV" ]; then # scenario 1
ROOTDEV="/dev/mapper/${CRYPTDEV}"
fi
fi
fi

This can be happily hacked to pieces in the following manner:

CRYPTDEV=$(basename $ROOTDEV)
/sbin/cryptsetup luksOpen ${LUKSDEV} $CRYPTDEV /dev/systty 2>&1
[ "$CRYPTDEV" == "$ROOTDEV" ] && ROOTDEV="/dev/mapper/${CRYPTDEV}"

Notice how a simple if conditional can be cropped right down. There is only a need to use the full clause if there are a number commands of or a single complex command to run on validation of the conditional. This is only an example, of course, and your system may well not use this exact version, but if you apply this kind of logic right through the file, you’ll end up with a very compact InitRD.

It may sort of go without saying, but once you’ve finalised your InitRD and added it to your LILO configuration, reboot and check that it works.

This section of the guide may appear quite small and self explanatory, but it may well take you a lot of trial and error before you’ve got a usable system.

See you tomorrow!

I’m going to call it a night at this point in the guide and post the last section of it tomorrow where we’ll look at hacking your rc scripts into tiny little pieces.

n00b

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: