Improve the Debian boot process - blog

Etch boots as fast as Woody...

2007-04-11T14:14:00.000-07:00

With the Post-etch frenzy, I installed Debian 4.0 stable as soon as I could. I used the same system used a few months ago for the google Summer of Code. Under the same conditions, the system required 32 seconds until KDE started. Compared with the previous stable releases:

Woody - 32 seconds
Sarge - 44 seconds
Etch - 32 seconds

Nevertheless, Etch has significantly more process started at boot time and the CPU usage is more intensive --with still some room for improvement --. Follow this link for the bootcharts and more detailed information.

As I starting point, using dash instead of bash, the boot time is reduced to 30 seconds and it could be further improved but there is some "hald" process (maybe part of dbus) that doesn't seem to want to run in parallel. See bootcharts. Any ideas?

A weird effect of discover (SoC2006)

2006-09-08T13:33:00.000-07:00

It is funny to see that when I remove discover (/etc/rcS.d/S36discover) from the boot, a disk utilisation and cpu usage peak appear at the end of loading KDE. Would it be that discover is loaded by KDE if it wasn't loaded? Or a discover ghost :p. Well, the bootcharts for the two different cases are available here.

Prelinking during the boot (SoC2006)

2006-09-08T11:28:00.000-07:00

I've tried prelinking with the aim of making the boot faster. I've used the package of prelink from debian in unstable and we get no significant time improvement. Prelinking was added after readahead in a custom script run during the boot in /etc/rcS.d/S70prelink. What the script does is to prelink: kdeinit, Xorg, kwin, kdesktop, kicker, artsd, kaccess, ktip, klipper and korgac. The bootcharts are availabe here.

8 second reduction (SoC2006)

2006-09-08T06:35:00.000-07:00

By removing useless init-scripts from the symbolic link pool (/etc/rc?.d) we got a further second improvement in the boot time. The two init-scripts removed were hotkey-setup and gdm. The former can be removed as I'm not using a laptop and the latter because I'm using KDE. The boot time was reduced from 46 to 45 seconds. See the new bootchart and compare with the reference bootchart.

Trying to integrate Ubuntu's readahead (SoC2006).

2006-09-08T00:11:00.000-07:00

I've been playing a bit with Ubuntu's readahead to get a better boot time on debian. At least they seem to get it. I've used strace to get the list of files for different init-scripts and generate the required /etc/readahead/boot file - containing the files to load to memory. The advantage of readahead over preload so far is that it does not affect the boot time when it is not active. I consider readahead inactive when the boot file is empty and preload when the preload script is removed from the symbolic link pools (/etc/rcX.d).

By using readahead shortly after the system starts to boot (near udev), the boot time is even increased by 2 seconds (e.g. S03readahead in /etc/rcS.d). On the other side, by using some of the files used by KDE during startup there is almost a one second improvement as may be seen in the bootchart. We use readahead in /etc/rcS.d position S42. The list of files and the bootcharts may be found here.

Besides, I've corrected the deliverable 5 including the fact that lintian incorporates now a check for lsb compliance based on our patch! The deliverable is available here

7 seconds less on the boot time (SoC2006)

2006-09-05T16:52:00.000-07:00

With the alioth sever down, it seems our project webpage is down as well. Anyway, we are currently on a 7 second improvement of the boot time by using reordering, dash as /bin/sh and hwclock in the background. The bootchart is available here while that of the original system here. No time was won using preload 0.4 with varied configuration combinations. Curious to see that the time is 2 seconds more even without preload in the symbolic link farm (/etc/rcX.d) when preload is installed.

Deliverables 3 and 5 (SoC2006)

2006-08-31T10:17:00.000-07:00

The new deliverables 3 and 5 were published. In the third deliverable we mention the effect of most hotspots, the procedure used for testing them and their bootcharts. Besides, it contains a group of combinations done with the hotspots and their effect. Deliverable 5 simply consists of the LSB guide for maintainers and the lintian patch to check LSB compliance. Both issues were published some weeks ago and this deliverable was just published to comply with the original deliverable list. Still two deliverables are missing: Deliverable 4: a proposal to change the boot system in debian according to the results from Deliverable 3 and further research, and Deliverable 6: the final report of the project. They are available in the deliverables webpage

