22.03.2018

Nerviges beim Autofahren - 2

Schön, dass Sie trotz Teil 1 wieder eingeschaltet haben zum nächsten Teil meines Gemeckers über Autofahren und Autofahrer und alles rundherum!

Ich hatte im letzten Teil schon angefangen, mich über Baustellen und das Verhalten von Fahrern in Baustellen auszulassen.

Einen Nachtrag zum Thema "Mittelspurfahrer" möchte ich noch nachliefern: der Postillon hat vor einiger Zeit über eine Sensation auf deutschen Autobahnen berichtet.

Auch sehr nett sind die Autofahrer, die in Baustellen links fahren, aber dann kein Gefühl dafür haben, wie breit ihr Auto tatsächlich ist, und sich dann nicht trauen, an breiten LKWs vorbeifahren. Dann bleiben sie schräg links hinter dem LKW, aber sie kommen auch nicht auf die Idee, dass sie wieder auf die rechte Spur wechseln, und blockieren dann erst mal alles.

Autofahrer, die nicht blinken können oder wollen, sind auch so eine Sache. Meistens geht das auch einher damit, nicht einschätzen zu können, wie schnell jemand von hinten angefahren kommt.

Nicht zu Unrecht lernt man in der Fahrschule, mindestens zweimal in den Spiegel zu schauen, um zu sehen, wie schnell jemand näher kommt, wie groß also der Geschwindigkeitsunterschied ist. Es gibt aber Fahrer, die das nicht nötig haben und dann einfach darauf vertrauen, dass der Hintermann gute Bremsen hat. Leider verursachen genau diese heftigen Bremsmanöver i.a. auch noch Folgebremsungen der weiteren Fahrzeuge dahinter, und das pflanzt sich dann vielleicht noch Kilometer nach hinten fort. Im schlimmsten Fall geschieht durch den unüberlegten und rücksichtslosen Spurwechsel sogar noch ein Unfall.

Wie gut, dass der Postillon erst kürzlich vermelden konnte, dass ab 2018 auch ein Blinker für das Geradeausfahren Pflicht wird!

Vielleicht wollen die Fahrer, die nicht blinken, den anderen Verkehrsteilnehmern aber auch einfach nicht die Überraschung verderben?

Marode Brücken sind auch so eine Sache für sich: durch die Vibrationen gehen Brücken schneller kaputt, als bei der Konstruktion vorausgesehen, weil insbesondere der LKW-Verkehr unglaublich zugenommen hat. An vielen Brücken gibt es Tempolimits wegen "Brückenschäden", üblicherweise 60 für LKWs und 80 für PKW. Ich denke mir dann, dass jeder, der das Tempolimit ignoriert, dazu beiträgt, dass die Brücke schneller kaputtgeht und saniert werden muss. Und natürlich passiert das von den Steuergeldern - meinen und seinen. Leider ist der Zusammenhang zwischen Steueraufwand und Tempolimit den meisten Autofahrern nicht allzu naheliegend.

Achja, nochmal Baustellen: die meisten dicken Automodelle, insbesondere die Disco- und Kindergartenpanzer, neudeutsch "SUV" genannt, sind mittlerweile inklusive Außenspiegeln deutlich breiter als zwei Meter, und das bedeutet in den üblichen Baustellen, dass sie rechts bleiben müssen. Im Fahrzeugschein steht die Breite ohne Spiegel, aber wenn auf einem Verbotsschild ein Limit von zwei Meter angezeigt wird, gilt das für die reale Breite inklusive beider Außenspiegel. Öffnen Sie einfach mal spaßeshalber die Scheiben in den vorderen Türen und messen Sie, wie breit Ihr Auto ist! Sie werden überrascht sein.

Tempolimits innerorts sind mir auch besonders wichtig und ich halte mich auch daran. In unserer Gemeinde ist vor einiger Zeit überall Tempo 30 eingeführt worden, außer auf der Bundesstraße und höchstens noch einer Durchgangsstraße durch jeden Ortsteil. Damit verbunden ist generell "rechts vor links". Leider hält sich kaum jemand daran - weder an das Eine noch an das Andere. Dabei ist es gerade innerorts wichtig, auf kleine und große Fußgänger Rücksicht zu nehmen. Besonders toll, wenn einem der Schulbus die Vorfahrt nimmt.

