SoC boot project weekly summary week #3/14
pere at hungry.com
Sat Jun 17 15:49:21 UTC 2006
Great to see an update of the status. I really look forward to seeing
your results implemented in Debian. :)
> This third week I looked at the woody, sarge and etch releases from
> Debian. They were installed with KDE (with autologin) and
> bootchart. The results were 32 sec for woody, 44 sec for sarge and
> 34 sec for Etch ...(sid results go here)... Nevertheless, it seems
> that bootchart stops logging before you're actually logged in to
How do these numbers compare to wall-clock measurements from the grub
menu until KDE is ready? How much of the boot process is not
accounted for? I expected the boot times for a desktop boot to be
much larger, so the numbers surprise me.
> approach to solve this is to modify bootchart such that it stops until
> a program specified in kdm PostSession.
I suspect the time spent in the initrd environment isn't counted, as
well as the time from the rc script is finished until the KDE desktop
is ready. I do not know how to teach bootchart to measure the entire
boot session including the kde autologin.
> The current results are available in
Very interesting read. :)
> Nevertheless, I didn't keep any log of the installation procedure
> while just accepting all the default configuration (except for using
> always KDE). I'll keep a log on the future to evaluate and
> understand the difference in boot times.
Great. It would be interesting to hear if others installing the same
profile see similar numbers, or if your results are tied to your
hardware in some way.
> Besides, I looked at the SUSE, Mandriva and Fedora distributions to
> analyse their boot process. The most interesting so far has been
> SUSE being LSB compliant and having insserv/startpar to set and
> ajust the dependencies for parallalel booting.
Right. I believe we should all push to get all init.d scripts in
Debian to provide such dependency information as well. I've submitted
a few bug reports to fix it, but there are lots of packages left.
With such information in place, it is possible to detect bugs in the
boot process. I've written a prototype for such checking as part of
the insserv package. Here is an example run on my sid chroot (with a
grep to hide a bug in the script):
# /usr/share/insserv/check-initd-order 2>&1 | grep -v 'Use of uninitialized value'
LSB header missing in /etc/rcS.d/S25libdevmapper1.02
Incorrect order mountvirtfs@ > udev at 03
Incorrect order $local_fs@ > hwclock.sh at 22
Incorrect order $remote_fs@ > hwclock.sh at 22
Incorrect order $lvm@ > resize_lvm at 32
As you can see, there is either bugs in the dependency information or
the run order of a few scripts.
But the script is a ugly hack, and do not take into account other run
levels than S and 2. It should at the very least be able to check the
stop order as well as the start order (for runlevel 1 and 6).
> rcorder in FreeBSD does something similar although it seems to do
> check dependencies in two stages during the boot (with root fs and
> with all mounted filesystems) and does not support runlevels.
One thing I believe rcorder and FreeBSD does correct is to calculate
the order at boot time. If it does not give an unreasonable speed
impact, I believe it is best to let the boot order be dynamic instead
of requiring all packages with init.d scripts to run a program to
update the boot order (like insserv). Only if it does slow the boot
down considerably, it is better to do it every time init.d is updated.
More information about the initscripts-ng-devel