Deliverables 3 and 5 (SoC2006)

[Petter Reinholdtsen]

[Carlos Villegas]
> 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.

Looks good.  A note for the dash hotspot.  I've discovered a few days
ago that dash actually provide a debconf question to change /bin/sh.
Try 'dpkg-reconfigure dash' to use that method instead.

I notice you tried a few things with reordering.  I've tested insserv
recently myself, and discovered my accident that it will do a very
poor job if it claim to find loops in the dependency graph.
Unfortunately update-bootsystem-insserv do not indicate such problem,
so it might be that corrected dependency info will give a completely
different result.  One indicator I use to detect such problem is
hostname.sh.  IT does not depend on anything, so it should end up very
early in rcS.d/.  In your list of scripts, it is still
rcS.d/S40hostname.sh.  To test if the loop issue is affecting your
test, run 'insserv -v' manually fater you run
update-bootsystem-insserv to enable insserv.  It should not mention
any loops when everything is correct.

I also discovered that the $syslog facility have incorrect value in
/etc/insserv.conf.  It should not list klogd, as klogd itself depend
on $syslog, and thus end up in a dependency loop.

I do notice that the reordering increases the disk throughput, while
there are still some "quiet" periods.  I suspect there are more to
gain from correct dependencies and a better reordering.

I'm very happy to discover that the lintian check you wrote now is
included in the newest release of lintian.  Now we just need to wait
for the maintainers to fix their scripts. :)

Looking at the 'less verbose' hotspot, the result still confuses me.
I have no idea why it take 1 second longer to run with VERBOSE=no.
The only far-fetched idea is that some of the script uses a different
code path, and that this code path is slower.  I discovered today that
there are two settings affecting the verbosity of the boot.  One is
for kernel messages, and it is enabled by specifying the 'quiet'
kernel boot argument, and the other is the 'VERBOSE=no' setting in
default/rcS.  Perhaps the 'quiet' option have more effect than the
VERBOSE setting?  I have no idea.

> Besides, it contains a group of combinations done with the hotspots
> and their effect.

This part is very interesting.  The goal of the boot charts is of
course to try to keep both the CPU and the disk busy, and the
combination graphs seem to indicate that we mostly succeed in trading
one with the other, but not really keeping them both occupied.  I
notice that the combination 4 succeeds in increasing disk utilization,
but at the cost of a lot more IO-wait in the CPU.  There must be some
secret trick to this.  I wonder how the equivalent graph for Ubuntu
is. :/

It would be interesting to know the effect off some of the untested
hotspot, especially prelinking.  Perhaps it does not have any effect
at all. :)

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

This look good too.  There ar ea few minor issues, thought.  The URLs
should be links, and the path to the lintian check is not complete.
Perhaps the lintian section should be updated to mention the bug
number and the fact that a fix is in the released version of lintian?
I guess it should mention the web page reporting the status of the
various scripts,
<URL:http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/lsblist.html>.

I've read the wiki page, and it still look sensible.  The only thing
that might need more info is the use of several names in Provides.  I
believe but have not verified that insserv fail to handle more than
one name in this header.  If this is the case, it should be mentioned
on the wiki page.

This morning I implemented support in update-rc.d to parse the
runlevel part of the LSB header.  The new version is uploaded into
unstable, and should show up tomorrow on the archives.  This code is
activated by creating /etc/update-rc.d-lsbparse.  I did not want to
activate it before we have verified that most scripts have correct
information in their headers. :)

Friendly,
-- 
Petter Reinholdtsen