Howto: 16-second boot on 550Mhz Celeron with Crux

I’ve mentioned a few times that my Thinkpad boots in under 16 seconds to an Openbox desktop, but I haven’t ever really shown how. It takes a little while to arrange a system that runs that fast, but if you’re interested and you have a few days to spare, these are the best suggestions I can make.

Before you try something like this, you should be able to handle everything described in the Crux Handbook, including setting up a network, building a custom kernel, configuring your hardware and partitioning a system drive. And of course, all from the command line. Extra points are awarded for style, such as setting up your wireless connection while you’re still in the live environment. πŸ˜‰

Please be aware that this is definitely not a beginner’s task. Remember when you first installed Ubuntu and everything just magically worked? I can guarantee you, with 99 44/100 percent certainty, that at the first boot everything will not work — if it boots at all. This is the kind of project where one small button buried deep in a nested menu somewhere will cost you hours of compiling, hours of troubleshooting and days of kicking yourself in the behind.

For partitions, I use a simple four-part scheme — something like this.

/boot 32MB ext2
swap 128MB
/ 4096MB ext2
/home (remainder) ext2

Make sure you set the noatime flag when you build your /etc/fstab file too. It helps.

Most of the magic happens in the kernel configuration, which should make sense — a custom kernel is still the best and most effective way of speeding up any system, and any distro. Personally I disable almost everything I can think of, although that’s going to vary from machine to machine. For the record, this is the hardware I’m using.

  • 550Mhz Celeron (Coppermine)
  • 192Mb PC100
  • 4Mb Silicon Motion, Inc. SM712 LynxEM+
  • 20Gb 5400rpm Hitachi hard drive HTS548040M9AT00
  • LG CRN8241B 24x CDROM
  • 2x USB 1.1 ports, one side and one rear
  • 800×600 SVGA LCD
  • Intel 8440MX AC’97 Audio

Network is from an unencrypted access point to a Linksys WPC11 v3 PCMCIA card. This is an 11b card that uses the Prism 2 chipset — in other words, I don’t need firmware or special binary packages to get the network up. If yours is different, you’re on your own.

My kernel configuration takes everything — absolutely everything — out that isn’t essential. I find it makes the system faster, and takes less time to compile. That will be important if you’re using a similarly (or even more so) slow machine. So here’s what I suggest for, downloaded in the live environment, and you can decide if it’s to your liking:

Under general setup I disable …

  • incomplete code or drivers (it makes setup go by a little quicker)
  • optimization for for size
  • control group support
  • group CPU scheduler
  • create deprecated sysfs files
  • kernel-user space relay support
  • heap randomization
  • profiling support
  • OProfile system profiling and
  • Kprobes

In enable the block layer disable …

  • support for large block devices (when they make a terabyte drive for my 550Mhz machine, I’ll re-enable it)
  • anticipatory and deadline I/O schedulers (which makes CFQ the default)

For processor type and features I …

  • disable high resolution timer support
  • disable SMP support
  • disable single-depth WCHAN output
  • set the subarchitecture type to PC-compatible
  • set the processor family to Coppermine
  • disable HPET timer support
  • disable machine check exception
  • turn off high memory support
  • disable Compat VDSO support

In power management options I …

  • disable legacy power management
  • enable supend-to-RAM and standby
  • disable hibernation (when you boot in 16 seconds, do you really need hibernation?)
  • For ACPI
    • disable all deprecated options, as well as the future power /sys interface
    • disable battery, since the machine doesn’t have one
    • disable debug statements
  • enable APM and the real mode APM BIOS call (this works for shutdown for me)
  • disable CPU frequency scaling, since it will be on AC at all times
  • disable CPU idle PM support

The bus options I use are …

  • disable deprecated pci_find_*
  • enable PCMCIA/Cardbus support and
    • disable ioctl
    • modularize yenta-compatible support

Under networking

  • disable IPv6
  • and wireless options …
    • modularize the deprecated 802.11 stack

For block devices under device drivers

  • disable normal floppy disk support

Disable all misc devices.

For ATA/ATAPI/MFM/RLL support …

  • disable legacy /proc/ide/ support
  • disable probe IDE PCI devices in PCI order
  • enable Intel PIIXn chipsets support, and nothing else

For SCSI device support

  • disable SCSI CDROM support
  • disable all SCSI transports
  • disable all SCSI low-level drivers

Disable all SATA and PATA drivers, all RAID and LVM, Fusion MPT, Firewire and Macintosh support.

For network devices

  • disable all ethernet devices
  • under Wireless LAN
    • enable IEEE802.11
    • modularize the Hermes chipset and Hermes PCMCIA card support
    • modularize IEEE802.11 for Host AP and the Prism2 PC card options

For character devices, disable HPET event timer and hardware random number generator core support.

Under multimedia devices, disable DVB for Linux.

For graphics support and /dev/agpgart, enable only the 440BX option.

For sound, I use ALSA and enable the AC’97 option under PCI devices. I also diable the OSS options.

