+<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/Fint_at_milit_ret_ikke_ble_aktivisert_22__juli.html">Fint at militæret ikke ble aktivisert 22. juli</a></div>
+ <div class="date"> 2nd August 2011</div>
+ <div class="body"><p>I <a href="http://www.dagsavisen.no/innenriks/article518719.ece">gårdagens
+dagsavis</a> gjøres det et poeng av at Forsvarets spesialkommando ikke
+ble tatt i bruk da en rykket ut under aksjonene 22. juli. Personlig
+må jeg innrømme at jeg et glad for at militæret ikke ble tatt i bruk,
+og ser ikke det som et problem slik journalisten legger opp til.
+Politi er trent opp til å forholde seg til sivile regler, mens
+militæret er trent opp til å forholde seg til militære regler. For å
+si det litt flåsete, så skal politiet spørre først og skyte etterpå,
+mens militæret skal skyte først og spørre etterpå. Jeg vil helst kun
+ha den første gjengen i aktiv operasjon blant sivile i Norge.</p>
+
+<p>Ikke at jeg egentlig tror våre folk i militæret er mer skyteglade
+enn folk i politiet, men de er trent forskjellig og med forskjellig
+mål for treningen. Politiet er trent på å operere blant sin egen
+sivilbefolkning, mens militære er trent på å operere blant fiendtlige
+tropper. Jeg tror det er en vesentlig forskjell.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk</a>, <a href="http://people.skolelinux.org/pere/blog/tags/personvern">personvern</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Fin_minnemarkering_p__Stortinget_i_dag.html">Fin minnemarkering på Stortinget i dag</a></div>
+ <div class="date"> 1st August 2011</div>
+ <div class="body"><p>Jeg hadde anledning, så jeg deltok på
+<a href="http://www.stortinget.no/no/Hva-skjer-pa-Stortinget/Nyhetsarkiv/Forsidenyheter/2010-2011/Minnemote-mandag-1-august-kl-12/">minnemarkeringen
+på Stortinget</a> i dag. Det var en fin markering, og jeg likte talene.
+For meg er demokrati, åpenhet og humanitet fundert på frihet, som jeg
+håper vi alle vil bidra til å beskytte i tiden som kommer. Jeg
+registrerer at det i Danmark
+<a href="http://www.aftenposten.no/nyheter/iriks/article4189002.ece">diskuteres
+å redusere friheten</a>. Vi bør vite bedre her i Norge. Stoltenberg
+berørte retten til å feile, og den er nært knyttet til muligheten til
+å lykkes. Begge deler krever at en har friheten til å prøve, og den
+er viktig i et samfunn. Friheten til å prøve begrenses når kontroll
+innføres.</p>
+
+<p>Det at noen av stolene i stortingssalen var tomme ga en litt
+uventet ramme til markeringen. Jeg hadde regnet med at
+stortingsrepresentanter, regjeringsmedlemmer og kongehus til sammen
+ville fylle alle setene. Vet ikke hvem som skulle sittet der det var
+ledige plasser, men antar noen var opptatt andre steder. Kanskje i
+begravelser, eller rett og slett var blitt drept (har ikke hørt at
+noen i Stortinget ble drept, men kan ha gått glipp av noe). Det at
+noen manglet synes jeg illustrerte minnestundens poeng godt. Vi
+mangler noen som skulle ha vært blant oss. Det kan aldri gjøres om,
+og bør aldri glemmes.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk</a>, <a href="http://people.skolelinux.org/pere/blog/tags/personvern">personvern</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/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html">What is missing in the Debian desktop, or why my parents use Kubuntu</a></div>
+ <div class="date">29th July 2011</div>
+ <div class="body"><p>While at Debconf11, I have several times during discussions
+mentioned the issues I believe should be improved in Debian for its
+desktop to be useful for more people. The use case for this is my
+parents, which are currently running Kubuntu which solve the
+issues.</p>
+
+<p>I suspect these four missing features are not very hard to
+implement. After all, they are present in Ubuntu, so if we wanted to
+do this in Debian we would have a source.</p>
+
+<ol>
+
+<li><strong>Simple GUI based upgrade of packages.</strong> When there
+are new packages available for upgrades, a icon in the KDE status bar
+indicate this, and clicking on it will activate the simple upgrade
+tool to handle it. I have no problem guiding both of my parents
+through the process over the phone. If a kernel reboot is required,
+this too is indicated by the status bars and the upgrade tool. Last
+time I checked, nothing with the same features was working in KDE in
+Debian.</li>
+
+<li><strong>Simple handling of missing Firefox browser
+plugins.</strong> When the browser encounter a MIME type it do not
+currently have a handler for, it will ask the user if the system
+should search for a package that would add support for this MIME type,
+and if the user say yes, the APT sources will be searched for packages
+advertising the MIME type in their control file (visible in the
+Packages file in the APT archive). If one or more packages are found,
+it is a simple click of the mouse to add support for the missing mime
+type. If the package require the user to accept some non-free
+license, this is explained to the user. The entire process make it
+more clear to the user why something do not work in the browser, and
+make the chances higher for the user to blame the web page authors and
+not the browser for any missing features.</li>
+
+<li><strong>Simple handling of missing multimedia codec/format
+handlers.</strong> When the media players encounter a format or codec
+it is not supporting, a dialog pop up asking the user if the system
+should search for a package that would add support for it. This
+happen with things like MP3, Windows Media or H.264. The selection
+and installation procedure is very similar to the Firefox browser
+plugin handling. This is as far as I know implemented using a
+gstreamer hook. The end result is that the user easily get access to
+the codecs that are present from the APT archives available, while
+explaining more on why a given format is unsupported by Ubuntu.</li>
+
+<li><strong>Better browser handling of some MIME types.</strong> When
+displaying a text/plain file in my Debian browser, it will propose to
+start emacs to show it. If I remember correctly, when doing the same
+in Kunbutu it show the file as a text file in the browser. At least I
+know Opera will show text files within the browser. I much prefer the
+latter behaviour.</li>
+
+</ol>
+
+<p>There are other nice features as well, like the simplified suite
+upgrader, but given that I am the one mostly doing the dist-upgrade,
+it do not matter much.</p>
+
+<p>I really hope we could get these features in place for the next
+Debian release. It would require the coordinated effort of several
+maintainers, but would make the end user experience a lot better.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>, <a href="http://people.skolelinux.org/pere/blog/tags/multimedia">multimedia</a>, <a href="http://people.skolelinux.org/pere/blog/tags/web">web</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <p style="text-align: right;"><a href="index.rss"><img src="http://people.skolelinux.org/pere/blog/xml.gif" alt="RSS feed" width="36" height="14" /></a></p>
+ <div id="sidebar">
+
projects / homepage.git / blobdiff