[homepage.git] / blog / tags / bootsystem / bootsystem.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries tagged bootsystem</title>
                <description>Entries tagged bootsystem</description>
                <link>http://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>Debian init.d boot script example for rsyslog</title>
                <link>http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html</guid>
                <pubDate>Sat, 2 Nov 2013 22:40:00 +0100</pubDate>
                <description>&lt;p&gt;If one of the points of switching to a new init system in Debian is
&lt;a href=&quot;http://thomas.goirand.fr/blog/?p=147&quot;&gt;to get rid of huge
init.d scripts&lt;/a&gt;, I doubt we need to switch away from sysvinit and
init.d scripts at all.  Here is an example init.d script, ie a rewrite
of /etc/init.d/rsyslog:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides:          rsyslog
# Required-Start:    $remote_fs $time
# Required-Stop:     umountnfs $time
# X-Stop-After:      sendsigs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: enhanced syslogd
# Description:       Rsyslog is an enhanced multi-threaded syslogd.
#                    It is quite compatible to stock sysklogd and can be 
#                    used as a drop-in replacement.
### END INIT INFO
DESC=&quot;enhanced syslogd&quot;
DAEMON=/usr/sbin/rsyslogd
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Pretty minimalistic to me... For the record, the original sysv-rc
script was 137 lines, and the above is just 15 lines, most of the meta
info/comments.&lt;/p&gt;

&lt;p&gt;How to do this, you ask?  Well, one create a new script
/lib/init/init-d-script looking something like this:

&lt;p&gt;&lt;pre&gt;
#!/bin/sh

# Define LSB log_* functions.
# Depend on lsb-base (&gt;= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service

#
do_start()
{
        # Return
        #   0 if daemon has been started
        #   1 if daemon was already running
        #   2 if daemon could not be started
        start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test &gt; /dev/null \
                || return 1
        start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
                $DAEMON_ARGS \
                || return 2
        # Add code here, if necessary, that waits for the process to be ready
        # to handle requests from services started subsequently which depend
        # on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
        # Return
        #   0 if daemon has been stopped
        #   1 if daemon was already stopped
        #   2 if daemon could not be stopped
        #   other if a failure occurred
        start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
        RETVAL=&quot;$?&quot;
        [ &quot;$RETVAL&quot; = 2 ] &amp;&amp; return 2
        # Wait for children to finish too if this is a daemon that forks
        # and if the daemon is only ever run from this initscript.
        # If the above conditions are not satisfied then add some other code
        # that waits for the process to drop all resources that could be
        # needed by services started subsequently.  A last resort is to
        # sleep for some time.
        start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
        [ &quot;$?&quot; = 2 ] &amp;&amp; return 2
        # Many daemons don&#39;t delete their pidfiles when they exit.
        rm -f $PIDFILE
        return &quot;$RETVAL&quot;
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
        #
        # If the daemon can reload its configuration without
        # restarting (for example, when it is sent a SIGHUP),
        # then implement that here.
        #
        start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
        return 0
}

SCRIPTNAME=$1
scriptbasename=&quot;$(basename $1)&quot;
echo &quot;SN: $scriptbasename&quot;
if [ &quot;$scriptbasename&quot; != &quot;init-d-library&quot; ] ; then
    script=&quot;$1&quot;
    shift
    . $script
else
    exit 0
fi

NAME=$(basename $DAEMON)
PIDFILE=/var/run/$NAME.pid

# Exit if the package is not installed
#[ -x &quot;$DAEMON&quot; ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] &amp;&amp; . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

