...do a lot of different things while your new Debian Desktop is booting.<br /><br />Well, it's clear that some people in the project are thinking how we can speed up the boot times (no unfortunately i wasn't at debconf). I would like to invite you to split your ideas in two groups: a) Good For Etch; b) Dreams. :P My point here is that with what we've today, without break too much stuff for sure, applying some work where it's necessary we will have something good in December.<br /><br />Btw, i ran bootchart on three scenarios, using the latest weekly built image of testing, installing the desktop task, see my results:<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973355&size=o">Boot without changes (gdm left out)</a> - 2 m 29 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973357&amp;size=o">Adding "CONCURRENCY=shell" in /etc/default/rcS (gdm left out)</a> - 1 m 46 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973356&amp;size=o">Installing insserv and following the instructions in its README</a> - *1 m 29 s*<br /><br />I would like to hear what's the status of this "concurrency" stuff in /etc/default/rcS (is startpar default in sid now?) and if it breaks something. The other point is that we could push insserv tests forward, please read the documentation and do it yourself preparing your own bootchart results for comparison.<br /><br />The next step would add LSB headers in our init scripts, that will take more time because it involves a lot of packages. I think if we can guarantee that insserv and its dependency tree is ok, then we have the needed headers but they're not in the packages. We could release Etch this way, and add this workload to the individual maintainers of packages with init scripts during Etch+1 release cycle.

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.

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.

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).

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.

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)

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.

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 :(

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.

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.

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.

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 :)

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.

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.

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

I've been investigating alternative system inits from time to time the last few years. With the advent of bootchart, there was quite a hype around improving boot times with parallelization and such. Recently this topic has manifested itself in the initscripts-ng group on alioth, and some to-be Google Summer of Code projects. I've been using a modified version of minit for a long time, just lately I was to lazy and switched back to regular init. Since I use suspend2, I don't really reboot my system often anyway. However, minit has more features than being parallel and small. It offers service monitoring and respawning. Which brings me to something missing totally from current linux init systems: service state tracking. Right now, when you start a service, e.g. the web server, you pretty much hope it will never die. Agreed, apache does a good job here. Others may or may not. Mysql uses a really hackish shell script to respawn. And then there are of course tools like monit that check your services and respawn them when needed. There are a couple of things wrong with starting services via SysVInit style scripts from the shell. For example, in order to start a service you need root rights. And then this will "leak" file descriptors from your shell to the daemon (thats why some apps need to be started with "nohup"). Which also causes extra errors with SELinux, for example. And this is just one of the differences from services being started by manually running their init script from the script being run by runlevel changes. Therefore, I think we should move to a new init that can offer full state tracking for services, and is actually used for all services (and not just initial start and getty respawning...) Here's a fairly extensive state diagram I came up with:
Some features I'd like to have in a new init:

• state tracking with interim states
• dependency management with virtual services (e.g. webserver)
• service monitoring and respawning
• control fifos for starting/stopping services through init
• init monitoring socket for e.g. DBUS connector and service failure notifications

Sorry, no comments on my blog, intentionally. Please use the initscripts-ng mailing list for discussion, thats what the list is for!