Most of the USB options I keep because they allow you to use USB flash drives. I do however, disable USB 2.0 support (this machine is 1.1 only), and USB printer and monitor support under USB support.

Under file systems I only leave second extended filesystem enabled. Everything else — including NFS — gets turned off. I also …

  • disable dnotify
  • disable inotify
  • disable kernel automounter version 4

Under cryptographic API, I make sure everything is compiled into the kernel, and not modularized. Then I disable all hardware crypto devices.

Finally, disable all virtualization. I don’t see a 550Mhz Celeron as much of a platform for virtualizing. πŸ˜‰

And that’s about it. I’m sure there’s more that could be turned off or disabled, but it’s tough to test everything in there. πŸ˜€

Next step, I set up /etc/rc.modules to probe orinoco-cs and yenta-socket:

/sbin/modprobe yenta-socket
/sbin/modprobe orinoco-cs

Rather than use the /etc/rc.d/net daemon, I write the network connection sequence into /etc/rc.local, like this:

iwconfig eth0 mode managed essid any
ifconfig eth0 up
dhcpcd eth0

For some reason, the net daemon doesn’t behave for me like it’s supposed to under wireless connections, when I compare it to the wired connections I’ve tried. That’s probably my fault, but this way works perfectly for me.

I use Grub over LILO on my Crux systems. Grub is in the opt repository, which means you have to add it manually to the system, instead of just selecting the core packages. I also add nano from there, because vi just … well, never mind. πŸ˜›

When you edit your /boot/grub/grub.conf file, remember that the partitions are separated in this system — not as subdirectories. In other words, you can probably delete the “/boot” part from the kernel lines, and change the /dev/hda1 to /dev/hda3 instead. Setting up Grub for me is less complex than what the handbook suggests; I just



root (hd0,0)
setup (hd0)

That does it for me. If you have a stranger arrangement, you’ll have to adjust that for your flavor.

At this point, your system should boot. Cross your fingers and give it a try.

If it’s up and working, you can continue by setting the compilation flags in /etc/pkgmk.conf.

export CHOST="i686-pc-linux-gnu"
export CARCH="i686"
export CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer -ffast-math"
export CXXFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer -ffast-math"

If “unsafe” CFLAGS are something you worry about, you can use the safe ones from the Gentoo wiki. These haven’t given me any problems thus far. (Note: Except for Firefox, which had to be recompiled with the safe flags. Remember that some programs will work this way, and others won’t, and I don’t have any advice for you on how to predict the results.)

I disable the footprint check since it tends to halt software installations at inconvenient times.

For /etc/prt-get.conf, I set the logging feature and “prefer-higher” as default options. Since there’s not a lot of screen space available, the list of installed or failed packages can get kicked up off the screen. The logs tell me if something went wrong, at least.

I usually start the software update process at this point. Since my router’s settings block rsync, I use httpup to sync with the ports, and then start a system-wide update. That can take about four hours, depending.

From there, start building X, the drivers and the software you want. Configure X with (of all things) X -configure, and make the directory at /etc/X11 before moving the generated file to it’s new location under its new name (xorg.conf, that is).

I use the Arch Linux-style autologin. I also change the runlevels for C1 and C2 to 2345 — like this:

c1:2345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux

I disable all the other terminals; I just don’t use them. And I set the multiuser script to start at those same runlevels, like this:


Otherwise, your autologin doesn’t spawn terminals, or doesn’t kick into graphical mode. And of course, while I’m in there, I change all the “wait” terms to “once” — giving it one last kick in the pants. πŸ˜€

Once everything is how you like it, you can boot into a live CD once more and reoptimize the directory structures with this command, from a terminal.

e2fsck -fD /dev/hdXY

The drive assignments will change according to the live environment, and make sure you don’t run that on your swap partition. πŸ™‚

I think that’s about it. A machine built like this goes from Grub to X in under 16 seconds for me, and that’s by far the best performance I’ve gotten out of any distro I have ever found, with any and all of the tweaks I can find. Just out of curiosity, let me know if it works for you too. πŸ˜€