Ebenfalls gar nicht leiden kann ich es, wenn jemand mir zu dicht auffährt. Wenn ich mit der Familienkutsche unterwegs bin und habe jemanden hinter mir, dessen Front ich schon gar mehr nicht richtig im Spiegel sehen kann, weil er so nah ist, wünsche ich mir eine automatisch ausfahrbare Rampe statt der Heckklappe, um das Auto hinter mir als Beiboot an Bord zu nehmen (wie bei James Bond ;) ). Dieses Verhalten ist extrem dumm - wenn ich rechts fahren könnte, würde ich das tun. Meistens überhole ich aber gerade selbst, oder es ist eine ganze Schlange vor mir. In jedem Fall führt Drängeln aber zu erhöhtem Streß beim Gedrängelten und in letzter Konsequenz erhöht es das Risiko von Fahrfehlern und Unfällen (wie vor ein paar Jahren bei dem Unfall mit einem Mercedes-Testfahrer und einem Kleinwagen mit Mutter und Kind).

Eine besonders krasse Form von "dicht Auffahren" passiert anscheinend auch nur mir: ich bin vermutlich der einzige Idiot, der regelkonform am STOP-Schild wirklich anhält. Bei meinem vorherigen Astra ist mir an derselben Autobahnausfahrt zweimal (!) dieselbe Art von Unfall passiert: ich fahre bis zur Linie und halte an. Und dann bummst es. Weil der Autofahrer hinter mir (bzw. Kleinlaster, ist aber eigentlich egal) nicht erwartet hatte, dass ich tatsächlich anhalte. Das sind die Oberschlauen, die als zweiter in der Schlange sehen, dass von Links keiner kommt und dann einfach durchfahren wollen.

Dieselbe Art von Unfall ist mir dann mit dem kleinen Spaßauto nochmals passiert, allerdings an einem STOP-Schild an einer Einmündung zur Landstraße. Der Autofahrer hinter mir schaut nach links und bildet sich ein, er kann fahren, achtet aber nicht darauf, ob vor ihm das Auto noch da ist. Dieser Autofahrer war dann besonders penetrant: er beschimpfte mich auch noch, warum ich angehalten hätte. Der Gipfel der Selbstgerechtigkeit war, dass er von meinem kaputten Auto ausgiebig Fotos machen wollte, damit ich auf keinen Fall auf seine Kosten von der Versicherung Reparaturen bezahlen lasse, für die er nicht verantwortlich sei. Dabei hatte es gar keine sonstigen Schäden. Ich liebe das kleine Spaßauto, das ist technisch immer in Ordnung, nur manchmal ein bißchen staubig.

15.03.2018

Ich bau mir ein Linux wie es mir gefällt - 1

Seit langen Jahren bin ich begeisterter Nutzer einer ganz speziellen Linux-Variante namens "Linux from scratch".

Wie der Name sagt, wird dabei ein Linux-System von Grund auf ("from scratch") komplett neu gebaut. Dazu werden die Quelltexte verwendet, um selbst alle Pakete zu übersetzen und einen PC (oder ein anderes Rechnersystem) mit einem von Festplatte startfähigen Linux auszustatten.

Dabei hat man natürlich ein Henne-Ei-Problem: man braucht ein Linux, um das neue Linux zusammen zu bauen. Für dieses Problem gibt es mehrere Lösungsmöglichkeiten: zum Einen kann man das LFS in einer virtuellen Maschine zusammenbauen. Alternativ kann man auf dem Zielrechner zunächst eine kleine Partition mit einem anderen Linux einrichten, von dort starten und dann das LFS auf den freien Platz der Festplatte werfen. Das Linux zum Bauen kann man dann hinterher als Notfallsystem behalten, oder aus der Partition dann die Swappartition machen oder sie anderweitig verwenden. Für das allererste ("bootstrap") Linux reicht eine Minipartition von 8-16 GB, und dort kann man dann z.B. ein Linux Mint oder Fedora installieren.

