Avian’s Blog

After reading that it's possible to boot an Eee PC into Linux in five seconds I started tweaking Debian installation on my 701 to see how close I can get to that impressive time. I didn't want to completely throw away any chances of cleanly upgrading packages so I tried to stay away from radical changes to the system like using a static /dev instead of udev for boot and patching X11.

Currently my boot time stands at 32 seconds (that is from the moment I press the power button to the GDM login screen). Far cry from the instant on action of Arjan van de Ven, but a bit better than a couple of minutes you get with a stock Debian install.

Out of those 32 seconds, 8 seconds are spent in the BIOS and GRUB boot loader. There's nothing I can do about those.

I reduced time spent loading the kernel by compiling a custom kernel. I started with a stock Debian kernel config (I'm currently using 2.6.23 because of all the problems with newer versions) and removed initrd (compiled-in SATA and filesystems support) and code that doesn't make sense on Eee like SMP support.

To reduce the time spent in the early boot I followed instructions on the Debian Wiki. I linked /bin/sh to /bin/dash, parallelized startup scripts and removed all services that aren't necessary for the system. I skipped readahead installation since I don't think it would help much with the low seek times of the solid state drive.

Then I installed bootchart to see if there is any more low hanging fruit. One thing that bootchart showed nicely was a sleep in /lib/udev/net.agent. This shell script is run by udev for every new detected network device and checks for any autoconfiguration directives for it in /etc/network/interfaces. For some reason it waits for loopback device to get accessible before doing anything, which means that on boot it halts udev initialization until kernel decides to bring lo up. Since I don't think I'll be hot-plugging any network devices into my Eee in the near future I commented out the relevant line in /etc/udev/rules.d/80-drivers.rules. This removed several seconds.

So, right now the boot chart looks like this:

You can see that the majority of time is spent in the kernel. Either in the boot process (before bootchartd started, left of the edge of the chart, or in module initialization (modprobe processes on the chart). There is little more I could do. Even with more aggressive boot parallelization further gains would be small. You can also see that CPU is constantly at 100% and that there is practically zero I/O wait time during boot, so my assumption about readahead was probably correct.

There is one thing on this graph I don't understand though. I replaced modprobe binary with a wrapper that logged modprobe start and end times (that's why the chart shows modprobe and modprobe.orig processes) to see exactly which modules are hogging the machine. bootchartd here shows that each modprobe takes several seconds, but my log shows that each modprobe exited after less that 100 ms. So either modprobe forks the process or bootchart gets confused somehow.