Insserv reordering and repeated init-scripts (SoC2006)

2006-08-17T01:08:00.000-07:00

Some time ago I posted having obtained a 2 second time decrease in the boot time using insserv reordering. In that occasion, I had already deleted some repeated init scripts from the insserv modified /etc/rc2.d directory. Recently, I had problems using insserv as I thought the major change was just to change the order of some of the init-scripts (stop-bootlogd, sysklogd, klogd). Now, from a system starting in 53 seconds I got a 2 second improvement by using the same script order used some time ago. Besides, I thought I shouldn't bother to delete the repeated init-scripts as /sbin/init is supposed to ignore them. Nevertheless, by removing the remaining repeated scripts I got a further 2 second time improvement, i.e., a 4 seconds improvement! The bootcharts and init order are available at the project webpage.

System reinstalled and testing preload again (SoC 2006)

2006-08-15T05:42:00.000-07:00

Currently recovering from a disk failure with lots of data lost (i'll backup more often now), I'm trying to tackle with the inconsistencies sketched in the previous blog: preload and parallel booting hotspots don't perform as before. I guess the discrepancies came from playing too much with the boot process.
The new system has originally a boot time of 52 seconds and the installation of preload 0.4 on a freshly installed system gave 1 second longer boot time during the first reboot and came back to the original time after 4 reboots and goes back to 53 seconds afterwards.
The bootchart is available on the bootcharts section of the project webpage for two preload configurations.

Besides, unverbose booting was tested. Well, simply verbose was changed to "VERBOSE=no" and "VERBOSE=quiet" just making the system slower! What could this be? Manual tweaking may be probably needed. The bootcharts for the different cases are available on the bootcharts section of the project webpage

Finally, a laptop testing system was prepared for comparison. It has also a fresh debian sid installation on an external USB hard drive. The results using the laptop test bed were similar for unverbose booting although the boot time seem to be unconsistent! Around 2 second changes without networking and higher with networking. I _guess_ a possible reason is by using an usb hard drive.

Comparing preload 0.4 and 0.2 (SoC 2006)

2006-08-09T01:56:00.000-07:00

I've tried preload 0.2 and 0.4 to compare its effects. Unfortunately my results don't hold with the results obtained some blogs ago: preload 0.2 reduced the boot time by 2 seconds. In this occasion, time was even lost (making me remember my first tests). This may be due to some upgrades had been made to sid since.
First I tried preload 0.2 with default with 1 second lost and a modified configuration with no boot time change.
Then I tried preload 0.4 with default and modified configuration both with no time change.
The bootcharts and log file are availabe at the project webpage.
Yesterday I presented a table with hotspots combinates and unlike it was expected, preload may not be helping anymore (preload 0.4 was used).

Table preview of hotspots (SoC 2006)

2006-08-07T16:02:00.000-07:00

Some hotpots combinations were tested. Unexpectedly, the use of several hotspots together didn't cause an arithmetic sum of boot time improvements. For example, let's consider the following hotspots and their corresponding boot times:

hotspot	time
DASH AS SH	4
PRELOADING	2
NETWORKING	0
HWCLOCK	2
REORDERING	2
PARALLEL	4

On the other side, while trying them together we get:

hotspot	Test#1	Test#2	Test#3	Test#4	Test#5	Test#6
INSSERV	X	X	X	X	X
DASH	X	X	X	X	X	X
NETWORKING	X		X	X
HWCLOCK	X		X	X
PRELOAD		X	X	X	X	X
PARALLEL		X	X		X	X
time improve	4	6	6	6	6	4

Lintian patch for LSB-compliance (SoC 2006)

2006-07-30T04:22:00.000-07:00

A patch for lintian to check runtime dependency in the init scripts is now availabe at the project webpage. It proposes modifications to two files in the lintian/checks directory and was already tested. It reports incomplete and missing dependency information as well as individual warnings per headers missing. It was reported as a patch for the #377740 bug previously reported.

Now preloading worked (SoC 2006)

2006-07-22T11:40:00.000-07:00

One again I've tried the preload program from Behdad Esfahbod (a result from SoC2005) but this time positive results. The cause of the difference might have been an incorrect deinstallation of parallel booting (insserv/startpar). The boot time showed a 2 second time improvement. The preload.conf parameters mapprefix and exeprefix were set to empty such that all files would be accepted. The results were compared with mapprefix being set to the directories used by some of the init scripts (strace -f initscript), adjusting the quantum time of preload (cycle parameter) and changing the position of the initscript to start just after hwclockfirst.sh. The results were the same: a 2 second time improvent. See the bootcharts here.

Now Parallel execution works better (SoC 2006)

2006-07-20T16:36:00.000-07:00

A bug was found when doing parallel execution with startpar. The scripts seem to have been executing twice and it is being fixed by Petter Reinholdtsen. To compare the effect of the bug, the parallel execution boot time using startpar was compared with the one using "shell". The main difference between using CONCURRENCY=startpar and CONCURRENCY=shell in /etc/default/rcS is that the latter doesn't care about the order in which messages are printed to the screen.

The issue made me try things again and this time I didn't accept the default script reorder from insserv. Insserv seems to have the following reordering issues:

a)repeates scripts in /etc/rc2.d that were already started in /etc/rcS.d
b)doesn't reorder /etc/rcS.d
c)puts stop-bootlogd near the beginning in /etc/rc2.d and bootlogd while sysklogd and klogd are at the middle.
d)includes scripts present in /etc/init.d that were not previously executed at boot time.