"Linux from Scratch" ist nicht nur eine Anleitung für ein Linux zum Selbstbasteln, sondern ist hauptsächlich dazu gedacht, Erfahrung beim Bauen von Linuxprogrammen aus den Quelltexten zu sammeln.

Man lernt dabei eine ganze Menge, nämlich vor allem Zusammenhänge zwischen den verschiedenen Programmen, Konfigurationsdateien, aber auch viel über Netzwerke, und vor allem natürlich über die technischen Voraussetzungen, darunter die Verwendung von Makefiles, und man lernt, Logfiles zu lesen, um die Probleme zu beseitigen.

Bei "LFS" gibt es verschiedene Steigerungsmöglichkeiten, wie man sich selbst das Leben schwer und spannend machen kann. Man kann das Basissystem bauen, dann hat man "nur" eine Linux-Kommandozeile.

Darauf aufbauend ist es mit dem Fortsetzungsbuch "Beyond Linux from scratch" (BLFS) möglich, einen Server zu bauen, mit dem man z.B. eine Firewall, ein NAS, einen Webserver, oder noch viel mehr zusammen bauen kann. Oder man baut sich ein Desktopsystem mit einer grafischen Oberfläche, und am Ende steht dann der selbst kompilierte Firefox. Hört sich das nicht cool an?

Eine Schwierigkeitsstufe darüber steht die Automation des Bau-Vorgangs - und hauptsächlich darüber will ich hier schreiben. Die Anleitung von "LFS" für ein Basissystem und für das "BLFS" sind ziemlich gut. Wenn man sich daran hält, hat man gute Chancen, manuell Schritt für Schritt ein lauffähiges System zu erstellen. Man geht am Browser durch alle Kapitel der Reihe nach durch und führt gemäß Anleitung die einzelnen Schritte durch. Das ist beim ersten Mal ehrlich gesagt mühsam - ich spreche aus Erfahrung ;-). Andererseits ist es spannend zu erleben, wie das Linuxsystem mit jedem Schritt wächst und tatsächlich immer mehr dem ähnelt, was man als Linuxbenutzer kennt.

Die Automation "Automated Linux from scratch" (ALFS) hingegen ist in einer README-Datei nur spärlich beschrieben. Dafür hat man, wenn man das System einmal verinnerlicht hat, eine wunderbare und sehr esoterische Möglichkeit, Updates zu installieren oder das gesamte System auf Knopfdruck noch einmal komplett neu zu erzeugen.

Auf diese Weise habe ich über Nacht ein Linux gebaut - besser gesagt: bauen lassen, das mit dem neuesten Kernel 4.15 und C-Compiler gcc 7.3 gegen Spectre und Meltdown gefeit wäre. - Wenn, ja wenn mein Bastelsystem ein 64-bit-System gewesen wäre (x86_64) und nicht 32 Bit (i686). Und wenn ich das Gefühl hätte, dass ich wirklich von diesen Sicherheitslücken bedroht bin. Aber zum Thema Risikoanalyse muss ich noch mal einen eigenen Artikel schreiben, denke ich.

Und noch eine Stufe darüber verwendet man nicht die "stable" Variante der Bücher, sondern die LFS- und BLFS-Bücher, die gerade in der Entwicklung sind. Die Autoren der Kapitel sind permanent damit beschäftigt, neue Versionen der Pakete zu integrieren und die Artikel anzupassen. Wenn sich z.B. bei einem Paket das Verfahren ändert, wie man das Paket lauffähig kompiliert, wird das enorm schnell in die "development"-Variante von LFS bzw. BLFS übernommen. Genau das ist mir während des Schreibens dieses Artikels passiert: ich habe das Makefile angestoßen, und mittendrin wurde im Buch auf ncurses 6.1 umgestellt. Kaum war ich fertig, veröffentlichen die Entwickler die neue glibc-Version 2.27. So kann's gehen ...