17 thoughts on “Howto: 16-second boot on 550Mhz Celeron with Crux

  1. Freduardo

    This looks very good!
    Very well written and very tempting to try out ;).

    I’ve been wanting to give CRUX a whirl on my old laptop, ever since I’ve read about it on your blog. It’s an old Dell Inspiron 4000 (192 mb RAM, 700 MHz Pentium 3 (Coppermine)).

    Now, because I’m right in the middle of exams I probably won’t have time over the next few weeks. But hopefully I’ll be able to try it out afterwards (my things-to-do-or-try list is getting awfully long).

    If and when I do get around to it, IΒ΄ll let you know how I did.

    Thanks for writing this.

  2. K.Mandla Post author

    Samtek: Not that I’m aware of. I’ve never heard of one Linux filesystem being more inclined to fragmentation than another. Perhaps you’re thinking of journalling, since ext2 doesn’t journal at all?

    For me, that’s a bonus, since I don’t require it and using ext2 relieves an older processor of that burden. I’d much rather keep my critical data off the machine and worry about a USB stick than suffer slow performance with a filesystem that requires journalling.

    To each his own though.

    Freduardo: Give yourself at least a day or two to work out all the kinks, but I can guarantee that a machine like that is going to FLY with Crux. (You might want to give yourself three or four days; I like to set up one system and test it, then rebuild it to make sure I understand everything I did.) The learning curve is definitely steep, but the reward at the end is unbelievable. πŸ™‚


    Wow, very nicely written. I will be recieving an old laptop from a friend of mine soon and plan on trying this out on it. It is a Sony VIAO, PIII, 256 MB ram. I dont know the specs 100% yet but will write back here once I try this, I can’t wait!

  4. timw06

    Do you think this will work for newer (Dual-Core) cpus? I have 1 Gig of RAM and it takes me over a minute to get to an Arch desktop!!

  5. Onyros

    @ timw06: there must be something wrong going there, mate! Arch boots in around 20 seconds in my Thinkpad sporting an old 4200 rpm drive.

    I fear going down the Crux path, I really do. It would probably make me commit myself as much as I did to my Gentoo installation. It wasn’t pretty. I spent more time compiling stuff than using it, and as much as that sounds like a clichΓ© for a Gentoo user, in my case it was (almost) true. OK, take it with as many grains of salt as needed to smoke a codfish, I was obviously exaggerating. I never compiled anything in my life. I don’t even use Linux. Sorry for the inconvenience.


  6. K.Mandla Post author

    timw06: Yes, there’s something wrong with your Arch system if it takes that long to get to a desktop. Even the Gnome desktops I built in Arch only took a minute or so to get to a working environment, and that was on a PIII Celeron.

    Onyros: I’ll admit I spend a fair amount of time compiling, but I honestly don’t think it’s that bad. My systems are fairly lightweight, and I really only recompile a package a few times a week when updates something, or when a core package is improved. It’s no worse that working out of ABS in Arch, really.

  7. N.N.

    Thanks for the tips. Unfortunately I haven’t been able to achieve such impressive results with these fixes as you have, even though I tried them on better hardware.

    I spent two days installing CRUX and applying these fixes on a Dell Inspiron 6000 (1.60 GHz Pentium M, 768 MB 400 MHz DDR2 SDRAM, 60 GB 5,400 rpm IDE HDD), and the best “boot time” (from LILO to X) I was able to get was 30 seconds. 😦 I didn’t try the unsafe CFLAGS, though. Perhaps that’s what makes the greatest difference?

    Next time I’ll try using reiserfs instead of ext2, as I’ve heard that it’s supposed to be a fast filesystem. I won’t be doing another reinstall of CRUX, however. I’m convinced that whatever slight performance advantage that distribution might have over, say, Arch Linux, simply doesn’t make up for the amount of time it takes to install and update it from a 2.4 CD.

  8. K.Mandla Post author

    Sorry to hear that. 😦 It is possible that with newer hardware or a faster system, some improvements like reiserfs are possible. I usually use ext2 because it cuts out journaling, and on the machines I use, it’s a waste of time and slows things down too much.

    I don’t know if the unsafe CFLAGS will make a huge difference for you, if you’re already cutting out a lot of the kernel. I once compiled a “default” kernel, adding only the stuff I needed to make the hardware work, and it was slower than my minimized versions, but not by much. Hmmm. 😐

  9. N.N.

    Contrary to my previous remark I continued to pursue the 16-second boot time with CRUX on my Inspiron 6000 last night.

    Using a partitioning scheme that doesn’t utilize all the available space on the hard drive, formatting root and home partitions with the XFS file system, minimizing the kernel, and applying your /etc/inittab “hacks”, I managed to achieve a “boot time” (from lilo to CLI login prompt) of 17 seconds! I reckon adding X will increase this time by 2-3 seconds, but that’s still a pretty decent time to me. Had to cut some corners in the process, however, as I sacrificed kernel support for ethernet and wireless (the laptop won’t be connected to either regularly).

    I think that it’s possible to reduce the boot time further by configuring and compiling the kernel again, but I tend to mess up pretty badly when I overdo the “minimization”, so I don’t know if I’ll pursue that option.

    Anyway, thanks for the tips once again; they’ve been very stimulating to me. Sorry for my somewhat bleak reaction yesterday. I’ll keep you posted on further progress. πŸ™‚

  10. Pingback: Finally, Grub to Gnome in under a minute « Motho ke motho ka botho

  11. James Mills


    Has anyone tried using an
    alternative init ?

    Has anyone gotten the boot
    time from LILO to X any quicker
    than 16 seconds on recent
    hardware ?


  12. Pingback: The Bucket List. « /home/freduardo

  13. Pingback: We err twice « Motho ke motho ka botho

  14. Pingback: Project #28, Install a CRUX Linux system for i386 | Rage Against The Status Quo

  15. Pingback: Running the kernel ultralight « Motho ke motho ka botho

  16. Pingback: Configuring an ultralight 2.6.34 kernel « Motho ke motho ka botho

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s