Dieser Eintrag ist eine Übersetzung von brain0s Early Userspace in Arch Linux für jene Arch Linux Nutzer, welche mit dem Englischen dann doch ihre Probleme haben, keine Gewähr auf Fehlerfreiheit. Dieser Eintrag unterliegt nicht der im Impressum angegebenen Lizenz, die Rechte liegen bei Thomas Bächler, die Übersetzung ist mit seinem Einverständnis erfolgt.

In letzter Zeit gab es einige große Änderungen bei Archs Programmen des fühen Userspace. Also dachte ich mir, dass ich mir die Zeit nehme und allen diese Änderungen erläutere.

Bootvorgang von Linuxsystemen: Wofür braucht man einen frühen Userspace?

Früher war das starten eines Linux Systems einfach: Der bootloader lud den Kernel, dieser wurde extrahiert und initialisierte die Hardware, danach initialisierte er den Festplatten-Controller, erkannte die Festplatte und das sich darauf befindliche Root-Dateisystem, band dieses ein uns startete /sbin/init.

Heutzutage gibt es eine gigantische Menge an unterschiedlichen Controllern und eine große Anzahl unterschiedlicher Dateisysteme, da wir eine ordentliche Distribution sind möchten wir alle unterstützen. Also bauen wir sie alle in unser monolithisches Kernelimage welches nun mehrere Megabyte groß ist alles bis zur Küchenspüle unterstützt, aber dann kommt jemand und hat zwei SATA-Controller, drei IDE-Controller, sieben Festplatten sowie drei externe USB-Laufwerke und wer weiß was. Der Kernel erkennt diese nun alle asynchron, aber wo ist nun bitte das Root-Dateisystem? Ist es auf der ersten Festplatte? Oder auf der dritten? Was ist "die erste Festplatte" überhaupt? Und wie binde ich mein Root-Dateisystem in der LVM Laufwerksgruppe im verschlüsselten Container auf dem Software RAID-Array ein? Wie man sieht wird das alles etwas hässlich und der Kernel stellt sich gerne dumm oder kümmert sich einfach nicht um diese nervtötenden Probleme, besonders nachdem er durch uns - die wir ihn mit jeden erdenklichen Treiber gefüttert haben - so fett wurde.

Was nun? Ganz einfach, wir übergeben die Kontrolle dem Userspace und regeln die Erkennung der Hardware dort, richten den ganzen komplizierten und von den Leuten gewünschten Kram ein, binden das Root-Dateisystem ein und starten /sbin/init selbst. Nun frägst du dich sicherlich "Wie führe ich Applikationen im Userspace aus, wenn das Root-Dateisystem nicht eingebunden ist?" die Antwort darauf lautet "Magie!".

Was ist initramfs?

Naja die Antwort ist nicht Magie. Die Antwort lautet eigentlich initramfs: Jedes Linux System hat ein ramfs Dateisystem, welches immer eingebunden ist und rootfs heißt. Wahrscheinlich wirst du dieses nie sehen, da deine wirklichen Dateisysteme es nach dem Einbinden überdecken. Allerdings führt der Kernel auch ein komprimiertes cpio Archiv mit sich, welches direkt nach dem Start in das rootfs extrahiert wird. Noch besser: Es ist sogar möglich aus dem Bootloader heraus ein solches Archiv an den Kernel anzuhängen, welches dann ebenfalls in das rootfs entpackt wird.

Bevor der Kernel den altmodischen init Code ausführt, prüft er, ob das rootfs eine Datei namens /init enthält, ist dies der Fall überspringt er den klassischen Einbindungs- und Initcode und führt stattdessen /init aus. Nun liegt die Verantwortung für diese Aufgabe, welche für den Kernel als zu kompliziert eingeschätzt wird, bei diesem Programm. Auf diese Weise können wir einen Kernel, welcher keinerlei eingebaute Unterstützung für einen Festplatten-Controller auch nur für irgendein Dateisystem bietet(das ist eigentlich, was wir mit dem Arch Linux Standardkernel machen) bauen und fügen die benötigten Module schlichtweg in das initramfs Image ein.

klibc - Das Fegefeuer für die Initramfs Maintainer

klibc wurde ursprünglich als kleine leichtgewichtige C Bibliothek für den frühen Userspace entwickelt. Sie bringt einige Programme mit, welche einem dabei helfen alles Einzurichten. Mit klcc führt sie sogar ein hässliches Perlskript mit, welches den gcc aufruft und Binärdateien gegen die klibc anstatt die übliche libc linkt. Als Aaron Griffin 2006 mkinitcpio als Ersatz für die alten, unflexiblen Skripte mkinitrd und mkinitramfs entwickelte, wurde entschieden es auf klibc basieren zu lassen. Von Anfang an hatte klibc Probleme:

• Das Set an mitgelieferten Programmen war begrenzt und den Programmen fehlten wichtige Optionen.
• Die meisten externen Programme liesen sich nicht gegen die klibc linken oder mussten dafür stark gepatcht werden.
• Es gab keinen dynamischen Linker, alle Binärdateien wurden statisch gegen eine spezifische Version der klibc gelinkt, diese Version änderte sich mit jeder Änderung an den klibc Quellen oder der Kernelheader, was dann wieder den Neubau aller - gegen die klibc gelinkten - Binärdateien nötig machte.
• Es war nicht möglich andere dynamische Bibliotheken, als die klibc selbst zu erstellen.

All das resultiere in großem Arbeitsaufwand für die Instandhaltung von udev und den module-init-tools, wir mussten auch ein kleines klibc-extra Paket verwalten, welches die fehlenden klibc Programme mit unseren eigenen ersetzte. Fortgeschrittenere Programme wie lvm oder cryptsetup mussten wir statisch gegen die glibc linken und so bereitstellen.

Irgendwann war klibc inkompatibel zu den Kernelheadern und wir mussten mehr und mehr Hacks einführen um es aktualisieren zu können. Seit Linux 2.6.30 war ich nicht in der Lage überhaupt eine funktionierende Version der klibc zu bauen, was uns mit einer alten Binärdatei zurückließ, bei welcher wir nicht einmal mehr Bugs fixen konnten. Mitte 2009 starb dann upstream vollkommen, keine commits ins git Repository und acuh auf der Mailingliste gab es nur eine Hand voll Mails pro Monat. Das brachte mich dazu, mir folgende Frage zu stellen: "Worin besteht der Sinn eine seperate C Bibliothek zusammen mit Programmen zu verwalten, welche nur für den Bruchteil einer Sekunde beim Start des Systems Verwendung finden?" Außer einem kleineren initramfs Image und dadurch verkürzte Bootzeit vermutlich nichts.

Es einfach halten

2009 entschied ich dann, dass um eine initramfs Umgebung mit geringem Verwaltungsaufwand, vielen Funktionen und großer Flexibilität, die folgenenden Änderungen nötig waren:

• Verwendung der C Bibliothek des Systems und keiner seperaten.
• Die Verwendung von busybox für grundlegende System- und Skriptingprogramme, um einen guten Kompromiss ziwschen hoher Funktionalität und kleiner Dateigröße zu finden.
• Die Verwendung von util-linux-ngs blkid, um Label von Dateisystemen, UUID und Typerkennung vollständig für alle neuen und alten Dateisysteme zu haben.
• Die Verwendung von modprobe, udev, lvm, cryptsetup, mdadm/mdassemble aus den normalen Arch Paketen für weitere fortgeschrittene Funktionen.

Auf diese Weise müsste ich neben mkinitcpio selbst nur noch eine ordentlich konfigurierte busybox Binärdatei verwalten. Ich setzte busybox seit geraumer Zeit auf meinen OpenWRT Routern und wusste daher wie beeindruckend es war. Es stellte sich außerdem heraus, dass die Implementierung von NFS Root-Unterstützung einfacher war, wenn wir die mit der klibc gelieferten Programme nfsmount und ipconfig nutzten.

Nun ist es Februar 2010 und in den letzten Wochen hatte ich endlich die Zeit, die ganze Arbeit zu erledigen. Erst vor wenigen Tagen veröffentlichte ich mkinitcpio 0.6, diese Version ist deutlich stabiler, flexibler und weniger fehleranfällig als jede klibc-basierte Version die wir je hatten. Das initramfs ist nun um Durchschnitt 600KB bis 1MB größer, ich glaube nicht, dass sich deswegen jemand beschwert, es ist immer noch kleiner als bei den meisten anderen Distributionen. Ich bin froh, dass ich hoffentlich nie wieder mit klibc zu tun haben werde.

Ich halte die eigentliche Idee hinter "Stöckchen" eigentlich nicht für schlecht, wenn es um sinnvolle Themen geht, den den Kabarakh mir da aber "zugeworfen" hat mag ich dennoch nicht sonderlich, aber man will ja kein Spielverderber sein.

Warum bloggst du?
Um Dinge, welche für mehrere Bereiche des Netzes in denen ich aktiv bin, nochmal gesondert Platz einzuräumen, dass spiegelt sich zwar nicht in jedem Eintrag(beispielsweise diesem hier) wider, ist aber dennoch die eigentliche Intention.

Seit wann bloggst du?
Ohm da waren vor Jahren schonmal gemeinsame Blogs mit hanshiro bei Bloghostern, da bin ich zu faul nach zu schauen, dieser hier wird seit dem Frühjahr 2008 von mir geführt.