Um noch mal auf "Meltdown" und "Spectre" zurück zu kommen: das LFS-Buch enthält seit kurzem brandneue Kernel- und gcc-Versionen, die diese Sicherheitslücken beheben sollen. Das ist natürlich immer "work in progress". Der aktuelle Stand ist, dass Spectre V2 und Meltdown repariert sind, und für Spectre V1 ist noch einiges an Entwicklerarbeit zu leisten. Die alten 32-bit-Prozessoren hinken hier leider hinterher, für 64 bit (also alles, was grob jünger als 10 Jahre ist) sollten alle Fixes auf jeden Fall in Arbeit sein.

So, jetzt aber wie versprochen eine genauere Beschreibung der Automation für LFS (ALFS). Dazu lädt man sich zunächst das aktuelle Paket herunter. Der Paketname lautet aus historischen Gründen "jhalfs" und ehrt damit den ersten Entwickler des Verfahrens mit seinen Initialen "jh".

Damit jhalfs funktioniert, benötigt es ein paar zusätzliche Linux-Pakete auf dem Gastsystem, die man nachinstallieren muss, weil sie normalerweise nicht für Endbenutzer erforderlich sind. Dazu gehören natürlich der C-Compiler gcc und einige Hilfsprogramme und Bibliotheken wie bison, awk, ncurses etc. Das Schöne ist: wenn man jhalfs startet, kontrolliert es, was noch fehlt und beschwert sich. Für die Verwendung der "development"-Fassung muss man außerdem noch Subversion installieren, um die tagesaktuellen Dateien aus dem Versionskontrollsystem herunter zu laden.

Die Automation setzt tatsächlich schon bei den allerersten Schritten ein, die man gemäß LFS-Buch durchführen würde: dem Erzeugen eines neuen Unixbenutzers "lfs" für das Kompilieren der Pakete, dem Anlegen von Verzeichnissen usw. Der einzige Schritt, den man selbst durchführen muss, ist das Erzeugen einer Festplattenpartition und sie dann so zu mounten, dass die Skripte sie finden können. Traditionell ist das /mnt/lfs, man kann es aber nach Belieben ändern, wenn man weiß, was man tut.

Vorab ein paar Worte zum Design von jhalfs: die Autoren erstellen LFS und die weiteren Bücher in einem speziellen XML-Format namens "DocBook"; daraus werden mit trickreichen XSLT-Transformationen dann lesbare Bücher in HTML, PDF oder sogar TeX. jhalfs verwendet ebenfalls XSLT-Transformationen, um aus dem Buch die Kommandozeilenanweisungen herauszufiltern, und erstellt daraus ein Makefile und Installationsskripte für jedes Kapitel, d.h. jedes zu installierende Paket. Die Automation mit ALFS ist also ein zweistufiger Prozess: zuerst werden aus dem Buch die Befehle zum Bauen herausgefiltert und in ein Makefile mit Hilfsskripten umgewandelt, und in einem zweiten Schritt wird diese Befehlsliste ausgeführt.

Die Autoren liefern außerdem eine komplette Liste der Softwarepakete mit Versionsnummern, die man entweder selbst herunterladen kann oder die automatisch nach Bedarf geholt werden, wenn man eine einigermaßen schnelle Internetverbindung hat. Grob geschätzt muss man für LFS ca. 400 MB an Paketen herunterladen und für BLFS, je nach Umfang, bis zu 2 GB.

Die Pakete sollte man in einem Verzeichnis /mnt/lfs/sources unterhalb der zukünftigen LFS-Partition ablegen, damit während des Ablaufs alle Pakete gefunden werden können. Hierzu wird eine Unix-Technik namens "chroot" (change root) verwendet, um einem laufenden Programm eine andere Festplattenstruktur vorzutäuschen - effektiv wird das verwendet, um so zu tun, als würde es schon in der "richtigen" LFS-Umgebung ausgeführt werden.

