Sunday, October 3, 2010

Boot time tuning chapter 4th: Reliability


today I'm making a little step back but another forward. I mean that in the last tuning chapter I was enthusiastic of my 9 sec boot time, even knowing I was on the edge of the blade. Actually nothing bad has happened, I was even able to cut away another second.

I did optimize booting levels and made some order in my xorg.conf. Maybe some little extra is given by the latest xorg version, which I installed in these days. At the very end of my optimization I was able to boot in 8s... but sometimes I was not able to boot. So here is the detailed story.

First let's talk about optimizations.

As you were able to see in last chapter images, the X system startup takes a lot of time, so I tried to get more info about it. We are talking about 6-7 seconds: during this time, the new generation Xorg infrastructure (which has become more flexible and dynamical, cooperating with hal daemon) monitors you hardware and try to guess what you want your desktop look like. This stuff includes hardware polling, modules and drivers loading but even monitor and outputs sizes and resolutions, positions etc. So the simplest thing to do is to fill the xorg.conf file with your default settings. I'm not getting into the business this time, it's a huge argument, maybe we'll talk about it another day, but I'm not leaving you alone! (Of course not!) The most of information needed to generate a good xorg.conf file are in man xorg.conf (surprise surprise!!!;) ). Intel Graphics users can find vital extra infos and tips here: Intel Linux Graphics: Documentation

Moving on, the rest of the news is a simple-stupid idea: "If something is not needed in boot, remove it". So I got rid of those useless rc services. Then it came another great (rofl) idea: "If something is not needed in early booting, then move it in default runlevel". This is simple and someway effective.

Anyway here comes the "bad" news.

The only trouble I step into was a read-write issue. Getting in the detail what happened was an early try to write on the disk, most of times by bootchart (lol), which caused whole the boot process to stop in a bunch of errors... Hehe... that happened with read-only filesystem so no effects on my box, but better make a step backward and get a more reliable system.

The sysinit level contains few tasks that are made usually in read only mode. This is done for some security reasons I suppose, anyway what we should care about is to let this few things run in the traditional way and not let other runlevels to start in the meanwhile. So get your inittab and edit:
sudo nano /etc/inittab
the sysinit line should not have the "&" we added few days ago:
si::sysinit:/sbin/rc sysinit


I'm not giving up. I'm already thinking about a temporized solution, to let higher runlevel start some seconds after sysinit start, without waiting for it to end. I'll let you know about it.


No comments:

Post a Comment