case &quot;$1&quot; in
  start)
        [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_daemon_msg &quot;Starting $DESC&quot; &quot;$NAME&quot;
        do_start
        case &quot;$?&quot; in
                0|1) [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_end_msg 0 ;;
                2) [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_end_msg 1 ;;
        esac
        ;;
  stop)
        [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_daemon_msg &quot;Stopping $DESC&quot; &quot;$NAME&quot;
        do_stop
        case &quot;$?&quot; in
                0|1) [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_end_msg 0 ;;
                2) [ &quot;$VERBOSE&quot; != no ] &amp;&amp; log_end_msg 1 ;;
        esac
        ;;
  status)
        status_of_proc &quot;$DAEMON&quot; &quot;$NAME&quot; &amp;&amp; exit 0 || exit $?
        ;;
  #reload|force-reload)
        #
        # If do_reload() is not implemented then leave this commented out
        # and leave &#39;force-reload&#39; as an alias for &#39;restart&#39;.
        #
        #log_daemon_msg &quot;Reloading $DESC&quot; &quot;$NAME&quot;
        #do_reload
        #log_end_msg $?
        #;;
  restart|force-reload)
        #
        # If the &quot;reload&quot; option is implemented then remove the
        # &#39;force-reload&#39; alias
        #
        log_daemon_msg &quot;Restarting $DESC&quot; &quot;$NAME&quot;
        do_stop
        case &quot;$?&quot; in
          0|1)
                do_start
                case &quot;$?&quot; in
                        0) log_end_msg 0 ;;
                        1) log_end_msg 1 ;; # Old process is still running
                        *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
          *)
                # Failed to stop
                log_end_msg 1
                ;;
        esac
        ;;
  *)
        echo &quot;Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}&quot; &gt;&amp;2
        exit 3
        ;;
esac

:
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;It is based on /etc/init.d/skeleton, and could be improved quite a
lot.  I did not really polish the approach, so it might not always
work out of the box, but you get the idea.  I did not try very hard to
optimize it nor make it more robust either.&lt;/p&gt;

&lt;p&gt;A better argument for switching init system in Debian than reducing
the size of init scripts (which is a good thing to do anyway), is to
get boot system that is able to handle the kernel events sensibly and
robustly, and do not depend on the boot to run sequentially.  The boot
and the kernel have not behaved sequentially in year.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>How is booting into runlevel 1 different from single user boots?</title>
                <link>http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html</guid>
                <pubDate>Thu, 4 Aug 2011 12:40:00 +0200</pubDate>
                <description>&lt;p&gt;Wouter Verhelst have some
&lt;a href=&quot;http://grep.be/blog/en/retorts/pere_kubuntu_boot&quot;&gt;interesting
comments and opinions&lt;/a&gt; on my blog post on
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html&quot;&gt;the
need to clean up /etc/rcS.d/ in Debian&lt;/a&gt; and my blog post about
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html&quot;&gt;the
default KDE desktop in Debian&lt;/a&gt;.  I only have time to address one
small piece of his comment now, and though it best to address the
misunderstanding he bring forward:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
Currently, a system admin has four options: [...] boot to a
single-user system (by adding &#39;single&#39; to the kernel command line;
this runs rcS and rc1 scripts)
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;This make me believe Wouter believe booting into single user mode
and booting into runlevel 1 is the same.  I am not surprised he
believe this, because it would make sense and is a quite sensible
thing to believe.  But because the boot in Debian is slightly broken,
runlevel 1 do not work properly and it isn&#39;t the same as single user
mode.  I&#39;ll try to explain what is actually happing, but it is a bit
hard to explain.&lt;/p&gt;