Das Makefile für LFS wird in einem neuen Unterverzeichnis erzeugt, in das man nach der Festlegung von ein paar Grundannahmen wechseln muss. Genau wie /sources sollte dieses Verzeichnis auf der zukünftigen LFS-Partition liegen, damit alle Skripte auch in der "chroot"-Umgebung erreichbar sind. Wenn man nun dort "make" startet, sollte nach einigen Stunden (je nach Geschwindigkeit des Rechners*) ein fast schon startfähiges Linux auf der neuen Partition vorliegen. Schritte, die man automatisieren kann, aber nicht muss, sind das Kompilieren eines Kernels und das Festlegen der Partitionen, die beim Starten gemountet werden sollen.

*) Als grobe Richtschnur zwei Vergleichszahlen, die ich mit der aktuellen LFS-Version gemessen habe. Das Paket, das mit großem Abstand am längsten dauert, ist der finale Schritt, den C-Compiler zu kompilieren. Auf einem alten Pentium 4 dauert das 540 Minuten, auf einem etwas aktuelleren i5-3350 immer noch knapp 230 Minuten. Eine SSD statt einer Festplatte ist hierbei eine große Hilfe, Zeit zu sparen.

Der erste Schritt nach dem Auspacken des jhalfs-Pakets ist, in das Verzeichnis zu wechseln und dort "make" einzugeben. Wer schon mal einen Kernel selbst kompiliert hat, wird gleich einen Aha-Effekt erleben: die Konfiguration verwendet dieselbe Textoberfläche für die Menüauswahl wie der Kernel beim "make menuconfig". Hier kann man LFS/BLFS wählen, "stable" oder "development", ob der Kernel auch automatisiert kompiliert werden soll und einiges mehr. Die Grundeinstellungen sind gar nicht so schlecht, und man sollte nur ändern, was man auch versteht ;-)

Nach dem "exit" aus diesem ALFS-Menü kommt die Frage, ob man zufrieden ist mit der Konfiguration. Bei "yes" werden die schon erwähnten Prüfungen durchgeführt, ob alle Developerpakete auf dem Gastlinux vorhanden sind und bestimmte Mindestvoraussetzungen erfüllen, wie z.B. gcc mindestens in Version 4.6 (weil frühere Versionen Fehler enthalten, so dass das LFS nicht funktionieren würde oder Pakete nicht kompiliert werden können usw.). Wenn das alles erfolgreich geprüft wurde, wechselt man (als Benutzer, nicht als root) in das neue Verzeichnis und startet dort erneut "make".

Coole Socken schauen sich im Unterverzeichnis lfs-commands die Dateien unterhalb von chapter040506 und 07 erst mit dem Editor an, bevor sie make starten. Man könnte insbesondere bei den Dateien für Kapitel 7 direkt auf die Idee kommen, dort die Stellen noch zu bearbeiten, die mit **EDITME** markiert sind ;-)

Parallel dazu empfiehlt es sich, dieselbe Version des Buchs in einem Browser zu öffnen und die Kapitel zu lesen, die der Automatismus auch gerade zu bauen versucht. Bei Problemen kann man dann im jeweiligen Kapitel nachlesen, was gerade passiert.

Wahrscheinlich wird es beim ersten Mal nicht gleich komplett erfolgreich funktionieren; das ist aber nicht schlimm: wenn ein Fehler gemeldet wird, kann man sich die Logdatei dieses Schritts aus dem Unterverzeichnis logs anschauen, den Fehler beheben und dann einfach wieder "make" eingeben. Das make-Programm ist so schlau, dass es an derselben Stelle weitermacht. Manche Pakete werden mehrfach gebaut, z.B. der C-Compiler und einige Hilfsprogramme. Dies hat den Zweck, dass man nicht aus Versehen Abhängigkeiten zum Gastsystem einbaut. Wenn ein wichtiges Programm mit der C-Bibliothek des Gastsystems gelinkt wäre, würde das nach dem Booten ja nicht mehr funktionieren. Also wird ein "Zwischensystem" in einem anderen Pfad (/tools) gebaut, das dann das endgültige LFS kompilieren kann.

