Add bootsystem tag where it belong.

[homepage.git] / blog / index.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:atom="http://www.w3.org/2005/Atom">
        <channel>
                <title>Petter Reinholdtsen</title>
                <description></description>
                <link>http://people.skolelinux.org/pere/blog/</link>
                <atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
        
        <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>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>
&lt;p&gt;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
&lt;a href=&quot;http://www.idg.no/computerworld/article169432.ece&quot;&gt;IT-sjef
Viggo Billdal i Steinkjer intervjuet&lt;/a&gt;, og forteller uten
blygsel:&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;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.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;En &lt;a
href=&quot;https://init.linpro.no/pipermail/skolelinux.no/bruker/2010-June/009101.html&quot;&gt;rask
sjekk&lt;/a&gt; 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
&lt;a href=&quot;http://www.dn.no/multimedia/archive/00090/Dagens_it_nr__18_90826a.pdf&quot;&gt;Dagens
IT nr. 18 2005&lt;/a&gt; hvor en kan lese på side 18:&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;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.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;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:

&lt;blockquote&gt;
&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;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.&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>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>
&lt;p&gt;Via the
&lt;a href=&quot;http://feedproxy.google.com/~r/robweir/antic-atom/~3/QzU4RgoAGMg/weekly-links-10.html&quot;&gt;blog
of Rob Weir&lt;/a&gt; I came across the very interesting essay named
&lt;a href=&quot;http://faculty.haas.berkeley.edu/shapiro/wars.pdf&quot;&gt;The Art of
Standards Wars&lt;/a&gt; (PDF 25 pages).  I recommend it for everyone
following the standards wars of today.&lt;/p&gt;
</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>
&lt;p&gt;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:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
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:~#
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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 mo model, and virtual Xen
machines listed as [no-dmi-info].  One can add -l as a command line
option to list the individual machines.&lt;/p&gt;

&lt;p&gt;A larger list is
&lt;a href=&quot;http://narvikskolen.no/sitesummary/&quot;&gt;available from the the
city of Narvik&lt;/a&gt;, 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.&lt;/p&gt;
</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>
&lt;p&gt;Det står dårlig til med toget når en finner på å la det
&lt;a href=&quot;http://www.aftenposten.no/nyheter/iriks/article3677060.ece&quot;&gt;kappkjøre
med sykkel&lt;/a&gt;...  Jeg tror det trengs strukturendringer for å få
fikset på togproblemene i Norge.&lt;/p&gt;

&lt;p&gt;Mon tro hva toglinje mellom Narvik og Tromsø ville hatt slags
effekt på området der?&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>More flexible firmware handling in debian-installer</title>
                <link>http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html</guid>
                <pubDate>Sat, 22 May 2010 21:30:00 +0200</pubDate>
                <description>
&lt;p&gt;After a long break from debian-installer development, I finally
found time today to return to the project.  Having to spend less time
working dependency based boot in debian, as it is almost complete now,
definitely helped freeing some time.&lt;/p&gt;

&lt;p&gt;A while back, I ran into a problem while working on Debian Edu.  We
include some firmware packages on the Debian Edu CDs, those needed to
get disk and network controllers working.  Without having these
firmware packages available during installation, it is impossible to
install Debian Edu on the given machine, and because our target group
are non-technical people, asking them to provide firmware packages on
an external medium is a support pain.  Initially, I expected it to be
enough to include the firmware packages on the CD to get
debian-installer to find and use them.  This proved to be wrong.
Next, I hoped it was enough to symlink the relevant firmware packages
to some useful location on the CD (tried /cdrom/ and
/cdrom/firmware/).  This also proved to not work, and at this point I
found time to look at the debian-installer code to figure out what was
going to work.&lt;/p&gt;

&lt;p&gt;The firmware loading code is in the hw-detect package, and a closer
look revealed that it would only look for firmware packages outside
the installation media, so the CD was never checked for firmware
packages.  It would only check USB sticks, floppies and other
&quot;external&quot; media devices.  Today I changed it to also look in the
/cdrom/firmware/ directory on the mounted CD or DVD, which should
solve the problem I ran into with Debian edu.  I also changed it to
look in /firmware/, to make sure the installer also find firmware
provided in the initrd when booting the installer via PXE, to allow us
to provide the same feature in the PXE setup included in Debian
Edu.&lt;/p&gt;

&lt;p&gt;To make sure firmware deb packages with a license questions are not
activated without asking if the license is accepted, I extended
hw-detect to look for preinst scripts in the firmware packages, and
run these before activating the firmware during installation.  The
license question is asked using debconf in the preinst, so this should
solve the issue for the firmware packages I have looked at so far.&lt;/p&gt;

&lt;p&gt;If you want to discuss the details of these features, please
contact us on debian-boot@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Magnetstripeinnhold i billetter fra Flytoget og Hurtigruten</title>
                <link>http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html</guid>
                <pubDate>Fri, 21 May 2010 16:00:00 +0200</pubDate>
                <description>
&lt;p&gt;For en stund tilbake kjøpte jeg en magnetkortleser for å kunne
titte på hva som er skrevet inn på magnetstripene til ulike kort.  Har
ikke hatt tid til å analysere mange kort så langt, men tenkte jeg
skulle dele innholdet på to kort med mine lesere.&lt;/p&gt;

&lt;p&gt;For noen dager siden tok jeg flyet til Harstad og Hurtigruten til
Bergen.  Flytoget fra Oslo S til flyplassen ga meg en billett med
magnetstripe.  Påtrykket finner jeg følgende informasjon:&lt;/p&gt;

&lt;pre&gt;
Flytoget Airport Express Train

Fra - Til        : Oslo Sentralstasjon
Kategori         : Voksen
Pris             : Nok 170,00
Herav mva. 8,00% : NOK 12,59
Betaling         : Kontant
Til - Fra        : Oslo Lufthavn
Utstedt:         : 08.05.10
Gyldig Fra-Til   : 08.05.10-07.11.10
Billetttype      : Enkeltbillett

102-1015-100508-48382-01-08
&lt;/pre&gt;

&lt;p&gt;På selve magnetstripen er innholdet
&lt;tt&gt;;E?+900120011=23250996541068112619257138248441708433322932704083389389062603279671261502492655?&lt;/tt&gt;.
Aner ikke hva innholdet representerer, og det er lite overlapp mellom
det jeg ser trykket på billetten og det jeg ser av tegn i
magnetstripen.  Håper det betyr at de bruker kryptografiske metoder
for å gjøre det vanskelig å forfalske billetter.&lt;/p&gt;

&lt;p&gt;Den andre billetten er fra Hurtigruten, der jeg mistenker at
strekkoden på fronten er mer brukt enn magnetstripen (det var i hvert
fall den biten vi stakk inn i dørlåsen).&lt;/p&gt;

&lt;p&gt;Påtrykket forsiden er følgende:&lt;/p&gt;

&lt;pre&gt;
Romnummer 727
Hurtigruten
Midnatsol
Reinholdtsen
Petter
Bookingno: SAX69   0742193
Harstad-Bergen
Dep: 09.05.2010 Arr: 12.05.2010
Lugar fra Risøyhamn
Kost: FRO=4
&lt;/pre&gt;

&lt;p&gt;På selve magnetstripen er innholdet
&lt;tt&gt;;1316010007421930=00000000000000000000?+E?&lt;/tt&gt;.  Heller ikke her
ser jeg mye korrespondanse mellom påtrykk og magnetstripe.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>