Warum lesen deine Leser deinen Blog?
Langeweile? Noch nicht gelangweilt genug um einzuschlafen? Ich weiß es nicht.

Welche war die letzte Suchanfrage, über die jemand auf deine Seite kam?
urxvt borderless - interessant, da weiß wohl jemand nicht, wie er eher an eine brauchbare Antwort käme, mein Artikel für Fluxbox wird ihm bei einem anderen Window Manager nur bedingt geholfen haben.

Welcher deiner Blogeinträge bekam zu Unrecht zu wenig Aufmerksamkeit?
Dazu kann ich recht wenig sagen, ich denke die meisten Leser meiner Texte bekommen sie über den Feed eines Planets förmlich aufgezwungen. ;-)

Dein aktuelles Lieblingsblog?
Puh, ich mag eigentlich alle in meinem Feedreader, aber etwas Werbung für den Schweizer Hackerfunk ist dennoch angebracht.

Welches Blog hast du zuletzt gelesen?
So richtig gelesen? Dustys über die git tab-completition in der bash, danach habe ich Kabarakhs Fragen kopiert.

Wieviele Feeds hast du gerade im Moment abonniert?
85 - newsbeuter ist klasse.

An welche fünf Blogs wirfst du das Stöckchen weiter und warum?
Da ich - wie gesagt - an diesem hier keinen wirklichen Gefallen finde, an niemanden, ich lege es quasi vor die Tür, so dass jeder der es möchte aufheben kann.

2009 geht zu Ende, Zeit mal die gröbsten Eckpunkte aus diesem Jahr hier zusammenzufassen.

• Im Frühjahr die x-te Feststellung, dass es in Heidelberg einen Chaostreff gibt, diesmal jedoch auch mit anschließendem Besuch und Beitritt in den NoName e.V.
• Abschluss der Schullaufbahn.
• BadBoy_ kam im Sommer zu Besuch.
• Der Besuch der FrOSCon in St.Augustin.
• Beginn des Informatikstudiums in Mannheim.
• Die Ernennung zum Trusted User bei Arch Linux.

Dann will ich euch mal nicht weiter langweilen, sondern wünsche euch eine angenehme Feier ins neue Jahr, hoffen wir mal, dass dies auch für js der Fall sein wird.

As ArchLinux user one has to build his packages in chroots in order to make sure, that everything is fine with them and the package will build on other people's machines. ArchLinux provides several scripts which makes this easier with the devtools package. How they are used is described in the DeveloperWiki. So as you can see this is really simple but if you have a real build machine and want to build your packages with different chroots it helps a lot to have a function in your shell configuration, note that I use a x86_64 system, so the last two functions need small modifications to run on an i686 installation.

alias mktesting="mkchr testing64 && mkchr testing32"
alias mkstable="mkchr stable64 && mkchr stable32"

# Update the given chroot/all
function upchr() {
        if [ $1 = "all" ]; then
                print 'e[1;32mUpdating the e[1;31mstable32e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/stable32/root/
                print 'e[1;32mUpdating the e[1;31mtesting32e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/testing32/root/
                print 'e[1;32mUpdating the e[1;31mstable64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/stable64/root/
                print 'e[1;32mUpdating the e[1;31mtesting64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/testing64/root/ 
        elif [ ! $1 = "" ]; then
                print 'e[1;32mUpdating the e[1;31m'$1'e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/$1/root/
        fi
}

# Build the package with the given chroot
function mkchr() {
        if [ ! $1 = "" ]; then
                print 'e[1;32mBuilding package using the e[1;31m'$1'e[1;32m chroot.e[0m'
                sudo makechrootpkg -c -r /var/chroots/$1/
        fi
}

# Create a set of stable chroots for both architectures
function create_stable_chroots () {
                sudo mkdir -p $1/stable64 $1/stable32
                # 64 Bit Chroot
                sudo mkarchchroot $1/stable64/root base base-devel sudo
                sudo $EDITOR $1/stable64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sudo sed -e 's/x86_64/i686/g' $1/stable64/root/etc/pacman.d/mirrorlist > /tmp/mirrorlist
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' $1/stable64/root/etc/pacman.conf > /tmp/pacman.conf
                sudo mkarchchroot $1/stable32/root base base-devel sudo
                echo "Created stable32 and stable64 under ."
}