Ein paar generelle Tipps, wenn das Kompilieren eines Pakets fehlschlägt: gcc 7.3 ist "bleeding edge", also so brandneu, dass man sich bei Verwendung auch mal in die Finger schneiden kann ;-). Ich will damit sagen, dass hier soviele Änderungen drin sind, z.B. Anpassungen an die aktuellen C- und C++-Standards, die in den meisten Paketen und in den Gehirnen der Entwickler noch nicht angekommen sind. Aber: man will gcc 7.3 und aktuelle binutils einsetzen, weil hier die Reparaturarbeiten für Meltdown und Spectre stattfinden. Trotzdem nochmal die Empfehlung: erst mal ein "stable" LFS bauen und danach als Steigerung auf "development" umsteigen.

Typisches Problem beim Kompilieren:
  • ein C-Programm verwendet Datentypen, die jetzt in einer neu eingeführten include-Datei <stdint.h> deklariert werden und nicht mehr in <stdlib.h>. Vorläufig muss man also irgendwo den zusätzlichen include-Befehl unterbringen, bevor das Programm erfolgreich kompiliert werden kann. Freundlicherweise sagt make sehr genau, wo ein Problem aufgetreten ist.
  • beim Korrigieren eines Problems hat man Dateien oder Verzeichnisse als root editiert oder bearbeitet. Das führt zu einem Folgefehler, weil LFS alles mit dem Benutzer "lfs" durchführen will und dann ein Abbruch wegen Berechtigungsproblemen passieren kann (bringe ich laufend fertig).
    chown lfs:lfs is your friend.
Was mir noch untergekommen ist:
  • das gcc-interne Makro __sigemptyset gibt es nicht mehr. Man kann stattdessen sigemptyset (ohne die Unterstriche) verwenden.
  • die Makros major und minor für Devices sind jetzt in <sys/sysmacros.h> zu finden.
  • grub lässt sich mit binutils 2.30 auf 32-bit-Systemen nicht übersetzen, man muss zusätzlich zu den configure-Switches im LFS-Buch noch den Switch "--enable-64-bit-bfd" angeben. Alternativ binutils 2.29.1 statt 2.30 verwenden.
Zwei Schritte sind im LFS-Buch etwas vage beschrieben, weil sie sehr stark vom eigenen PC abhängen: die Konfiguration des Kernels und die bootfähige Festplatte. Wenn man ein Linux-Gastsystem mit "kernelconfig"-Unterstützung hat, kann man sich selbst einen maßgeschneiderten Kernel bauen mit "make oldconfig", das verwendet dann nämlich genau die Einstellungen, die im Moment aktuell sind.

Der einzige wichtige Punkt ist, dass das Filesystemformat des Bootlaufwerks in den Kernel fest kompiliert sein soll. Es nutzt nichts, wenn das Root-Filesystem mit ext4 formatiert ist und der Kernel die ext4-Fähigkeit erst mit einem Modul lernen soll, das auf der ext4-Festplatte liegt - hier beißt sich die Katze in den Schwanz. Ach ja: nach dem Kompilieren von Kernel und Modulen unbedingt in der chroot-Shell "make modules_install" durchführen und in /lib/modules kontrollieren!

Für spätere Bildungs- und Forschungszwecke kann man natürlich auch eine "initiale Ramdisk" (initrd) vorsehen und dort benötigte Module und sonstige Files ablegen, aber wenn man sich einen maßgeschneiderten Kernel für diesen speziellen PC erzeugt, ist das erst mal nicht nötig. Man kann es später machen, um Microcode-Updates per "early load" zu aktivieren, aber lebensnotwendig ist es erst mal nicht. Für intel-Prozessoren gibt es hier die Microcode-Dateien.

