After one week of holiday already passed by I finally write a post again. I used the last days to go through a lot of texts I missed in the last weeks as I was preparing for the exams of the semester. Now that I read everything interesting/important I finally started to improve the arch_chroot_packaging.sh yesterday.

So for now I'm finished with that and will use the cool parts of the day to learn for the study, while the rest of each is used for the stuff that comes up. However I'll be at the Arch booth at this year's FrOSCon 2010 I hope some of you will come there and visit us.

Yesterday evening td123 and wonder were so nice to update the shell functions I wrote in order to make work with different packaging-chroots even more comfortable.

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

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

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

# Create a set of stable chroots for both architectures
function create_stable_chroots () {
                sudo mkdir -p /var/chroots/stable64 /var/chroots/stable32
                # 64 Bit Chroot
                sudo mkarchroot /var/chroots/stable64/root base base-devel sudo
                sudo $EDITOR /var/chroots/stable64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' /var/chroots/stable64/root/etc/pacman.conf > /tmp/pacman.conf
                linux32 sudo mkarchroot /var/chroots/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 /var/chroots/testing64 /var/chroots/testing32
                # 64 Bit Chroot
                sudo mkarchroot /var/chroots/testing64/root base base-devel sudo
                sudo $EDITOR /var/chroots/testing64/root/etc/pacman.conf
                sudo $EDITOR /var/chroots/testing64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' /var/chroots/testing64/root/etc/pacman.conf > /tmp/pacman.conf
                linux32 sudo mkarchroot /var/chroots/testing32/root base base-devel sudo
                sudo $EDITOR /var/chroots/testing32/root/etc/pacman.conf
                sudo $EDITOR /var/chroots/testing32/root/etc/pacman.d/mirrorlist
                echo "Created testing32 and testing64 under ."
}
 

Edit 20100706: Thanks to mac_mario for notification about a typo in the text.

Es gibt Tage, da weiß man nicht so genau was man da eigentlich macht, bei mir war der gestrige ein solcher Tag. Eigentlich wollte ich abends nur einen kurzen Eintrag über den vorgestern auf meinem Laptop eingerichteten Mirror des Arch Linux core Repositories schreiben, dann stellte ich fest, dass mir hier am Laptop ein dafür geeigneter Editor fehlte und mir kam die Idee doch einfach mal selbst einen zu schreiben, schließlich war das Thema der OOT Vorlesungen in den vergangenen 14 Tagen das Java Toolkit Swing.

Also Eclipse gestartet und während im Fernseher zuerst Matilda und im Anschluss der restliche Eurovision Song Contest lief, ging ich hier nochmals durch die Folien und schrieb einen Editor, welcher zumindest halbwegs meinen Vorstellungen entspricht. Dabei tauchten im Laufe des Abends einige unerwartete Probleme mit dem Umgang mit Swing auf, insofern war dieser plötzliche Entschluss doch sehr gut zum lernen des Stoffes dieses Prüfungsfachs. Dank dem Master Studenten Wiesel wurde mir dann auch der - auf den Vorlesungsfolien nicht korrekt beschriebene - Umgang mit der Swing Klasse JFileChooser (Anzeige der Öffnen/Speicher Dialoge) klar, vielen Dank nochmal an dieser Stelle.

Wer sich den Editor anschauen möchte, kann dies in meinem github Repository BlogUtils erledigen, momentan ist er noch nichts anderes als ein grundlegendes Gerippe, ich werde ihn zur Übung wohl noch um einige nützliche Funktionen erweitern, wer Vorschläge hat, kann mir diese gerne unterbreiten.

Nachtrag: Da nicht auf jeder Maschine ein JDK installiert ist, habe ich schnell ein jar exportiert: Download zu starten mittels:

java -jar blogposteditor20100530.jar

Wie man sieht, ist es hier im Blog recht ruhig geworden, das liegt vor allem daran, dass ich mich hauptsächlich auf mein Studium konzentriere und meine digitale Kommunikation zum größten Teil mittels Mailing Listen und kurzen Unterhaltungen via IRC/XMPP erledige. Dennoch ist es an der Zeit, auch hier ein Lebenszeichen von mir zu geben und auf Tätigkeiten meinerseits zu verweisen, welche nicht bloß für mich von Interesse sind.

Da wäre zum einen mein Artikel über die absoluten Grundlagen im Umgang mit dem Portscanner NMap in der diesjährigen Mai Ausgabe von freiesMagazin, durch welchen ich dank Hilfe der Redaktion auch einige Kniffe hinsichtlich verständlicher Formulierungen erlernt habe.

Zum anderen wäre da noch der Vortrag über Arch Linux, welchen ich im Rahmen des Faches Proseminar vor einem Teil meines Semesters geben musste durfte. Der Vortrag richtet sich vom Schwierigkeitsgrad her an ein Publikum, welches keine oder nur sehr geringe Kenntnisse über Linux Distributionen besitzt, dementsprechend einfach sind Handout und Folien formuliert. Beides findet man - zusammen mit den LaTeX Quellen - in meinem talks Repository bei github.

sECuRE veröffentlichte gestern i3 v3.ε. Neuerungen sind unter anderem:

• Umstieg von Xinerama auf RandR, Nutzer des Nvidia Treibers sollten sich unbedingt diese beiden Artikel anschauen: Multi-Monitor und Multi Monitor im Userguide.
• Der neue Konfigurationsparser ist nun Standard, ggf. sind also kleine Änderungen an der Konfiguration nötig.
• Der Funktionsumfang mittels IPC wurde vergrößert.
• Die Workspace Leiste lässt sich abschalten und durch eine andere ersetzen.

Mit diesem Release habe ich gestern auch das i3 Paket aus dem AUR in das ArchLinux community Repository verschoben, bei 56 Votes wird das sicherlich den ein oder anderen Archer freuen.

Links:
Projektseite
git Repository
i3-git im AUR
i3lock im AUR
i3status im AUR

Heute mittag wurde newsbeuter 2.2 von Andreas Krennmair freigegeben. Hinzugekommen sind unter Anderem:

• Unterstützung für den Google Reader
• Das markieren von Artikeln in der Artikelliste, abhängig vom Artikelinhalt.
• Erweiterung der "ignore article" Funktion mit verschiedenen Modi.
• "hard quit" zum direkten beenden des Readers.
• Der HTML-Renderer rendert nun auch Tabellen.

Links:
Projektseite
Dev-Blog
Changelog

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.