&lt;p&gt;Single user mode is defined like this in /etc/inittab:
&quot;&lt;tt&gt;~~:S:wait:/sbin/sulogin&lt;/tt&gt;&quot;.  This means the only thing that is
executed in single user mode is sulogin.  Single user mode is a boot
state &quot;between&quot; the runlevels, and when booting into single user mode,
only the scripts in /etc/rcS.d/ are executed before the init process
enters the single user state.  When switching to runlevel 1, the state
is in fact not ending in runlevel 1, but it passes through runlevel 1
and end up in the single user mode (see /etc/rc1.d/S03single, which
runs &quot;init -t1 S&quot; to switch to single user mode at the end of runlevel
1.  It is confusing that the &#39;S&#39; (single user) init mode is not the
mode enabled by /etc/rcS.d/ (which is more like the initial boot
mode).&lt;/p&gt;

&lt;p&gt;This summary might make it clearer.  When booting for the first
time into single user mode, the following commands are executed:
&quot;&lt;tt&gt;/etc/init.d/rc S; /sbin/sulogin&lt;/tt&gt;&quot;.  When booting into
runlevel 1, the following commands are executed: &quot;&lt;tt&gt;/etc/init.d/rc
S; /etc/init.d/rc 1; /sbin/sulogin&lt;/tt&gt;&quot;.  A problem show up when
trying to continue after visiting single user mode.  Not all services
are started again as they should, causing the machine to end up in an
unpredicatble state.  This is why Debian admins recommend rebooting
after visiting single user mode.&lt;/p&gt;

&lt;p&gt;A similar problem with runlevel 1 is caused by the amount of
scripts executed from /etc/rcS.d/.  When switching from say runlevel 2
to runlevel 1, the services started from /etc/rcS.d/ are not properly
stopped when passing through the scripts in /etc/rc1.d/, and not
started again when switching away from runlevel 1 to the runlevels
2-5.  I believe the problem is best fixed by moving all the scripts
out of /etc/rcS.d/ that are not &lt;strong&gt;required&lt;/strong&gt; to get a
functioning single user mode during boot.&lt;/p&gt;

&lt;p&gt;I have spent several years investigating the Debian boot system,
and discovered this problem a few years ago.  I suspect it originates
from when sysvinit was introduced into Debian, a long time ago.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>What should start from /etc/rcS.d/ in Debian? - almost nothing</title>
                <link>http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</guid>
                <pubDate>Sat, 30 Jul 2011 14:00:00 +0200</pubDate>
                <description>&lt;p&gt;In the Debian boot system, several packages include scripts that
are started from /etc/rcS.d/.  In fact, there is a bite more of them
than make sense, and this causes a few problems.  What kind of
problems, you might ask.  There are at least two problems.  The first
is that it is not possible to recover a machine after switching to
runlevel 1.  One need to actually reboot to get the machine back to
the expected state.  The other is that single user boot will sometimes
run into problems because some of the subsystems are activated before
the root login is presented, causing problems when trying to recover a
machine from a problem in that subsystem.  A minor additional point is
that moving more scripts out of rcS.d/ and into the other rc#.d/
directories will increase the amount of scripts that can run in
parallel during boot, and thus decrease the boot time.&lt;/p&gt;

&lt;p&gt;So, which scripts should start from rcS.d/.  In short, only the
scripts that _have_ to execute before the root login prompt is
presented during a single user boot should go there.  Everything else
should go into the numeric runlevels.  This means things like
lm-sensors, fuse and x11-common should not run from rcS.d, but from
the numeric runlevels.  Today in Debian, there are around 115 init.d
scripts that are started from rcS.d/, and most of them should be moved
out.  Do your package have one of them?  Please help us make single
user and runlevel 1 better by moving it.&lt;/p&gt;

&lt;p&gt;Scripts setting up the screen, keyboard, system partitions
etc. should still be started from rcS.d/, but there is for example no
need to have the network enabled before the single user login prompt
is presented.&lt;/p&gt;

&lt;p&gt;As always, things are not so easy to fix as they sound.  To keep
Debian systems working while scripts migrate and during upgrades, the
scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
order, ie the scripts that nothing in rcS.d/ depend on can be moved,
and the next ones can only be moved when their dependencies have been
moved first.  This migration must be done sequentially while we ensure
that the package system upgrade packages in the right order to keep
the system state correct.  This will require some coordination when it
comes to network related packages, but most of the packages with
scripts that should migrate do not have anything in rcS.d/ depending
on them.  Some packages have already been updated, like the sudo
package, while others are still left to do.  I wish I had time to work
on this myself, but real live constrains make it unlikely that I will
find time to push this forward.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Automatic upgrade testing from Lenny to Squeeze</title>
                <link>http://people.skolelinux.org/pere/blog/Automatic_upgrade_testing_from_Lenny_to_Squeeze.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Automatic_upgrade_testing_from_Lenny_to_Squeeze.html</guid>
                <pubDate>Fri, 11 Jun 2010 22:50:00 +0200</pubDate>
                <description>&lt;p&gt;The last few days I have done some upgrade testing in Debian, to
see if the upgrade from Lenny to Squeeze will go smoothly.  A few bugs
have been discovered and reported in the process
(&lt;a href=&quot;http://bugs.debian.org/585410&quot;&gt;#585410&lt;/a&gt; in nagios3-cgi,
&lt;a href=&quot;http://bugs.debian.org/584879&quot;&gt;#584879&lt;/a&gt; already fixed in
enscript and &lt;a href=&quot;http://bugs.debian.org/584861&quot;&gt;#584861&lt;/a&gt; in
kdebase-workspace-data), and to get a more regular testing going on, I
am working on a script to automate the test.&lt;/p&gt;

&lt;p&gt;The idea is to create a Lenny chroot and use tasksel to install a
Gnome or KDE desktop installation inside the chroot before upgrading
it.  To ensure no services are started in the chroot, a policy-rc.d
script is inserted.  To make sure tasksel believe it is to install a
desktop on a laptop, the tasksel tests are replaced in the chroot
(only acceptable because this is a throw-away chroot).&lt;/p&gt;

&lt;p&gt;A naive upgrade from Lenny to Squeeze using aptitude dist-upgrade
currently always fail because udev refuses to upgrade with the kernel
in Lenny, so to avoid that problem the file /etc/udev/kernel-upgrade
is created.  The bug report
&lt;a href=&quot;http://bugs.debian.org/566000&quot;&gt;#566000&lt;/a&gt; make me suspect
this problem do not trigger in a chroot, but I touch the file anyway
to make sure the upgrade go well.  Testing on virtual and real
hardware have failed me because of udev so far, and creating this file
do the trick in such settings anyway.  This is a
&lt;a href=&quot;http://www.linuxquestions.org/questions/debian-26/failed-dist-upgrade-due-to-udev-config_sysfs_deprecated-nonsense-804130/&quot;&gt;known
issue&lt;/a&gt; and the current udev behaviour is intended by the udev
maintainer because he lack the resources to rewrite udev to keep
working with old kernels or something like that.  I really wish the
udev upstream would keep udev backwards compatible, to avoid such
upgrade problem, but given that they fail to do so, I guess
documenting the way out of this mess is the best option we got for
Debian Squeeze.&lt;/p&gt;

&lt;p&gt;Anyway, back to the task at hand, testing upgrades.  This test
script, which I call &lt;tt&gt;upgrade-test&lt;/tt&gt; for now, is doing the
trick:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
#!/bin/sh
set -ex

if [ &quot;$1&quot; ] ; then
    desktop=$1
else
    desktop=gnome
fi

from=lenny
to=squeeze

exec &amp;lt; /dev/null
unset LANG
mirror=http://ftp.skolelinux.org/debian
tmpdir=chroot-$from-upgrade-$to-$desktop
fuser -mv .
debootstrap $from $tmpdir $mirror
chroot $tmpdir aptitude update
cat &gt; $tmpdir/usr/sbin/policy-rc.d &amp;lt;&amp;lt;EOF
#!/bin/sh
exit 101
EOF
chmod a+rx $tmpdir/usr/sbin/policy-rc.d
exit_cleanup() {
    umount $tmpdir/proc
}
mount -t proc proc $tmpdir/proc
# Make sure proc is unmounted also on failure
trap exit_cleanup EXIT INT

chroot $tmpdir aptitude -y install debconf-utils

# Make sure tasksel autoselection trigger.  It need the test scripts
# to return the correct answers.
echo tasksel tasksel/desktop multiselect $desktop | \
    chroot $tmpdir debconf-set-selections

# Include the desktop and laptop task
for test in desktop laptop ; do
    echo &gt; $tmpdir/usr/lib/tasksel/tests/$test &amp;lt;&amp;lt;EOF
#!/bin/sh
exit 2
EOF
    chmod a+rx $tmpdir/usr/lib/tasksel/tests/$test
done

DEBIAN_FRONTEND=noninteractive
DEBIAN_PRIORITY=critical
export DEBIAN_FRONTEND DEBIAN_PRIORITY
chroot $tmpdir tasksel --new-install

echo deb $mirror $to main &gt; $tmpdir/etc/apt/sources.list
chroot $tmpdir aptitude update
touch $tmpdir/etc/udev/kernel-upgrade
chroot $tmpdir aptitude -y dist-upgrade
fuser -mv
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;I suspect it would be useful to test upgrades with both apt-get and
with aptitude, but I have not had time to look at how they behave
differently so far.  I hope to get a cron job running to do the test
regularly and post the result on the web.  The Gnome upgrade currently
work, while the KDE upgrade fail because of the bug in
kdebase-workspace-data&lt;/p&gt;

&lt;p&gt;I am not quite sure what kind of extract from the huge upgrade logs
(KDE 167 KiB, Gnome 516 KiB) it make sense to include in this blog
post, so I will refrain from trying.  I can report that for Gnome,
aptitude report 760 packages upgraded, 448 newly installed, 129 to
remove and 1 not upgraded and 1024MB need to be downloaded while for
KDE the same numbers are 702 packages upgraded, 507 newly installed,
193 to remove and 0 not upgraded and 1117MB need to be downloaded&lt;/p&gt;

&lt;p&gt;I am very happy to notice that the Gnome desktop + laptop upgrade
is able to migrate to dependency based boot sequencing and parallel
booting without a hitch.  Was unsure if there were still bugs with
packages failing to clean up their obsolete init.d script during
upgrades, and no such problem seem to affect the Gnome desktop+laptop
packages.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Upstart or sysvinit - as init.d scripts see it</title>
                <link>http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</guid>
                <pubDate>Sun, 6 Jun 2010 23:55:00 +0200</pubDate>
                <description>&lt;p&gt;If Debian is to migrate to upstart on Linux, I expect some init.d
scripts to migrate (some of) their operations to upstart job while
keeping the init.d for hurd and kfreebsd.  The packages with such
needs will need a way to get their init.d scripts to behave
differently when used with sysvinit and with upstart.  Because of
this, I had a look at the environment variables set when a init.d
script is running under upstart, and when it is not.&lt;/p&gt;

&lt;p&gt;With upstart, I notice these environment variables are set when a
script is started from rcS.d/ (ignoring some irrelevant ones like
COLUMNS):&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
DEFAULT_RUNLEVEL=2
previous=N
PREVLEVEL=
RUNLEVEL=
runlevel=S
UPSTART_EVENTS=startup
UPSTART_INSTANCE=
UPSTART_JOB=rc-sysinit
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;With sysvinit, these environment variables are set for the same
script.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
INIT_VERSION=sysvinit-2.88
previous=N
PREVLEVEL=N
RUNLEVEL=S
runlevel=S
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;The RUNLEVEL and PREVLEVEL environment variables passed on from
sysvinit are not set by upstart.  Not sure if it is intentional or not
to not be compatible with sysvinit in this regard.&lt;/p&gt;

&lt;p&gt;For scripts needing to behave differently when upstart is used,
looking for the UPSTART_JOB environment variable seem to be a good
choice.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>KDM fail at boot with NVidia cards - and no one try to fix it?</title>
                <link>http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</guid>
                <pubDate>Tue, 1 Jun 2010 17:05:00 +0200</pubDate>
                <description>&lt;p&gt;It is strange to watch how a bug in Debian causing KDM to fail to
start at boot when an NVidia video card is used is handled.  The
problem seem to be that the nvidia X.org driver uses a long time to
initialize, and this duration is longer than kdm is configured to
wait.&lt;/p&gt;

&lt;p&gt;I came across two bugs related to this issue,
&lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;#583312&lt;/a&gt; initially filed
against initscripts and passed on to nvidia-glx when it became obvious
that the nvidia drivers were involved, and
&lt;a href=&quot;http://bugs.debian.org/524751&quot;&gt;#524751&lt;/a&gt; initially filed against
kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.&lt;/p&gt;

&lt;p&gt;To me, it seem that no-one is interested in actually solving the
problem nvidia video card owners experience and make sure the Debian
distribution work out of the box for these users.  The nvidia driver
maintainers expect kdm to be set up to wait longer, while kdm expect
the nvidia driver maintainers to fix the driver to start faster, and
while they wait for each other I guess the users end up switching to a
distribution that work for them.  I have no idea what the solution is,
but I am pretty sure that waiting for each other is not it.&lt;/p&gt;

&lt;p&gt;I wonder why we end up handling bugs this way.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellized boot seem to hold up well in Debian/testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</guid>
                <pubDate>Thu, 27 May 2010 23:55:00 +0200</pubDate>
                <description>&lt;p&gt;A few days ago, parallel booting was enabled in Debian/testing.
The feature seem to hold up pretty well, but three fairly serious
issues are known and should be solved:

&lt;p&gt;&lt;ul&gt;

&lt;li&gt;The wicd package seen to
&lt;a href=&quot;http://bugs.debian.org/508289&quot;&gt;break NFS mounting&lt;/a&gt; and
&lt;a href=&quot;http://bugs.debian.org/581586&quot;&gt;network setup&lt;/a&gt; when
parallel booting is enabled.  No idea why, but the wicd maintainer
seem to be on the case.&lt;/li&gt;

&lt;li&gt;The nvidia X driver seem to
&lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;have a race condition&lt;/a&gt;
triggered more easily when parallel booting is in effect.  The
maintainer is on the case.&lt;/li&gt;

&lt;li&gt;The sysv-rc package fail to properly enable dependency based boot
sequencing (the shutdown is broken) when old file-rc users
&lt;a href=&quot;http://bugs.debian.org/575080&quot;&gt;try to switch back&lt;/a&gt; to
sysv-rc.  One way to solve it would be for file-rc to create
/etc/init.d/.legacy-bootordering, and another is to try to make
sysv-rc more robust.  Will investigate some more and probably upload a
workaround in sysv-rc to help those trying to move from file-rc to
sysv-rc get a working shutdown.&lt;/li&gt;

&lt;/ul&gt;&lt;/p&gt;

&lt;p&gt;All in all not many surprising issues, and all of them seem
solvable before Squeeze is released.  In addition to these there are
some packages with bugs in their dependencies and run level settings,
which I expect will be fixed in a reasonable time span.&lt;/p&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Update: Correct bug number to file-rc issue.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellized boot is now the default in Debian/unstable</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</guid>
                <pubDate>Fri, 14 May 2010 22:40:00 +0200</pubDate>
                <description>&lt;p&gt;Since this evening, parallel booting is the default in
Debian/unstable for machines using dependency based boot sequencing.
Apparently the testing of concurrent booting has been wider than
expected, if I am to believe the
&lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg00122.html&quot;&gt;input
on debian-devel@&lt;/a&gt;, and I concluded a few days ago to move forward
with the feature this weekend, to give us some time to detect any
remaining problems before Squeeze is frozen.  If serious problems are
detected, it is simple to change the default back to sequential boot.
The upload of the new sysvinit package also activate a new upstream
version.&lt;/p&gt;

More information about
&lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
based boot sequencing&lt;/a&gt; is available from the Debian wiki.  It is
currently possible to disable parallel booting when one run into
problems caused by it, by adding this line to /etc/default/rcS:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
CONCURRENCY=none
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>systemd, an interesting alternative to upstart</title>
                <link>http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html</guid>
                <pubDate>Thu, 13 May 2010 22:20:00 +0200</pubDate>
                <description>&lt;p&gt;The last few days a new boot system called
&lt;a href=&quot;http://www.freedesktop.org/wiki/Software/systemd&quot;&gt;systemd&lt;/a&gt;
has been
&lt;a href=&quot;http://0pointer.de/blog/projects/systemd.html&quot;&gt;introduced&lt;/a&gt;

to the free software world.  I have not yet had time to play around
with it, but it seem to be a very interesting alternative to
&lt;a href=&quot;http://upstart.ubuntu.com/&quot;&gt;upstart&lt;/a&gt;, and might prove to be
a good alternative for Debian when we are able to switch to an event
based boot system.  Tollef is
&lt;a href=&quot;http://bugs.debian.org/580814&quot;&gt;in the process&lt;/a&gt; of getting
systemd into Debian, and I look forward to seeing how well it work.  I
like the fact that systemd handles init.d scripts with dependency
information natively, allowing them to run in parallel where upstart
at the moment do not.&lt;/p&gt;

&lt;p&gt;Unfortunately do systemd have the same problem as upstart regarding
platform support.  It only work on recent Linux kernels, and also need
some new kernel features enabled to function properly.  This means
kFreeBSD and Hurd ports of Debian will need a port or a different boot
system.  Not sure how that will be handled if systemd proves to be the
way forward.&lt;/p&gt;

&lt;p&gt;In the mean time, based on the
&lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg00122.html&quot;&gt;input
on debian-devel@&lt;/a&gt; regarding parallel booting in Debian, I have
decided to enable full parallel booting as the default in Debian as
soon as possible (probably this weekend or early next week), to see if
there are any remaining serious bugs in the init.d dependencies.  A
new version of the sysvinit package implementing this change is
already in experimental.  If all go well, Squeeze will be released
with parallel booting enabled by default.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellizing the boot in Debian Squeeze - ready for wider testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html</guid>
                <pubDate>Thu, 6 May 2010 23:25:00 +0200</pubDate>
                <description>&lt;p&gt;These days, the init.d script dependencies in Squeeze are quite
complete, so complete that it is actually possible to run all the
init.d scripts in parallell based on these dependencies.  If you want
to test your Squeeze system, make sure
&lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
based boot sequencing&lt;/a&gt; is enabled, and add this line to
/etc/default/rcS:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
CONCURRENCY=makefile
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;That is it.  It will cause sysv-rc to use the startpar tool to run
scripts in parallel using the dependency information stored in
/etc/init.d/.depend.boot, /etc/init.d/.depend.start and
/etc/init.d/.depend.stop to order the scripts.  Startpar is configured
to try to start the kdm and gdm scripts as early as possible, and will
start the facilities required by kdm or gdm as early as possible to
make this happen.&lt;/p&gt;

&lt;p&gt;Give it a try, and see if you like the result.  If some services
fail to start properly, it is most likely because they have incomplete
init.d script dependencies in their startup script (or some of their
dependent scripts have incomplete dependencies).  Report bugs and get
the package maintainers to fix it. :)&lt;/p&gt;