Vor dem Reboot sollte man dann im neuen /etc-Verzeichnis (das derzeit noch /mnt/lfs/etc heißt) nach Dateien schauen, die ein "**EDITME**" enthalten. Dort kann man dann Hostname, IP-Adresse, Nameserver etc. einbauen, die zur eigenen Umgebung passen (wenn man keinen eigenen DNS-Server betreibt, die IP-Adresse des DSL-Routers, der als DNS-Forwarder die Anfragen an den Provider weiterreicht). Die Dateien findet man mit einem beherzten "grep -l EDITME /mnt/lfs/etc/*", und wenn man gleich auf einen Schwung alle bearbeiten will, wirft man die Liste der Ergebnisse einfach einem Editor vor: "vi $(grep -l EDITME /mnt/lfs/etc/*)".

Die wichtigste Datei ist hier die /etc/fstab, die beschreibt, welche Partition der Festplatte welchen Zweck hat und wohin im Filesystem gehört. Eine Swappartition sollte man auf jeden Fall vorsehen, selbst wenn der PC gefühlt genug RAM eingebaut hat. Eine Begründung dafür findet sich hier (der Autor des Artikels arbeitet bei Facebook in einem Rechenzentrum). Früher gab es mal eine Regel "doppelt soviel Swap wie RAM", aber ich würde prinzipiell für normale Desktopsysteme zwischen 2 und 8 GB Swap vorsehen.

Was man auf keinen Fall vergessen darf: dem root-User des neuen LFS-Systems vor dem Reboot ein Passwort zu geben. Sonst kann man zwar wunderbar booten, aber sich nicht anmelden ;-)

Ganz ehrlich: das Gefühl ist unbeschreiblich, wenn das selbstkompilierte Linux dann tatsächlich zum ersten Mal bootet und man den Loginprompt sieht ;-)

Wenn das neue System nicht booten will, muss man Ursachenforschung betreiben. Ein "kernel panic" tritt auf, wenn das Root-Filesystem nicht gefunden wurde. Vermutlich fehlt dann das Kernelmodul für das betreffende Filesystem. Oder die Angabe in der /boot/grub/grub.cfg passt nicht, welche Partition das ist. Die Schreibweise von grub und Linux unterscheiden sich hier leider etwas. "sda" für Linux ist "hd0" in grub.

Ein Fehler, den ich mal gemacht habe: alle USB-Treiber als Module deklariert und dann nicht in /etc/modules definiert. In dieser Situation wird es für eine USB-Tastatur schwierig, ihre Eingaben abzuliefern :-).

In solchen Situationen bootet man dann erneut das Gastsystem, mountet die LFS-Partition wieder unter /mnt/lfs und fängt an zu reparieren.

Wenn es bootet und man sich anmelden kann, ist das Reparieren leichter: die Fehlermeldungen z.B. der init-Skripte stehen ja noch auf dem Bildschirm, und man kann Schritt für Schritt alles Nötige korrigieren und das neue, selbstgebaute Linuxsystem einrichten. Das LFS hat schon alles an Bord, um eigenständig Pakete zu übersetzen und zu installieren.

Nach dem erfolgreichen LFS geht es dann mit dem BLFS weiter.
Ein paar Vorschläge, wie man sich das LFS etwas bequemer bedienbar gestaltet:
  • gpm (copy+paste mit Maus in der Textoberfläche)
  • cpio (zum Bauen von initrd)
  • openssl (ssl-Bibliothek)
  • openssh (ssh server und client)
  • dhcpcd (IP-Adresse über DHCP setzen lassen)
  • nfs-utils (wenn man ein NAS hat, z.B. eine Fritzbox, oder selbst bauen will)
  • samba (wenn man selbst ein NAS aufbauen will oder einen Windows-Domaincontroller)
  • lm_sensors (Hardwareüberwachung von CPU und Lüfter)
  • lsusb (list USB devices)
  • lspci (list PCI devices)
  • ghostscript (für PDF)
  • cups (zum Drucken)
  • Firefox (für Katzenvideos im Internet)

14.03.2018

Flash-Update auf Version 29