Issues (a) and (c) were corrected and the boot time was 2 seconds faster than without insserv(See bootcharts).
While testing parallel execution, using CONCURRENCY=startpar, there was no improvement (the bug hasn't been fixed) and while testing with CONCURRENCY=shell there was a 4 second time improvement from the original system without insserv. (See bootcharts)

Meeting with my mentor in Dublin (SoC 2006)

2006-07-19T17:14:00.000-07:00

In one of this extremely weird sunny and warm days in Dublin, I've met my google SoC mentor Petter Reinholdtsen. We've discussed several issues of the project and here are the main points:

1. Some small issues in the LSB compliance list needed to be corrected. Some packages didn't showed their package. It was solved and now all the init-scripts have the package they belong to. See LSB-compliance list.

2. It was important to compare the results from two different ways to use dash instead of bash in the init-scripts. See discussion in debian-devel. The two approaches are:

a) make /bin/sh point to /bin/dash - using the procedure described in /usr/share/doc/bash/README.Debian.gz, we obtain a time reduction of 4 seconds.
b) change #!/bin/sh for #!/bin/dash in the init-scripts - using the substitution function of sed, the initscripts were changed to use dash. A reduction of 2 seconds was obtained.

The bootcharts are available here. The difference should be because some programs are still using bash as just the first line of the initscripts was changed.

Automatic update for the LSB compliance list (SoC 2006)

2006-07-15T12:47:00.000-07:00

We have published a list for LSB-compliance in here. The script to create it was now modified to be easily updated automatically considering changes in the initscript files and new reported bugs. It will also consider special cases like with the scripts bootlogd and hostname.sh that wouldn't normally be considered as LSB compliant. The scripts are available under the GNU license at the project repository.

testing ubuntu's readahead (SoC2006)

2006-07-11T19:02:00.000-07:00

The base distribution I'm using for Sid changed slightly by installing ssh. There was no boot time difference. The new base bootchart (same time 49 sec) is here.

