+from=lenny
+to=squeeze
+
+exec < /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 > $tmpdir/usr/sbin/policy-rc.d <<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 > $tmpdir/usr/lib/tasksel/tests/$test <<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 > $tmpdir/etc/apt/sources.list
+chroot $tmpdir aptitude update
+touch $tmpdir/etc/udev/kernel-upgrade
+chroot $tmpdir aptitude -y dist-upgrade
+fuser -mv
+</pre></blockquote>
+
+<p>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</p>
+
+<p>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</p>
+
+<p>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.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Skolelinux er laget for sentraldrifting, naturligvis</title>
+ <link>http://people.skolelinux.org/pere/blog/Skolelinux_er_laget_for_sentraldrifting__naturligvis.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Skolelinux_er_laget_for_sentraldrifting__naturligvis.html</guid>
+ <pubDate>Wed, 9 Jun 2010 12:30:00 +0200</pubDate>
+ <description><p>Det er merkelig hvordan myter om Skolelinux overlever. En slik
+myte er at Skolelinux ikke kan sentraldriftes og ha sentralt plasserte
+tjenermaskiner. I siste Computerworld Norge er
+<a href="http://www.idg.no/computerworld/article169432.ece">IT-sjef
+Viggo Billdal i Steinkjer intervjuet</a>, og forteller uten
+blygsel:</p>
+
+<blockquote><p>Vi hadde Skolelinux, men det har vi sluttet med. Vi testet
+om det lønte seg med Microsoft eller en åpen plattform. Vi fant ut at
+Microsoft egentlig var totalt sett bedre egnet. Det var store
+driftskostnader med Skolelinux, blant annet på grunn av
+desentraliserte servere. Det var komplisert, så vi gikk vekk fra det
+og bruker nå bare Windows.</p></blockquote>
+
+<p>En <a
+href="https://init.linpro.no/pipermail/skolelinux.no/bruker/2010-June/009101.html">rask
+sjekk</a> mot den norske brukerlista i Skolelinuxprosjektet forteller
+at Steinkjers forsøk foregikk fram til 2004/2005, og at Røysing skole
+i Steinkjer skal ha vært svært fornøyd med Skolelinux men at kommunen
+overkjørte skolen og krevde at de gikk over til Windows. Et søk på
+nettet sendte meg til
+<a href="http://www.dn.no/multimedia/archive/00090/Dagens_it_nr__18_90826a.pdf">Dagens
+IT nr. 18 2005</a> hvor en kan lese på side 18:</p>
+
+<blockquote><p>Inge Tømmerås ved Røysing skole i Steinkjer kjører ennå
+Microsoft, men forteller at kompetanseutfordringen med Skolelinux ikke
+var så stor. Jeg syntes Skolelinux var utrolig lett å drifte uten
+forkunnskaper. Men man må jo selvsagt ha tilgang på ekstern kompetanse
+til installasjoner og maskinvarefeil, sier Tømmerås.</p></blockquote>
+
+<p>Som systemarkitekten bak Skolelinux, kan jeg bare riste på hodet
+over påstanden om at Skolelinux krever desentraliserte tjenere.
+Skolelinux-arkitekturen er laget for sentralisert drift og plassering
+av tjenerne lokalt eller sentralt alt etter behov og nettkapasitet.
+Den er modellert på nettverks- og tjenerløsningen som brukes på
+Universitetet i Tromsø og Oslo, der jeg jobber med utvikling av
+driftstjenester. Dette er det heldigvis noen som har fått med seg, og
+jeg er glad for å kunne sitere fra en kommentar på den overnevnte
+artikkelen. Min venn og gamle kollega Sturle Sunde forteller der:
+
+<blockquote>
+<p>I Flora kommune køyrer vi Skulelinux på skular med alt frå 15 til
+meir enn 500 elevar. Dei store skulane har eigen tenar, for det er
+mest praktisk. Eg, som er driftsansvarleg for heile nettet, ser
+sjeldan dei tenarane fysisk, men at dei står der gjer skulane mindre
+avhengige av eksterne linjer som er trege eller dyre. Dei minste
+skulane har ikkje eigen tenar. Å bruke sentral tenar er heller ikkje
+noko problem. Småskulane klarar seg fint med 1 mbit-linje til ein
+sentral tenar eller tenaren på ein større skule.</p>
+
+<p>Det beste med Skulelinux er halvtjukke klientar. Dei treng ikkje
+harddisk og brukar minimalt med ressursar på tenaren fordi dei køyrer
+programma lokalt. Eit klasserom med 30 sju-åtte år gamle maskiner har
+mykje meir CPU og RAM totalt enn nokon moderne tenar til under
+millionen. Det trengst to kommandoar på den sentrale tenaren for å
+oppdatere alle klientane, både tynne og halvtjukke. Vi har ingen
+problem med diskar som ryk heller, som var eit problem før fordi
+elevane sat og sparka i maskinene. Og dei krev lite bandbreidde i
+nettet, so det er fullt mogleg å køyre slike på småskular med trege
+linjer mot tenaren på ein større skule.</p>
+
+<p>Flora kommune har nesten 800 Linux-maskiner i sitt skulenett, og
+ein person som tek seg av drift av heile nettet, inkludert tenarar,
+klientar, operativsystem, programvare, heimekontorløysing og
+administrasjon av brukarar.</p>
+
+<p>No skal det seiast at vi ikkje køyrer rein Skulelinux ut av
+boksen. Vi har gjort ein del tilpassingar mot noko Novell-greier som
+var der frå før, og som har komplisert installasjonen vår. Etter at
+oppsettet var gjort har løysinga vore stabil og kravd minimalt med
+arbeid.</p>
+</blockquote>
+
+<p>Jeg vet at Narvik, Harstad og Oslo er kommuner der Skolelinux
+sentraldriftes med sentrale tjenere. Det forteller meg at Steinkjers
+IT-sjef neppe bør skylde på Skolelinux-løsningen for sine 5 år gamle
+minner.</p>
+</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><p>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.</p>
+
+<p>With upstart, I notice these environment variables are set when a
+script is started from rcS.d/ (ignoring some irrelevant ones like
+COLUMNS):</p>
+
+<blockquote><pre>
+DEFAULT_RUNLEVEL=2
+previous=N
+PREVLEVEL=
+RUNLEVEL=
+runlevel=S
+UPSTART_EVENTS=startup
+UPSTART_INSTANCE=
+UPSTART_JOB=rc-sysinit
+</pre></blockquote>
+
+<p>With sysvinit, these environment variables are set for the same
+script.</p>
+
+<blockquote><pre>
+INIT_VERSION=sysvinit-2.88
+previous=N
+PREVLEVEL=N
+RUNLEVEL=S
+runlevel=S
+</pre></blockquote>
+
+<p>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.</p>
+
+<p>For scripts needing to behave differently when upstart is used,
+looking for the UPSTART_JOB environment variable seem to be a good
+choice.</p>
+</description>
+ </item>
+
+ <item>
+ <title>A manual for standards wars...</title>
+ <link>http://people.skolelinux.org/pere/blog/A_manual_for_standards_wars___.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/A_manual_for_standards_wars___.html</guid>
+ <pubDate>Sun, 6 Jun 2010 14:15:00 +0200</pubDate>
+ <description><p>Via the
+<a href="http://feedproxy.google.com/~r/robweir/antic-atom/~3/QzU4RgoAGMg/weekly-links-10.html">blog
+of Rob Weir</a> I came across the very interesting essay named
+<a href="http://faculty.haas.berkeley.edu/shapiro/wars.pdf">The Art of
+Standards Wars</a> (PDF 25 pages). I recommend it for everyone
+following the standards wars of today.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Sitesummary tip: Listing computer hardware models used at site</title>
+ <link>http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_computer_hardware_models_used_at_site.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_computer_hardware_models_used_at_site.html</guid>
+ <pubDate>Thu, 3 Jun 2010 12:05:00 +0200</pubDate>
+ <description><p>When using sitesummary at a site to track machines, it is possible
+to get a list of the machine types in use thanks to the DMI
+information extracted from each machine. The script to do so is
+included in the sitesummary package, and here is example output from
+the Skolelinux build servers:</p>
+
+<blockquote><pre>
+maintainer:~# /usr/lib/sitesummary/hardware-model-summary
+ vendor count
+ Dell Computer Corporation 1
+ PowerEdge 1750 1
+ IBM 1
+ eserver xSeries 345 -[8670M1X]- 1
+ Intel 2
+ [no-dmi-info] 3
+maintainer:~#
+</pre></blockquote>
+
+<p>The quality of the report depend on the quality of the DMI tables
+provided in each machine. Here there are Intel machines without model
+information listed with Intel as vendor and no model, and virtual Xen
+machines listed as [no-dmi-info]. One can add -l as a command line
+option to list the individual machines.</p>
+
+<p>A larger list is
+<a href="http://narvikskolen.no/sitesummary/">available from the the
+city of Narvik</a>, which uses Skolelinux on all their shools and also
+provide the basic sitesummary report publicly. In their report there
+are ~1400 machines. I know they use both Ubuntu and Skolelinux on
+their machines, and as sitesummary is available in both distributions,
+it is trivial to get all of them to report to the same central
+collector.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Togsatsing på norsk, mot sykkel</title>
+ <link>http://people.skolelinux.org/pere/blog/Togsatsing_p__norsk__mot_sykkel.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Togsatsing_p__norsk__mot_sykkel.html</guid>
+ <pubDate>Wed, 2 Jun 2010 23:45:00 +0200</pubDate>
+ <description><p>Det står dårlig til med toget når en finner på å la det
+<a href="http://www.aftenposten.no/nyheter/iriks/article3677060.ece">kappkjøre
+med sykkel</a>... Jeg tror det trengs strukturendringer for å få
+fikset på togproblemene i Norge.</p>
+
+<p>Mon tro hva toglinje mellom Narvik og Tromsø ville hatt slags
+effekt på området der?</p>
+</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><p>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.</p>
+
+<p>I came across two bugs related to this issue,
+<a href="http://bugs.debian.org/583312">#583312</a> initially filed
+against initscripts and passed on to nvidia-glx when it became obvious
+that the nvidia drivers were involved, and
+<a href="http://bugs.debian.org/524751">#524751</a> initially filed against
+kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.</p>
+
+<p>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.</p>
+
+<p>I wonder why we end up handling bugs this way.</p>
projects / homepage.git / blobdiff