# Create a set of testing chroots for both architectures
function create_testing_chroots () {
                sudo mkdir -p $1/testing64 $1/testing32
                # 64 Bit Chroot
                sudo mkarchchroot $1/testing64/root base base-devel sudo
                sudo $EDITOR $1/testing64/root/etc/pacman.conf
                sudo $EDITOR $1/testing64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sudo sed -e 's/x86_64/i686/g' $1/testing64/root/etc/pacman.d/mirrorlist > /tmp/mirrorlist
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' $1/testing64/root/etc/pacman.conf > /tmp/pacman.conf
                sudo mkarchchroot $1/testing32/root base base-devel sudo
                sudo $EDITOR $1/testing32/root/etc/pacman.conf
                sudo $EDITOR $1/testing32/root/etc/pacman.d/mirrorlist
                echo "Created testing32 and testing64 under ."
}
 

If your shell is not bash compatible, the functions may need small modifications.

Am gestrigen Abend hat Andreas Krennmair den Terminal Feedreader newsbeuter in der Version 2.1 freigegeben. Zu den Neuerungen zählen unter anderem:

• Support von 256 Farben unterstützenden Terminals
• Support von SOCKS Proxies.
• notify-beep Option(Sehr nützlich in Kombination mit dem Urgency Hint - siehe vorheriger Artikel)
• Automatische Selektierung des ersten ungelesenen Artikels in einem Feed.
• Verbessertes HTML Rendering.
• Artikel können nun auch aus der Artikelansicht heraus gelöscht werden.

Außerdem wurden natürlich auch einige Bugs gefixt, für eine vollständige Liste der Änderungen lohnt sich ein Blick in das CHANGELOG.

Links:
Projektseite
Dev-Blog
Changelog

As it took me some time yesterday evening, configuring those three to set an urgency hint for the terminal, so that my i3 highlights the workspace the urxvt containing the irssi-screen-session sECuRE told me I shall write a short post in order to help other finding the small glitches in their configuration which might cause problems.

screen: ~/.screenrc
Just turn the visualbell off:

vbell off

urxvt: ~/.Xdefaults
For urxvt you only have to activate the urgentOnBell option:

URxvt*urgentOnBell: true

If you use another terminal, you only have to search the documentation for "urgen" in order to find the option.

irssi: ~/.irssi/config
If you want to do configuration directly using the file, add these lines to the settings part:

settings = {
#...
  "fe-common/core" = {
    bell_beeps = "yes";
    beep_when_away = "yes";
    beep_when_window_active = "yes";
    beep_msg_level = "HILIGHT INVITES MSGS NOTICES CTCPS DCC DCCMSGS"
  }
}

Or using a running instance:

/set bell_beeps on
/set beep_when_away on
/set beep_when_window_active on
/set beep_msg_level HILIGHT INVITES MSGS NOTICES CTCPS DCC DCCMSGS
/save

Damit Andere nicht denselben Ärger, den ich in den letzten Stunden hatte, haben, schreibe ich euch hier schnell einen kurzen Post, was ihr machen solltet:

Macht euch mit dem LiveUpdate und Online LiveUpdate keine Hoffnungen, hat sich auf einem extra dafür aufgesetztem Windows XP mit Service Pack 2, auf welchem außer den Treibern für die Hardware nichts installiert war als unbrauchbar erwiesen(etliche Fehlfunktionen). Nehmt stattdessen lieber 3 Disketten(3.5" 1.44MB) und ein entsprechendes Diskettenlaufwerk zur Hand, formatiert diese mit FAT und ladet euch von der Seite eures Mainboards das aktuelle BIOS, besorgt euch eine Windows ME oder Windows 98 Startdiskette(RAMDISK! Den Hinweis im beiliegenden Word Dokument bemerkt man erst nach mehrmaligem durchlesen, leider wird er nicht hervorgehoben, eine Homepage, von welcher man ein entsprechendes Image beziehen kann, ist dort immerhin angegeben). Kopiert die Dateien aus dem BIOS Archiv auf eine der von euch formatierten Disketten, bootet im Anschluss das System von der Startdiskette, wählt im Menü den Punkt mit Unterstützung für CD Laufwerke kopiert die Dateien in die RAMDISK(siehe Dokument), tauscht im Anschluss die Diskette mit der verbleibenden leeren aus und beendet die Schritte wie sie in der Anleitung beschrieben werden, sichert das Backup aber auf jeden Fall auf der leeren Diskette.

Wer sich jetzt frägt, was er von diesem Post hat, das stünde ja alles in der Anleitung, dem kann ich nur die Gegenfrage stellen, ob er denn noch ein Diskettenlaufwerk in seinem System hat. Beim Großteil der in den letzten Jahren geschaffenen Desktopgeräte ist dies nicht der Fall und auch ich hatte, bei diesem System, vom Einbau eines solchen abgesehen. Da erscheint einem die temporäre Installation eines Windowssystems doch wesentlich weniger Arbeit zu sein, als das durchtesten des Floppylaufwerkstapels und der im Regal einstaubenden Disketten ... und wer nun sagen möchte, so faul sei er nicht soll sich zum Teufel scheren .