+ <h3>Entries tagged "bootsystem".</h3>
+
+ <div class="entry">
+ <div class="title">
+ <a href="http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html">How is booting into runlevel 1 different from single user boots?</a>
+ </div>
+ <div class="date">
+ 4th August 2011
+ </div>
+ <div class="body">
+ <p>Wouter Verhelst have some
+<a href="http://grep.be/blog/en/retorts/pere_kubuntu_boot">interesting
+comments and opinions</a> on my blog post on
+<a href="http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html">the
+need to clean up /etc/rcS.d/ in Debian</a> and my blog post about
+<a href="http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html">the
+default KDE desktop in Debian</a>. I only have time to address one
+small piece of his comment now, and though it best to address the
+misunderstanding he bring forward:</p>
+
+<p><blockquote>
+Currently, a system admin has four options: [...] boot to a
+single-user system (by adding 'single' to the kernel command line;
+this runs rcS and rc1 scripts)
+</blockquote></p>
+
+<p>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't the same as single user
+mode. I'll try to explain what is actually happing, but it is a bit
+hard to explain.</p>
+
+<p>Single user mode is defined like this in /etc/inittab:
+"<tt>~~:S:wait:/sbin/sulogin</tt>". This means the only thing that is
+executed in single user mode is sulogin. Single user mode is a boot
+state "between" 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 "init -t1 S" to switch to single user mode at the end of runlevel
+1. It is confusing that the 'S' (single user) init mode is not the
+mode enabled by /etc/rcS.d/ (which is more like the initial boot
+mode).</p>
+
+<p>This summary might make it clearer. When booting for the first
+time into single user mode, the following commands are executed:
+"<tt>/etc/init.d/rc S; /sbin/sulogin</tt>". When booting into
+runlevel 1, the following commands are executed: "<tt>/etc/init.d/rc
+S; /etc/init.d/rc 1; /sbin/sulogin</tt>". 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.</p>
+
+<p>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 <strong>required</strong> to get a
+functioning single user mode during boot.</p>
+
+<p>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.</p>
+
+ </div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/bootsystem">bootsystem</a>, <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title">
+ <a href="http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html">What should start from /etc/rcS.d/ in Debian? - almost nothing</a>
+ </div>
+ <div class="date">
+ 30th July 2011
+ </div>
+ <div class="body">
+ <p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+ </div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/bootsystem">bootsystem</a>, <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title">
+ <a href="http://people.skolelinux.org/pere/blog/Automatic_upgrade_testing_from_Lenny_to_Squeeze.html">Automatic upgrade testing from Lenny to Squeeze</a>
+ </div>
+ <div class="date">
+ 11th June 2010
+ </div>
+ <div class="body">
+ <p>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
+(<a href="http://bugs.debian.org/585410">#585410</a> in nagios3-cgi,
+<a href="http://bugs.debian.org/584879">#584879</a> already fixed in
+enscript and <a href="http://bugs.debian.org/584861">#584861</a> in
+kdebase-workspace-data), and to get a more regular testing going on, I
+am working on a script to automate the test.</p>
projects / homepage.git / blobdiff