Mir fehlen langsam die Worte, wie die Versionsnummern inflationär in Höhen klettern. Google hat es mit Chrome vorgemacht, aus irgendwelchen Gründen macht es Mozilla mit Firefox und Thunderbird nach, und jetzt beschleunigt Adobe die Nummerierung des Flashplayers genauso.

Und weil mir die neuen Worte fehlen, nehme ich immer den alten Blogartikel, nur die Versionsnummern und die Links ändern sich ;)

Einen Hinweis muss ich aber nun doch noch einbauen: ab Ende Januar 2016 gibt es keine freien Downloads der Installationsdateien mehr. Genaue Modalitäten sind noch nicht bekannt, Adobe hat nur bekannt gegeben, dass die Downloadlinks über die "distribution3.html"-Seite nicht mehr zur Verfügung stehen werden und man eine Adobe-ID und eine Business-Lizenz benötige.

Wir sind jetzt schon bei Flash-Version 29 (mittlerweile zählt wohl auch ein Major release nicht mehr zu den besonders erwähnenswerten Ereignissen bei Adobe?). Wer sich selbst auf dem Laufenden halten will, kann das Blog des Security-Teams bei Adobe lesen oder als RSS abonnieren.

Wie üblich in ihrem freundlichen Service-Blog die passende Automation zum Herunterladen und Installieren. Falls ein Proxy verwendet wird, das "rem" bzw. "#" entfernen und eigene Proxy-Adresse eintragen.

Das Tool wget wird bei Windows noch benötigt wie hier beschrieben. Bei Linux sollte es schon vorhanden sein, da es von vielen anderen Programmen intern verwendet wird.

Für Windows wie üblich beide Varianten, ActiveX und Netscape Plugin (Achtung übrigens, Firefox wird demnächst das NPAPI komplett abschaffen - mal sehen, was Adobe und Flash dann machen).

Die Download-URL hat sich übrigens im Vergleich zu Version 23 leicht geändert, sowohl bei Windows als auch bei Linux.
@echo off
rem set https_proxy=http://192.168.100.100:3128/
set VNP=29.0.0.171
set VAX=29.0.0.171
set V=29
set H=fpdownload.adobe.com
set P=/get/flashplayer/pdc
set AX=install_flash_player_ax.exe
set NP=install_flash_player.exe
wget https://%H%%P%/%VAX%/%AX% -O flash-%VAX%_ax.exe
.\flash-%VAX%_ax -install
wget https://%H%%P%/%VNP%/%NP% -O flash-%VNP%_np.exe
.\flash-%VNP%_np -install
Für Linux 64 bit rpm (als root ausführen oder "sudo rpm" schreiben) gibt es jetzt auch wieder offiziell dieselbe Version wie für Windows. Eine Zeitlang war Flash für Linux bei Version 11.2 "eingefroren", Adobe hat es sich nun anders überlegt und liefert wieder, obwohl die Zeichen generell auf Untergang stehen - in Google Chrome ist Flash gar nicht mehr enthalten, und die anderen Browser-Hersteller wechseln auf Multimedia in HTML5 statt Flash. Es gäbe auch die Version "PPAPI" zum Herunterladen, das ist die Pluginvariante "Pepper" für das Google-API, ich gebe hier "NPAPI" für das Firefox-API im Skript an.
#!/bin/sh

# https_proxy=http://192.168.100.100:3128/

VL=${1:-
29.0.0.171}
H=fpdownload.adobe.com
PL=/get/flashplayer/pdc/${VL}

DL() { wget -N "$1/$2" -O "$3"; }

echo Linux 64 bit rpm ...
DL https://${H}${PL} \
   flash-player-npapi-${VL}-release.x86_64.rpm \
   flash-${VL}.x86_64.rpm
rpm -F --force flash-${VL}.x86_64.rpm
Der Filename für die 32bit-Variante ist "flash-player-npapi-${VL}-release.i386.rpm".

[20180314: Security Bulletin von Adobe]
[20180410: Security Bulletin von Adobe]
[20180509: Security Bulletin von Adobe]