Based on a discussion in initscripts-ng-devel between Petter Reinholdtsen and Erich Schubert, I decided to try ubuntu's readahead to see if we will get a better or worst boot time. After installing ubuntu's readahead 1.0.1-2 but noticed not time difference. No difference was obtained by changing the boot order (S39 to S19 in rcS.d) nor by adding files read at /etc/readahead/readahead. The bootchart is here

Also tried the newer readahead from ubuntu readahead 0.20050517.0220-0ubuntu3 but now with a loss of 1 second. This includes two scripts S01readahead and S39readahead-desktop in rcS.d and S99stop-readahead in rc2.d. The bootchart is here

Next I'll try to analyze the SUSE static preload.

Besides I filed an bug (377941) to initramfs-tool I had with installing Etch on my laptop with a usb harddisk. Tried adding sleep 5 to /usr/share/initramfs-tools/scripts/init-premount/udev, then dpkg-reconfigure linux-image-.... but still fails :(

More bug reports and benchmark (SoC2006)

2006-07-11T01:52:00.000-07:00

Yesterday I filed a bug report for lintian as it doesn't check for LSB compliance. Many scripts would be fixed at the moment we get an LSB check in lintian and normally we will be providing them with a patch for it with our Deliverable 5 in a few weeks. Bug report #377740
I'm installing sid in my laptop --originally-- to use as benchmarking for the boot process. The installation procedure was the same as the one explained in the project webpage for sid except that it also includes the Laptop package subset. As I'm using a usb harddisk, it seems there is a problem at the boottime as /dev/sda1 takes to long to be detected and when root wants to mount it hasn't been detected yet. I currently skip this problem this by doing CTRL-S at the beginning to give it more time but this won't make a good boot process benchmark.
New bug reports were filed:
alsa-base #377716
alsa-utils #377717

LSB- howto, status list and check script (SoC 2006)

2006-07-08T11:51:00.000-07:00

A guide for debian package maintainers to make the scripts LSB compliant is available in here. It is not a substitute of the LSB 3.1 but intends to be used as a quick reference to create LSB-compliant init-scripts.

The script to check the LSB compliance was changed to reflect the init script status according to:
+No LSB headers - If "### BEGIN INIT INFO" is not found.
+LSB compliance - If the headers Provides, Required-Start, Required-Stop, Default-Start and Default-Stop exist and have arguments. Besides, if Default-Start is equal to 0 or to 6, LSB compliance is satisfied only with Provides, Required-Start and Default-Start.
+Missing LSB headers in the other cases.

Finally, a list with the current LSB-compliance status of Debian init-scripts is available here. It was automatically generated using a modified version of the script mentioned above and includes a link to the bug report filed to correct the scripts. The aim of this webpage is to give an overview of the work that needs to be done in Debian for LSB compliance.

Bug reports for packages with missing LSB headers (SoC2006)

2006-07-05T17:10:00.000-07:00

Yesterday I started to prepare bug reports about missing LSB headers. Since then I reported:
-acpid script #376778
-atd script #376780
-bittorrent script #376944
-exim4 script #376953
-hotkey-setup script #376955
-inetd script #376956
-kdm script #376958
-lpr script #376960
-makedev script #376992
-nfs-common script #376976.
A summary of the bug reports with missing lsb headers can be found in here
Besides, we've raised the issue of some scripts missing dependencies in the bootclean init script and the missing Should-Start dependency of bootmisc.sh in the sysvinit-devel mailing list.

Deliverable on line and LSB list

2006-07-04T11:55:00.000-07:00

The second deliverable of the "Improve debian boot" project is available to check since yesterday night in the webpage. In this report, a comparison between the boot process of the debian releases from woody to sid is presented. Besides, the first hotspots are investigated.

On the other hand,I've updated the LSB compliance of the scripts in Sid and added some related bug reports to some of the scripts. Besides, I've worked on new bugs on the script for LSB compliance by checking with all the scripts.

btw, anybody interested on this project can always join us every day at irc.debian.org at the channel #pkg-sysvinit (Europe daytime normally :D ).

Preload status and back to bechmarking (SoC 2006)

2006-07-02T06:49:00.000-07:00

I've went back to the subject of benchmarking Debian releases in order to prepare the second deliverable. It should be available tonight for review in the project webpage.

Besides, we are trying to explore how to make the debian package of preload to work properly such that we can notice any time improvement. The default configuration and with little variations show no time difference. Anybody out there knows about some examples of how to configure preload?

preload and LSB compliance webpage

2006-06-30T01:59:00.000-07:00

I started to try another hotspot: preload. Unfortunately, I noticed no change on the boot time after installing preload. Not even after changing its boot order from /etc/rc2.d/ to /etc/rcS.d/ after the dependencies were met: in the init script it claims to require $time, $remote_fs and $local_fs. I believe seeing it in ubuntu at just the beginning of /etc/rcS.d/. The bootcharts and test procedures can be seen here. This is an issue that has to be further investigated.

On the other side, the lsb check script was debugged a little bit more. A list with the compliance of the init scripts in sid is available here. The few LSB compliant scripts are on the top, the big incomplete majority in the middle and those without LSB headers at the bottom.

Debugging the LSB check in lintian/linda.

2006-06-29T01:33:00.000-07:00

With run-time dependencies in the init scripts (as LSB headers) we can verify the correct boot order of the system. Currently, lintian just checks the init scripts to provide start, stop, restart and force-reload actions. A small modification could allow it to check for LSB compliance as well and decrease the big amount of scripts lacking run-time dependencies until now.
Currently we have a script to verify LSB compliance and is on a debugging phase. One of the issues is when to warn about a missing information on the stop phase, like Required-Stop, Should-Stop and Default-Stop. Changes we made were not to warn (at least for Default-Stop) when the system default start is only runtime S (initialization).

Finally, there are now some way to track the bugs related to this project with BTS usertags. Most of them have been submitted by Petter Reinholdtsen. Follow this link to see the bugs.

Script for checking LSB compliance (SoC 2006)

2006-06-28T03:42:00.000-07:00

Based on a script by Petter Reinholdtsen to check the correct init script order, I've made a script to check for LSB compliance. It is available on the project webpage. The script checks for the existance of each of the LSB headers and considers 4 main output cases:
+ No LSB headers (when the START INIT INFO header is not found)
+ Basic LSB compliance (when Should-Start, Should-Stop and the Description have no arguments.
+ Full LSB compliance (when all headers have arguments)
+ Partial compliance (in the other cases).
Besides, it sends to to STDERR comments on missing headers or missing arguments in them.

startpar and insserv

2006-06-26T05:23:00.000-07:00

Yesterday I tried insserv together with startpar according to the post from Petter Reinholdtsen although the results were not what we expected as just a 2 second reduction was observed. The bootchart is here. This behaviour seems to be due to a deficient ordering of the init scripts by insserv as it may be observed by comparing the init scripts order before and after ordering with insserv.

In the order of the initscripts it can be observed that:
+there are repeated versions of one initscript in the symbolic link farms (/etc/rcS.d and /etc/rc2.d) like udev.
+some known errors in the order were not corrected (bugs #375388 and #375389).

To correct this behavior requires some modifications to the code for ordering the initscripts in insserv. This would be the next step in the project (to implement a promising hotspot) when dependency information (LSB-compliance) can be checked.

BTS and Lintian

2006-06-25T12:08:00.000-07:00

While working on the script to check for LSB compliance, and as a recommendation from Petter Reinholdtsen, I commited two bug reports to the BTS related to a wrong order of some scripts in the sysvinit package. Specifically alsa-utils and udev (Bug reports #375388 and #375389, respectively).

The reason for this, besides correcting the bug itself, is to raise the issue of correct script ordering. Currently, a developer cannot know if their package is correctly placed in the /etc/rc?.d symbolic pools until a bug is reported. If lintian and/or linda included some check for init script dependency information, i.e. basic LSB-compliance, the maintainers would remember to include this information and a script could correct the order for each individual system. The script needs to be developed for debian and this is one of the next steps on the current boot project.

dash and LSB check

2006-06-24T04:46:00.000-07:00

One new boot process hotspot was tested yesterday: using dash instead of bash. Got a good reduction of 3 seconds in the boot time. The results and method used are in the project webpage. Nevertheless, this was different from the 6 seconds obtained by Margarita Manterola in her slides from debconf6.
On the other side, with the aim of having a script for checking lintian rules and LSB compliance, I've started to take a look to the script written by Petter Reinholdtsen. It is written in perl so I took a quick tutorial of perl first :)

Background and LSB compliance (SoC 2006)

2006-06-23T04:28:00.000-07:00

Yesterday I tried another hotspot: networking on the background. In the Sarge networking script it is pretty easy to run in the background. Just have to add an ampersand after the line:
ifup -a
Couldn't be easier I guess. Well, there is the problem that the message "done." will appear afterwards at some random place out of context. Now, the sid version of the script is much nicer and seems to be LSB compliant!!! Grand! Well, the problem comes as "ifup -a" is inside an IF statement such that sending to the background makes no sense. So maybe it could be sent to the background in a new shell and send a message like "Configuring network interfaces...done".
Well, as my intention was just to test the boot speed I removed the IF statement. There was no change on time! That is not what should happen. I'll have to double check. The results and scripts are available here
Finally, I tried removed discover from the scripts as udev is already doing the same job. This change was motivated by a comment from Marco D'Itri. Also in this case I noticed no change on the boot time. This should be hardware dependent.

First hotspots tried (SoC 2006)

2006-06-22T02:30:00.000-07:00

Debian sid was installed and the installation log can be found here. There is a link to a list of the packages installed with the distribution update from etch and the resulting init scripts. Besides, bootcharts and other resources will be available in this section.
Using the same sid installation, from the hotspots yesterday I tried to load the hwclock on the background with a 2 seconds reduction in the boot time. The bootcharts and scripts are availabe here as well.
Finally, depmod is not used any more in sid's module-init-tools and this is one of the hotspots. This was removed as a result from a discussion started by Margarita Manterola in debian-devel. Just by adding it again from an old script, the 2 second reduction from hwclock was lost.

Sid bootcharts (SoC 2006)

2006-06-21T01:22:00.000-07:00

Hi, another rainy summer day in ireland and another bootchart in the webpage Now it was sid's turn. So now we have the time from grub to Kde startup for the four releases:
Woody(32s)
Sarge(44s)
Etch(34s)
Sid(33s)
All of them use kde with autologin although boothchart stops at least 6 seconds before kde stops loading. That means that all of the times here are at least 6 seconds shorter so Sid takes 39 seconds from grub. An attempt to measure until kde finishes loading was made by changing the /sbin/bootchartd wait_boot function such that bootchart waits until the program ktip (the one that gives you a usage tip at startup). Nevertheless, in this case bootchart takes around 6 seconds to stop logging. The bootchart is on the webpage as well.

/sbin/bootchartd and KDE

2006-06-20T02:51:00.000-07:00

After finding out that bootchart wasn't considering the whole time for KDE to start up, we are trying to modify bootchart so it ends up with another program. The changes doesn't seem to be working for the moment as the program selected to end logging can't be found in bootchart.tgz. Anybody familiar with this?
On the other side, we are considering to add ELF prelinking as one of the hotpots to decrease the boot process time. Probably it could help when big programs start that need to link to many libraries, e.g. KDE.
Well, as a remark, anonymous comments are now enabled in the blog and a contact address has been added to both, the webpage and the blog.

D1:State-of-the-art in the boot process and promising hotspots (SoC2006)

2006-06-18T16:24:00.000-07:00

Finally the first deliverable (D1) is ready for revision here. It can be modified according to comments and extended if it is considered that some subject should be further investigated. Besides, some hotspots were identified and, as stated in the proposal it is time to implement some of them. At least the 5 more promising for the second deliverable. Comments about the order will be appreciated.

Together with this 5 hotspots, the second deliverable will deal with the evolution of the boot process in Debian: from woody to sid. Already, initial results were presented through this blog during the last week concerning boot times from woody, sarge and etch.

Bootchart vs Stopwatch (SoC2006)

2006-06-17T17:52:00.000-07:00

Today I did some serious polishing of the first deliverable of the boot process project and made it available here. One of the things added were some hotspots ordered by how promising they are. The final version of the deliverable will be ready tomorrow evening.

One question that I had today was about the relationship between Debian's update-rc.d and Fedora's chkconfig command. Both of them seem to arrange the order of execution of the init scripts. The other question was about the acceptance of file-rc and it seems that, at least for debian, it is used quite seldom (1).

Finally, as a result from Petter Reinholdtsen's feedback to the previously published bootcharts of woody, sarge and etch, I compared the bootcharts time using a stopwatch. Petter considered that the times were too small and it looked like KDE autologin time was too short. The time results (in seconds) for Sarge and Etch are:

Sarge 0:44 (bootchart) and 1:06 (stopwatch). Difference = 0:22
Etch 0:34 (bootchart) and 0:49 (stopwatch). Difference = 0:15

Big difference. The stopwatch was activated when the key ENTER is pressed at the GRUB selection screen and stopped until the KDE in-progress window disappeared.It should be noticed that bootchart doesn't account for the time of initrd.

Besides, from the time that the message of starting kdm appears until the KDE stops loading there is an important time difference:

Sarge ~0:06 (bootchart) and 0:23.5 (stopwatch). Difference=0:17.5
Etch ~0:05.5 (bootchart) and 0:19 (stopwatch). Difference=13.5

Then, most of the time difference seems to be because of bootchart stopping to count the time before the KDE stops loading.

Just as a final remark, the PC time from pressing the ON botton to the grub is around 11.5 second. Then the total startup times of Sarge and Etch end up being as big as 1:17.5 and 1:00.5, respectively. Both above one minute.

(1)http://qa.debian.org/developer.php?popcon=file-rc

Benchmarking other distrubutions (SoC2006)

2006-06-17T05:32:00.000-07:00

Hi, for the debian boot process project, the last days I looked at the SUSE, Mandriva and Fedora distributions to analyse their boot process. The most interesting so far was SUSE being LSB compliant and having insserv/startpar to set and ajust the dependencies for parallalel booting. The insserv/chkconfig combinations seems to do the same as FreeBSD's rcorder although rcorder checks dependencies in two stages: with root filesystem and with all mounted filesystems.

Fedora looks like a regular sysvinit process although it contains LSB information in the initscripts that is read by chkconfig to set dependencies in the /etc/rc.d directories. Nevertheless, the dependencies don't adjust to added/substracted scripts.

Finally Mandriva 2006 doesn't seem to have pinit/prcsys in their default configuration so it seems to have a standard sysvinit.

BTW, the first deliverable is being written in latex (with pdf and html versions generated together) and available here.

Woody / Sarge / Etch boot processes compared

2006-06-13T06:59:00.000-07:00

Debian distributions booting times (up to kde with autologin) in the same PC:

Woody - 32 sec (bootchart)
Sarge - 44 sec (bootchart)
Etch - 34 sec (bootchart)

The input-output data was just available for Etch as it requires a 2.6 linux kernel.

Benchmarking between boot processes

2006-06-12T10:37:00.000-07:00

For the project to improve debian boot process, I've installed debian woody and debian sarge to see the changes in debian releases. Currently installing debian etch.

The first bootcharts are here for woody and sarge with a clean installation with autologin to kde. Funny to see woody being faster with 32 seconds while sarge has 44 seconds.

For debian woody I had some problems to use bootchart but they were solved thanks to the kind help of Baruch Even. The errors were:

bootchart requires tmpfs filesystem, while the kernel 2.2 that comes with woody doesn't have tmpfs. It was solved by installing kernel 2.4 and substituting tmpfs with ramfs in the /sbin/bootchartd script.

initrd ignores the kernel call to bootchartd, as it ignores the arguments given to the kernel. It was solved by renaming /sbin/init (e.g. /sbin/init-moved) and making the file /sbin/init link to /sbin/bootchartd. At the end of the latter, there renamed /sbin/init is called. It's perhaps an ugly tweak but worked for our means.

On the other hand, the first deliverable draft was added to the svn repository and is available for comments here. It is still on an early phase and needs to be converted from tex to html.

Finally, I'm checking out SUSE's implementation of startpar together with insserv for parallel execution. It is interesting to see a boot process that looks to be already LSB-compliant.

Margarita's guidelines

2006-06-09T02:32:00.000-07:00

Another post about google's SoC project to improve the boot process written from sunny Ireland!

With the first deliverable deadline nearby, I've been preparing the computer I'll use for playing with the boot process with different distributions. Iv'e lately installed debian woody and will be comparing it with Etch and Sarge (as freshly installed).

From the blog of Margarita Manterola got some interesting guidelines of what to do for the beginning of the project [1]. As she had already tested boot times for several processes and got a 20 second improvement for Etch (reduced boot time to 60%!!) it looks like there is hope. It would be great to be able to watch the recorded presentation (hopefully soon to be available).

So new hotspots identified:

setting up the hardware clock in the background
improve cpu use when starting the desktop manager.
make the boot less verbose

Besides, there are two programs to consider:

serel -> claims to get at least an 8% faster booting process (using parallelizaton). An interesting choice documented in [2].
rcpar -> claimed to have the same functionality as the shell concurrency of /etc/init.d/rc with better handling of the output.

[1] http://www.marga.com.ar/blog/index.cgi/debian/Parallel_booting.html
[2] http://www.fastboot.org

Project SVN repository is up

2006-06-07T05:44:00.000-07:00

Used part of my 6 hours in Malmo aiport to prepare the summer project webpage. Just 2 buses per day to Sturup airport (Malmo) from Copenhagen!!

Well, so the webpage will be again available soon as it will be updated automatically from the SVN repository thanks to Petter.
http://initscripts-ng.alioth.debian.org/soc2006-bootsystem

For hotspots, reading Henrique de Moraes [1] got interested in serel [2] and will consider to include it in the things to test. Besides, got to read some months of initscripts-ng mailing list being interesting a comment from Erich Schubert about readahead (use it just at the very beginning and while bringing up the gdm/kde desktop) among others.

[1] http://alioth.debian.org/docman/view.php/30730/38/debconf2-initscripts-bkg.pdf
[2] http://www.fastboot.org

reading, hotspots and repository

2006-06-05T15:40:00.000-07:00

This is the second post of the blog for improving the boot process. There are some logistic news and hotspots being identified together with some readings.

Logistics:

SVN repository is up at [1]
place for webpage was decided and will be ready soon at [2]
Project added to the debian wiki at [3]

For the potential hotspots, some have been identified like:

reordering bootscripts
parallel booting (like with startpar)
preloading (like with dynamic readahead)
using internal functions in init scripts or dash
don't run depmod at run time

Besides, some readings like "System Init scripts and Debian OS" from Henrique de Moraes and the linuces boot process benchmarking are on their way.

[1]svn+ssh://svn.debian.org/svn/initscripts-ng
[2] http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/
[3] http://wiki.debian.org/SummerOfCode2006

Fist message

2006-06-01T15:08:00.000-07:00

It is exciting to be in the summer of code 2006 with debian!

I will use this blog to include new advances, my current work and ideas and links to the deliverables. I still don't kow where will be the webpage used to host the project itself and the deliverables but that should be decided soon.

In the next days I'll prepare the first deliverable with the state of the art of linuces boot process and identifying some hotspots to increase the boot speed.

For the moment I'm looking at suse, ubuntu and FreeBSD. I'll write down some summary so anybody interested can send me some comments before preparing the deliverable.

pos eso es todo por hoy :D