&lt;p&gt;Running scripts in parallel could be the default in Debian when we
manage to get the init.d script dependencies complete and correct.  I
expect we will get there in Squeeze+1, if we get manage to test and
fix the remaining issues.&lt;/p&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Debian has switched to dependency based boot sequencing</title>
                <link>http://people.skolelinux.org/pere/blog/Debian_has_switched_to_dependency_based_boot_sequencing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_has_switched_to_dependency_based_boot_sequencing.html</guid>
                <pubDate>Mon, 27 Jul 2009 23:50:00 +0200</pubDate>
                <description>&lt;p&gt;Since this evening, with the upload of sysvinit version 2.87dsf-2,
and the upload of insserv version 1.12.0-10 yesterday, Debian unstable
have been migrated to using dependency based boot sequencing.  This
conclude work me and others have been doing for the last three days.
It feels great to see this finally part of the default Debian
installation.  Now we just need to weed out the last few problems that
are bound to show up, to get everything ready for Squeeze.&lt;/p&gt;

&lt;p&gt;The next step is migrating /sbin/init from sysvinit to upstart, and
fixing the more fundamental problem of handing the event based
non-predictable kernel in the early boot.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Taking over sysvinit development</title>
                <link>http://people.skolelinux.org/pere/blog/Taking_over_sysvinit_development.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Taking_over_sysvinit_development.html</guid>
                <pubDate>Wed, 22 Jul 2009 23:00:00 +0200</pubDate>
                <description>&lt;p&gt;After several years of frustration with the lack of activity from
