Foreword
I started to take it upon myself to speed up the boot process of my secondary workstation, but I decided I needed a way to quantitatively measure the boot process. I wanted to document my results in a way that could be reproduced, and I wanted to be very methodical in the process.
Setup
My secondary workstation is a Dell GX270 with a 3.0GHz P4 processor, 1GB of RAM and a 40GB Seagate ST340014A hard drive. I blew away the existing install, reinstalled Feisty with the default settings, specified my static IP, and updated via apt-get. The kernel is 2.6.20-16-generic #2 SMP i686.
To measure the boot times, I turned Automatic Login on for my user account. Then I made a file called imup.sh in my home directory, with the following contents, and put it in my session startup:
nc mymaindesktop 89 -z
This meant that when GNOME was up and running, my secondary desktop would attempt a TCP connection to my primary desktop. This I can quantify. First, I got a root shell by executing ‘sudo -s,’ and then I typed the following command into my console:
time nc -l -p 89 -vvn
I don’t execute it just yet. I hit the power button on my test machine and the Enter key on my primary desktop simultaneously. When the test machine hits the desktop, I’m presented with output similar to the following on my main desktop:
listening on [any] 89 … connect to [10.1.1.1] from (UNKNOWN) [10.1.1.2] 30958 sent 0, rcvd 0 real 0m46.919s
user 0m0.000s
sys 0m0.004s
So at this point, I know it took about 47 seconds to boot all the way to the GNOME desktop from a cold start. I repeat all my tests 3 times to make sure that the number is accurate. In the descriptions of each boot, save the Base Install, I’ll try to link to a page detailing how to replicate my process.
Some Results
Base Install (Fresh install, updated via apt-get): 47 seconds
Prelinking installed and run: 49 seconds
Disabling hplip: 47 seconds
Disabling various services: 49 seconds
(I also disabled brltty in the above)
Running prelink again after the above: 47 seconds
Bootchart
At this point, I installed bootchart via apt-get ( sudo apt-get install bootchart) and rebooted.
Then I began to examine just what was using up the most time during my boot process.
It looks like under S40Networking, dhclient is being run and then executing a sleep. Funny because I have specified a STATIC IP. So I went into /etc/network , and edited out all of the extra interfaces from /etc/network/interfaces. Only eth0 and lo remained. I also went into all of the directories inside /etc/network and moved all of those files to backup folders elsewhere. I don’t use avahi and I don’t use WPA, so those things shouldn’t run, right? So I removed those and went along my way.
But wait, bootchart tells you how long it took to boot! Which, after removing those files, appears to have decreased from 30 seconds to 24 seconds. Now we’re getting somewhere, and this article is going to take a different turn.
Avahi
Next, remember how I removed the avahi bits from /etc/network/? Avahi is still running. I don’t care to discover what’s on my network, and I want it to go. I just have to edit /etc/defaults/avahi and set that =1 to =0. If all goes well, it won’t run next boot.
25 seconds.
Oh well.
More Results
Next, I enabled concurrent init shell scripts.: 24 seconds.
I disabled usplash: 24 seconds
I reprofiled the bootup and restarted: 20 seconds
I went into /etc/readahead/ and edited every line containing hlip, blue, or avahi from the files boot and desktop: 20 seconds
I disabled readahead altogether: 25 seconds
Turned readahead back on, reprofiled: 20 seconds
Trying to optimize readahead
Next, I sorted through the /etc/readahead/boot file and sorted out the list by time last accessed.
Which did nothing, because readahead had accessed them all in the order that they were in /etc/readahead/boot.
So I disabled readahead, rebooted, and went back through and sorted the list again. Some of the files had not been accessed in the past 24hrs, or in the last boot, so I omitted those from the list.
This made the boot time 22 seconds. Oops. Maybe I shouldn’t have omitted those files that haven’t been accessed in the last 24hrs.
Out of the blue, I removed ipv6 from the modules list: 21 seconds
So I sorted the original list again, and didn’t prune anything from the list: 21 seconds
I put the original list back: 20 seconds
I disabled the kinit resume function: 20 seconds
I blacklisted xpad, the Xbox controller module: 20 seconds
Next, I went into the BIOS and disabled all of the stuff I didn’t need, like the floppy controller, serial ports, parallel port, etc: 20 seconds
I disabled the wacom lines in xorg.conf, and turned on boot logging: 20 seconds
I noticed that something to do with Wacom was still being loaded, so I went through all of the /etc/rcX.d directories and disabled them: still at 20 seconds
I don’t have a printer connected to this computer, nor will I ever, so I disabled cups: 19 seconds
I found that /etc/inittab does nothing now. The extra ttys are spawned in /etc/event.d, so I removed tty3, 4, 5, and 6, then rebooted: 19 seconds
Next, since I have a static IP and a completely static connection, I removed the packages for dhcdbd, network-manager, and network-manager-gnome, then rebooted: 19 seconds.
I generated another initramfs: 19 seconds.
I could go further, since I have no need for sound, or anacron, but at this point I’m severely I/O limited, according to the bootchart. Maybe 90% of the boot process is spent in I/O wait. I doubt disabling those will even shave a half second off of my boot times.
Just for kicks, I removed bootchart and tried out my old method three times: It takes 40 seconds to get to a desktop from the moment I push the power button. Not too shabby for older hardware.
Conclusion
All in all, it looks like the best speedups to get are from:
1. Reprofiling with readahead
2. Setting a static IP for your network (if you’re a desktop user like me)
Everything else was just a waste of time. At a later date I may reinstall, then simply try the reprofiling and disabling DHCP, and see how long that takes. If I had a dual-core CPU, I may have seen a benefit from concurrency. At this point it seems like the easiest way to speed up boot even more would be to use a faster/dual-core CPU or get faster disks. Maybe I’ll bring in my Seagate X15 from home and give that a shot.