It is quite a simple change but it makes an Ubuntu laptop to boot 2-3 times faster! What takes the most time during boot in Ubuntu (and many other Linux distros) are DHCP discovery and DHCP timeout that are run by networking startup scripts. This of course can be solved with tweaking the timeout or just configuring a static IP, however this solution is not all that elegant, just because “What if the system needs this particular timeout?” or “What if it is a laptop, and it’s IP cannot be static?”
The idea to solve this is simply to take an advantage of concurrency. So instead of all other boot scripts to wait on the networking script(s) to finish its discovering and “timeouting” during a system boot, these network script(s) could be started in parallel, as separate child processes. This will speed up boot time, since the system should no longer wait on the “networking” to finish.
One thing to understand here, is that networking is not taken out of the boot process – it stills belongs to it (it is its child), and it would still run, and would do its important job – the difference is it would do it in parallel.
Here are two easy steps on howto archive this in Ubuntu (it can be applied to pretty much any Linux/Unix distribution, however the scrips/locations will/might be different) :
Step 1. Find network startup scripts:
cd /etc user@host:/etc$ sudo find . | grep network ./rcS.d/S40networking ./init.d/networking ./network ./network/.interfaces.swp ./network/if-post-down.d ./network/if-post-down.d/avahi-daemon ./network/if-post-down.d/wireless-tools ./network/if-post-down.d/wpasupplicant ./network/interfaces ./network/if-up.d ./network/if-up.d/ntp ./network/if-up.d/clamav-freshclam-ifupdown ./network/if-up.d/ntpdate ./network/if-up.d/avahi-daemon ./network/if-up.d/sendmail ./network/if-up.d/avahi-autoipd ./network/if-up.d/wpasupplicant ./network/if-up.d/mountnfs ./network/if-pre-up.d ./network/if-pre-up.d/wireless-tools ./network/if-pre-up.d/wpasupplicant ./network/if-down.d ./network/if-down.d/clamav-freshclam-ifupdown ./network/if-down.d/sendmail ./network/if-down.d/avahi-autoipd ./network/if-down.d/wpasupplicant ./networks user@host:/etc$ ll ./rcS.d/S40networking lrwxrwxrwx 1 root root 20 2007-05-20 18:48 ./rcS.d/S40networking -> ../init.d/networking
FOUND IT: In this case the netwoking script that runs on startup is “../init.d/networking”
Step 2. Extract “start” case into a separate method:
user@host:/etc$ sudo vi ../init.d/networking
here is a “start case” in the original file:
case "$1" in start) log_action_begin_msg "Configuring network interfaces" type usplash_write >/dev/null 2>/dev/null && usplash_write "TIMEOUT 120" || true if [ "$VERBOSE" != no ]; then if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi else if ifup -a >/dev/null 2>&1; then log_action_end_msg $? else log_action_end_msg $? fi fi type usplash_write >/dev/null 2>/dev/null && usplash_write "TIMEOUT 15" || true ;;
let’s modify it by extracting the “start case” into a separate method so it can be run as a background process on the start up:
here is a “start case” in the modified file:
# adding this method so it can be run as a background process on the start up start_on_boot () { log_action_begin_msg "Configuring network interfaces" type usplash_write >/dev/null 2>/dev/null && usplash_write "TIMEOUT 120" || true if [ "$VERBOSE" != no ]; then if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi else if ifup -a >/dev/null 2>&1; then log_action_end_msg $? else log_action_end_msg $? fi fi type usplash_write >/dev/null 2>/dev/null && usplash_write "TIMEOUT 15" || true } case "$1" in start) # start networking on the background, so it does not slow down the boot time start_on_boot & ;;
Save the file, reboot and enjoy
DONE 
Interesting related articles:
making ubuntu boot in 19 seconds
understanding bash fork bomb
Way over my head =P
@everett
open the networking startup scripts with your text editor of choice as sudo/root e.g.:
sudo gedit /etc/init.d/networking
Replace the original start case code with the modified code in the above post. (Make sure you make a backup!) Save and reboot.
@zaid,
Thank you for explanation – I missed this comment
– Toly
Thanks for the tip
Mate -
Nice idea, thanks for posting.
Jameson
It didn’t work for me. My boot time reamains 56 seconds after the modification.
@Anselmo,
How do you have your network configured? Is it getting a static IP, or asks DHCP server for one? How many cards do you have (lan + wifi)?
The above method of “paralleling” processes works on several boxes for me.
– Toly
It asks a DHCP server for one, and I have two interfaces: lan and wlan.
Can you post your “/etc/network/interfaces”?
The thing to also check is while booting up, click “Ctrl+Alt+F8″ (can be “Ctrl+Alt+F7″ depending on the configuration), and see what “stage” is actually taking so long to boot. The thing is it may not just been the “networking startup” time.
Let me know,
– Toly
I configure my connections through the gnome network manager (nm). It seems that nm does ist own configuration, but I’m not certain.
My /etc/network/interfaces:
auto lo
iface lo inet loopback
#iface eth0 inet static
#address 192.168.0.20
#netmask 255.255.255.0
#gateway 192.168.0.1
@Anselmo,
If that is your configuration, network is not your problem during the startup.
So we can look deeper. While the system is booting up (splash screen), can you press “Ctrl + F1″, and then either “Ctrl + F8″ or “Ctrl + F7″, so you can see the actual boot process.
Pay attention to what takes the most amount of time, and post back with comments.
– Toly
I found out what is delaying my boot. It is the loading of the Virtual Box kernel module. However, I don’t know how to disable it. I have already included it in the file /etc/modprobe.d/blacklist, but it is still loading at the boot. How should I do to make it not load? The kernel module name is vboxdrv. TNX in advance.
@Anselmo,
I have Virtual Box configured on several servers, and do not recall having problems loading the “vboxdrv” during boot.
But here are things you can try.
Try to re-setup the module:
Also double check that the module have the right permissions, if not:
– Toly
Thank you. Changing file permissions reduced the time to load the virtual box module by about 10 seconds.
@Anselmo,
welcome!
– Toly
thank you very much for this hint! now my life is 40s longer per day