the existing sysvinit upstream developer, I decided a few weeks ago to
take over the package and become the new upstream.  The number of
patches to track for the Debian package was becoming a burden, and the
lack of synchronization between the distribution made it hard to keep
the package up to date.&lt;/p&gt;

&lt;p&gt;On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
and my Debian co-maintainer Kel Modderman.  About 10 days ago, I made
a new upstream tarball with version number 2.87dsf (for Debian, SuSe
and Fedora), based on the patches currently in use in these
distributions.  We Debian maintainers plan to move to this tarball as
the new upstream as soon as we find time to do the merge.  Since the
new tarball was created, we agreed with Werner at SuSe to make a new
upstream project at &lt;a href=&quot;http://savannah.nongnu.org/&quot;&gt;Savannah&lt;/a&gt;, and continue
development there.  The project is registered and currently waiting
for approval by the Savannah administrators, and as soon as it is
approved, we will import the old versions from svn and continue
working on the future release.&lt;/p&gt;

&lt;p&gt;It is a bit ironic that this is done now, when some of the involved
distributions are moving to upstart as a syvinit replacement.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Debian boots quicker and quicker</title>
                <link>http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html</guid>
                <pubDate>Wed, 24 Jun 2009 21:40:00 +0200</pubDate>
                <description>&lt;p&gt;I spent Monday and tuesday this week in London with a lot of the
