"On those infrequent occasions when you need to reboot Linux, you may find that the process takes longer than you'd like. Jack Wallen shares a number of tricks you can use to reduce boot times." While these tips are intended to shorten Linux boot times, some can also increase the security of your system. Speed and security in ten tips, both well-known and obscure.
Post a Comment
Member since:
2006-02-15
#2: Disable unnecessary kernel modules:
Most distros ship with those kernel modules compiled as modules, not built-in, so they don't make booting time any worse or better. The system just checks if it needs a module for some hardware and initializes that module, it doesn't load all of them!
#7: Avoid dhcp:
This one I was wondering what the heck was the author thinking? The answer to dhcp requests arrives in milliseconds (unless there's something terribly wrong with your system) and it allows for much more flexibility.
#6: Use an OpenBIOS:
There's a saying "Don't fix what isn't broken". Especially when it's the bios. If OpenBIOS doesn't work on your motherboard or if the flash procedure goes hayways then you're fscked. I wouldn't have included this in the list, even though it will boost boot-up time _if_ it works.
Member since:2005-07-06
[q#7: Avoid dhcp: This one I was wondering what the heck was the author thinking? The answer to dhcp requests arrives in milliseconds (unless there's something terribly wrong with your system) and it allows for much more flexibility. [/q]
On my systems it takes sometimes a few seconds to get an address, especially wirelessly. If it fails to get an address (for whatever reason), it may take 30 seconds or so before it gives up. Depending on the OS/Distro, if these task are done serially that can be a significant slowdown.
To me, the biggest speed-up is for most of these tasks to be done in parallel - thus our case of a failed dhcp request wouldn't matter.
Member since:2006-02-15
On my systems it takes sometimes a few seconds to get an address, especially wirelessly. If it fails to get an address (for whatever reason), it may take 30 seconds or so before it gives up. Depending on the OS/Distro, if these task are done serially that can be a significant slowdown.
To me, the biggest speed-up is for most of these tasks to be done in parallel - thus our case of a failed dhcp request wouldn't matter.
Hmm, well, I haven't tried too many different distros but Mandriva does dhcp in the background and so does Ubuntu (not that I use the latter one..). The whole point is that _if_ it happens to take some time to get a response then the process can just idle in the background, it does not need to be blocking other services from starting up. Especially since it consumes virtually no CPU time.
Member since:2006-05-28
To me, the biggest speed-up is for most of these tasks to be done in parallel - thus our case of a failed dhcp request wouldn't matter.
If you are using something like ifplugd then this isn't an issue
Edited 2008-07-31 07:08 UTC
Member since:
2006-04-18
If your desktop is wired to the Ethernet, you don’t need to have a wireless kernel module loaded. This task is a bit more difficult and will require a kernel recompilation, which is not the easiest task to undertake.
When was the last time, if *ever*, that a wireless module was compiled into a kernel? She even says 'module' in the previous sentence!
Member since:
2005-07-06
Member since:
2005-07-01
Member since:2005-11-13
Member since:2005-11-21
#5 Change your OS
#6 Change your hardware
#10 is the only interesting one and it isn't explained at all.
From /etc/init.d/rc on Debian SID
# Specify method used to enable concurrent init.d scripts.
# Valid options are 'none', 'shell' and 'startpar'. To enable the
# concurrent boot option, the init.d script order must allow for
# concurrency. This is not the case with the default boot sequence in
# Debian as of 2008-01-20. Before enabling concurrency, one need to
# check the sequence values of all boot scripts, and make sure only
# scripts that can be started in parallel have the same sequence
# number, and that a scripts dependencies have a earlier sequence
# number. See the insserv package for a away to reorder the boot
# automatically to allow this.
CONCURRENCY=none
INNSERV configuration is at /etc/insserv.conf
/usr/share/doc/insserv/README.Debian which explains the whole thing:
To test dependency based reordering of the boot sequence, install the
package, enable parallel booting, and run update-bootsystems-insserv
to make a backup of the boot sequence and reorder the boot scripts.
Be careful to verify the boot sequence before rebooting, as an
incorrect boot sequence can render the system completely unbootable.
In short:
# Enable parallel booting
echo CONCURRENCY=shell >> /etc/default/rcS
# Update boot sequence
update-bootsystem-insserv
# At this point, I recommend examining the order in /etc/rcS.d/ and
# /etc/rc2.d/ carefully, to verify that the configuration actually
# will boot. Update /etc/insserv/overrides/ or
# /usr/share/insserv/overrides/ with better dependency information
# if the boot order is incorrect, and run insserv -v to update the
# boot order.
# Ready to reboot
shutdown -r now
The next boot should then start services in parallel, as early as
possible during the boot process based on the dependency information
provided.
To monitor the boot sequence, the bootchart project is a good choice.
Debian packages are available in etch and sid. The project itself is
available from http://www.bootchart.org/.
Background info on alternative boot systems in Debian is available from
http://alioth.debian.org/docman/view.php/30730/38/debconf2-initscri....
In a nutshell, if you're not interested in getting down into the weeds I wouldn't fix what isn't broken.
Member since:
2008-04-28
Could he please quantify the result?
I always say to friends "get the OS that does what you want".
Booting time is not a concern to me. What is the maximum time your NIX takes to boot? 60 seconds?
My FreeBSD and Debian are always on. I have not rebooted them for over a year now.
Member since:2007-03-31
Member since:2006-02-10
Member since:
2006-01-02
1. Yes, we know. We knew that before we even knew what Linux was. But, with extra functionality comes extra services to be loaded, many during boot. What would be great, IMO, would be for service scripts to have their own dependency tree, and automatically run concurrently when possible, rather than requiring manual tuning for it, or basing it on some arbitrary factor (as the Debian example in 10).
2. *scratching head* This is usually automagically done for you, is it not (except maybe for drive controllers)?
3. Meh, until you get into ones that are really minimal. E17 may start up faster than KDE or Gnome, but XFCE takes about the same time, and can take longer. On my box, it's 8 seconds to KDE dekstop, just over 10 to XFCE's.
4. *shrug*
5. Bingo. I couldn't get X running (that was after days before it got to compiling) the last time I was reloading SMGL, so I went Arch. It's nice.
6. That would be really cool...but, even if I could, I don't have the balls for it. First, video inits, and you have your POST, then two fake-RAID drive controllers search for plugged in devices (I'm using drives plugged into both), then GRUB can do its thing. Speeding this up would be great.
If this is a concern, and you're going to build a new machine, get a motherboard with modern onboard video, and no frills.
7. *shrug*
8. *shrug* (udev)
9. Neat.
10. yup, been doing that for ages, in whatever way the distro I use allows. It's not just Debian that has this ability hidden in plain sight. Couldn't it be done better, though?
Edited 2008-07-30 20:12 UTC
Member since:
2005-11-12
Article, Hotplug?, no we use Udev and HAL now.
Since when did GNOME or KDE take along time to load, they are both pretty quick at under 10 seconds.
My Boot time is about just over 20 seconds on Linux Mint without any tweaking, this person should update their knowledge of Linux boot process.
Member since:
2005-09-19
Undoubtedly I will be downvoted for saying this, but I'm getting really tired of blanket statements like "Linux rarely needs to be rebooted" at the start of articles like this.
Frankly it's a myth for most desktop Linux users, and server boot times don't really mean much anyway.
Every time you update a kernel, or graphics drivers in Linux, you have to reboot and, since suspend doesn't seem to work anymore you have to shut down everytime you pop to the office with your laptop*. If you don't install the kernel security updates then you might as well run one of those other 'insecure' operating systems anyway.
* I have 4 different laptops currently with Linux installed, none resume reliably from suspend or hibernate.
The main content of the article is useful, however!
/rant ;-)
Member since:2006-12-18
Well, for kernelupdates that is true, you have to reload the kernel to use new code, and folowing that sense, it is NOT true that you need to reboot to use and updated video-driver, you only need to reload the graphics system to use the new code, ie. xorg, which is usually done by changing to a lower runlevel and then back to a runlevel that starts the X system... Or as simple as stoping kdm/gdm via an rc-script and then restaring that service... This is for debian at least... BTW, ctrl-alt-delete restarts the x-server, but for at least the nvidia-driver X arent allowed to run while installing/updating the driver, so thats why you need to stop the service abnd restart it afterwards...
Member since:2006-12-16
Member since:2005-08-18
Member since:2005-07-06
Frankly it's a myth for most desktop Linux users, and server boot times don't really mean much anyway.
That's too bad, but to be fair that's one of the reasons I got a Mac is because sleep and hibernate DOES work reliably. We reboot when the random update comes down from Apple, both my tower and the laptop. Today, that's more and more rare since I still run 10.4 and my wife runs 10.3 on her iBook.
Other than that, just walk away from the machine and let it sleep, or close the laptop.
Seriously, this "instant on" and "instant off" ability is a poignant "quality of life" issue with computers for me nowadays. Having an "instantly" available computer combined with my "ubiquitous, always on" internet is major component to their value to me. If I had to boot up a machine to get on line, then it wouldn't happen. Power up...boot boot boot...web browser...shutdown...wait wait wait... Nope, sorry.
I do wish the Linux/BSDs/Solaris systems could get this part of the experience bullet proof.
Until then, when I get my next laptop, it's gonna be a Mac.
Member since:2005-07-06
Member since:2007-09-08
Power management actually works very well in Linux. If you run Linux on a Mac, without using any closed source drivers, it works as well as it does on a Mac running Mac OS X.
Where it falls down is closed-source drivers (particularly nVidia and ATI's video drivers), and buggy ACPI implementations on motherboards.
The last three laptops I've had all worked perfectly in Linux (except my Macbook's trackpad, which is unusable in anything but Mac OS), but a good half of the laptops I've looked at wouldn't have, either due to requiring closed-source drivers, or crappy ACPI.
My desktop machine crashes when waking from sleep though. Does the same running Windows, for that matter.
Member since:2005-08-18
I'm getting really tired of blanket statements like "suspend doesn't seem to work anymore". Frankly it's a myth for most desktop Linux users. Also, you really don't have to reboot when you install a new video driver.
I found it mostly useless.
Member since:
2006-05-19
I'd like to see day when there would be only one chipset, only one type of hdd connectors (why we need drives at all is beyound me- petabytes of non-volatile RAM is available already), only one type of hot-swappable PSU, only one type of CPU cards that is upgradable just by throwing other(s) card(s) into ONE TYPE of socket, only one video card.
ONLY ONE F***** OS THAT WORKS!?
Member since:2005-07-07
Member since:2005-12-02
"I'd like to see day when there would be only one chipset, only one type of hdd connectors (why we need drives at all is beyound me- petabytes of non-volatile RAM is available already), only one type of hot-swappable PSU, only one type of CPU cards that is upgradable just by throwing other(s) card(s) into ONE TYPE of socket, only one video card.
ONLY ONE F***** OS THAT WORKS!?"
Can we throw World Peace in there too? 
Member since:2007-08-11
ONLY ONE F***** OS THAT WORKS!?
would you also like there to be only ONE type of house, ONE type of car, ONE phone.
competing standards aren't all bad. All of these things do interoperate so they're not completely incompatible. Sure your scenario makes life easier for IT support techs, but life would be very dull.
Member since:
2006-01-14
The code is at least there. Its mainly a problem with the hardware makers and bios makers not using a standard. I have a dell M1330 laptop and with Fedora 8 and 9 it worked flawlessly. Both suspend and hibernate. That is while using the Nvidia drivers. I would think it would work using generic video drivers.
Member since:
2005-07-06
Member since:
2006-02-06
I've used the runlevels/services with pretty good success over the years.
For example, I don't have a printer connected, so cupsd can go. And I don't have any use for ssh either; plus a couple of other things I disabled. Be careful though, since most of the things you *will* need. This lets me shave off a second or 5 from my boot time.
As a bonus, (Open)SUSE makes it very easy to change this using its Yast module.
Member since:
2007-08-28
Member since:2006-05-28
Member since:
2006-03-01
the author has forgotten a potentually very useful one ( for those with ext3 boot partitions at least)
11. use fcache (http://lkml.org/lkml/2006/5/15/46) - after a first boot in which data is sequentially copied to a frontend cache in read order, having the system read from the cache on subsequent boots minimizes head seeks and, overall, boot time
Member since:
2007-01-04
Member since:2007-03-06
Ermm not at all. Deleting keys there only prevents some stuff from running at boot... if anything that would only be remotely similar to disabling services (#1).
Member since:2007-01-04
Hmmm, perhaps I was too subtle. What I meant was, if you want your Windows machine to boot faster you delete keys from HKLM\Blah\blah\blah\Run. Sometimes you go into the Services thingy and disable some service startups, but mostly it's the registry thing.
In Linux, a lot of people already disable unnecessary services after an install in much the same way they would go into HKLM\Blah\blah\blah\Run on a Windows machine after a fresh re-image using a manufacturer's recovery disc (because it installs all that extra crap nobody really likes/uses anyway).
I know that in actuality the HKLM\Blah\blah\blah\Run thing and disabling services in Linux are entirely different approaches but they are usually the first steps taken on a Windows or Linux system (respectively) to get it to boot faster.
Things like using another Window manager is not dissimilar from disabling nVidia nView etc.