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
/ 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 18.104.22.168, 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
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. :D
Next step, I set up
/etc/rc.modules to probe orinoco-cs and yenta-socket:
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
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. :P
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/hda3 instead. Setting up Grub for me is less complex than what the handbook suggests; I just
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
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.
/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 xorg.conf.new 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. :D
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. :D