people involved in the boot system on Debian and Ubuntu, to see if we
could find more ways to speed up the boot system.  This was an Ubuntu
funded
&lt;a href=&quot;https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint&quot;&gt;developer
gathering&lt;/a&gt;. It was quite productive.  We also discussed the future
of boot systems, and ways to handle the increasing number of boot
issues introduced by the Linux kernel becoming more and more
asynchronous and event base.  The Ubuntu approach using udev and
upstart might be a good way forward.  Time will show.&lt;/p&gt;

&lt;p&gt;Anyway, there are a few ways at the moment to speed up the boot
process in Debian.  All of these should be applied to get a quick
boot:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Use dash as /bin/sh.&lt;/li&gt;

&lt;li&gt;Disable the init.d/hwclock*.sh scripts and make sure the hardware
   clock is in UTC.&lt;/li&gt;

&lt;li&gt;Install and activate the insserv package to enable
   &lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
   based boot sequencing&lt;/a&gt;, and enable concurrent booting.&lt;/li&gt;

&lt;/ul&gt;

These points are based on the Google summer of code work done by
&lt;a href=&quot;http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/&quot;&gt;Carlos
Villegas&lt;/a&gt;.

&lt;p&gt;Support for makefile-style concurrency during boot was uploaded to
unstable yesterday.  When we tested it, we were able to cut 6 seconds
from the boot sequence.  It depend on very correct dependency
declaration in all init.d scripts, so I expect us to find edge cases
where the dependences in some scripts are slightly wrong when we start
using this.&lt;/p&gt;

&lt;p&gt;On our IRC channel for this effort, #pkg-sysvinit, a new idea was
introduced by Raphael Geissert today, one that could affect the
startup speed as well.  Instead of starting some scripts concurrently
from rcS.d/ and another set of scripts from rc2.d/, it would be
possible to run a of them in the same process.  A quick way to test
this would be to enable insserv and run &#39;mv /etc/rc2.d/S* /etc/rcS.d/;
insserv&#39;.  Will need to test if that work. :)&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>