Gentoo and me (Update)

Monday, 30 August 2010

Mein Laptop betreibe ich aufgrund der damaligen Arroganz der Entwickler bereits seit fast zwei Jahren nicht mit Gentoo Linux. Und hab es auch ehrlich gesagt auch nicht bereut. Aber der Web- und Mailserver, auf dem zum Beispiel auch tasmiro.de liegt, blieb weiterhin auf diesem OS. Überstand sogar einen Serverumzug und später die Migration in eine KVM. Doch gestern abend passierte ein Unglück. Eigentlich ein harmloses Update mit "emerge -Du world", wie schon duzende Male zuvor gemacht. Keine Fehlermeldung oder so. Doch als der Server auch nach 10 Minuten nicht neu gestartet war, schaute ich nach. Die genaue Todesursache hab ich nicht identifizieren können, vermutlich es hängt irgendwie mit udev und/oder baselayout zusammen. Der Kernel findet noch beide (virtuelle) Festplatten, aber es wird kein Eintrag in /dev erstellt. Dadurch scheitert das Mounten und dem System fehlen /boot, /var und /home.

Nun ja, ich habe einige Stunden lang versucht, das Leben des Patienten zu retten, aber vergeblich. Da er schon sehr alt ist, und auch einige Geschwülste (also nicht vollständig entfernte, aber inzwischen überflüssige Programme) hat, werde ich ihn ziehen lassen. Im Moment erstelle ich das letzte Backup seines Lebens, danach schließe ich die VM wieder an die Herz-grml-Maschine an, und heute abend kümmere ich mich um ein neues System.

RIP, Gentoo.

[Klarstellung: Damit ist nicht gemeint, dass ich Gentoo den Untergang wünsche, im Gegenteil - die Welt braucht solche Distributionen. Aber für mich persönliche war dies das letzte noch im Einsatz befindliche System, welches nun auf eine andere Distribution migriert wird. Entsprechend ist der "Nachtrag" auch als eine persönliche Anmerkung zu betrachten; solche Situationen sind auch bei Gentoo gewiss nicht an der Tagesordnung.]

Nachtrag:
Ich muss es einfach nochmal erwähnen: Dass ein Linux-System nach einem regulären Update nicht wieder startet ist der absolute Worst-Case. Vor allem wenn nicht einmal der Kernel betroffen ist darf das einfach nicht passieren. In diesem Fall hatte ich Glück, dass es sich um eine virtuelle Maschine handelt und ich damit auch ohne SSH an das Ding rankomme, es sogar von einem Rettungssystem booten kann. Wäre es das Hostsystem gewesen, dann hätte ich mir die Nacht um die Ohren schlagen dürfen, weil die provisorische Inbetriebnahme kaum möglich gewesen wäre.

Nachtrag 2:
Nach dem Hinweis von Linux Freund in den Kommentaren habe ich nochmal weiter recherchiert. Es lag an den Kernel-Flags "CONFIG_SYSFS_DEPRECATED" und "CONFIG_SYSFS_DEPRECATED_V2". udev hatte mich zwar darauf hingewiesen, dass es damit ein Problem geben könnte. Da ich nicht viel Zeit hatte, kompilierte ich deshalb einen Standardkernel mit "genkernel". Hätte ich ahnen sollen, dass auch dieser diese Flag enthalten würde? Keine Ahnung... unvernünftigerweise hatte ich mich darauf verlassen, dass da schon ein Kernel herauskommen würde, mit dem jedes normale Gentoo-System funktioniert. Tat es aber nicht. Nun habe ich meinen ursprünglichen Kernel nochmal ohne diese Flags kompiliert, und das System fährt hoch. Leider hat der Up- und Downgrade des "baselayouts" von 1 auf 2 und dann wieder auf 1 wohl doch noch etwas mehr kaputt gemacht.

Linux
Gentoo
IMHO

Comments

Linux Freund (not verified)

2. September 2010 - 13:20

Es tut mir leid, dass du nach dem Gentoo Update nicht mehr booten konntest, aber das ist nicht Gentoos/emerges Schuld, sondern deine. Das kann ich deswegen so fest behaupten, weil ich dein Problem mit udev kenne und weiss, dass emerge beim udev Update eine Warnung zu dem Thema ausgibt. Vielleicht solltest du nochmal das mergelog durchlesen? Eigentlich müssten auch schon seit Wochen beim booten deprecation Meldungen diesbezüglich gekommen sein. Afair gabs sogar eine news Meldung dazu, da bin ich mir aber nicht sicher. Bitte behaupte nicht einfach Sachen über Gentoo, für die du keine Belege hast. Denn solange du nicht das Gegenteil beweisen kannst, bist du für mich an deinem Problem Schuld und nicht Gentoo. Es ist sehr unwahrscheilich, dass emerge das System so ändert, dass es nicht mehr bootbar ist ohne vorher eine Meldung auszugeben. Wenn es mal nicht so ist, ist in jedem Fall ein Bugreport fällig. Bei Gentoo sind zwei Fähigkeiten wichtig: 1. Die Fähigkeit zu lesen und 2. die Fähigkeit das gelesene auf sein System anzuwenden. Bei anderen Distributionen ist das nicht zwangsweise so.

Cybso (not verified)

3. September 2010 - 10:11

@Linux Freund: Ich hab wirklich viele, viele Jahre Gentoo eingesetzt, und diese Distribution mehrfach verteidigt. Ich kenne Linux extrem gut, und in aller Regel kriege ich Probleme wie diese in den Griff. Das Mergelog lasse ich mir genau aus diesem Grund auch per E-Mail zuschicken. Und weißt du, was da zu udev drin steht?

> udev-151 does not support Linux kernel before version 2.6.25!
> For a reliable udev, use at least kernel 2.6.27

Es läuft 2.6.31.

Des Weiteren:

> ERROR: setup
> CONFIG_SYSFS_DEPRECATED: should not be set. But it is.
> CONFIG_SYSFS_DEPRECATED_V2: should not be set. But it is.
> CONFIG_IDE: should not be set. But it is.

Aus diesem Grund habe ich einen neuen Kernel mit (Gentoo-)Standardoptionen kompiliert, der aber das Problem auch nicht beseitigte.

Nachtrag: Das ließ mir gerade ja keine Ruhe, deswegen habe ich mir die .config nochmal genauer angeschaut. Und tatsächlich enthält die Standardkonfiguration mit genkernel diese "deprecated"-Flags. Das hatte ich nun wirklich nicht erwartet. Ich kompiliere den Kernel nun nocheinmal ohne SYSFS und berichte dann, ob es geholfen hat.

Nachtrag 2: Hat es. Lag also tatsächlich daran, dass ich mich wahnsinnigerweise darauf verlassen habe, dass "genkernel" schon einen Kernel bauen würde, mit dem das System auch funktioniert.

Sorry, aber ich weiß ja nicht mal, ob es wirklich udev war oder irgendetwas anderes (obwohl Probleme mit einem unvollständigen dev nunmal auf diesen Dienst hinweisen). Aber keiner der Portage-Mails vom besagten Update hat mir auch nur in Indiz gegeben, woran es liegen soll. Keine Logdatei hat eine (für mich) verwertbare Information ausgegeben - außer, dass der Kernel die entsprechenden Devices durchaus erkannt hat. Weswegen mir letztendlich nur bliebe, das Grundsystem neu einzurichten. Und dazu habe ich einfach keine Lust.

Aus diesem Grund auch kein Bugreport: Dieser würde es erfordern, dass ich viele weitere Stunden in die Suche nach der Ursache aufbringe. Aber die Zeit habe ich nicht.

Wenn du willst, dann lösche ich stumpf alle persönlichen Daten von dem System und drück dir das abgespeckte Image als tarball in die Hand. Allerdings fürchte ich, dass meine letzten verzweifelten Experimente (Upgrade auf baselayout-2, später wieder ein Downgrade auf baselayout-1 - dabei geht übrigens die /etc/conf.d/net verloren, ernsthaft!) mehr zusätzlichen Schaden angerichtet haben als sie genutzt haben. Das Update hatte ich ausprobiert, da "/etc/init.d/udev start" behauptete, nur mit einem baselayout-2 funktionieren zu können.

@roo: Selbstverständlich habe ich ein revdep-rebuild ausgeführt. Ebenso wie ein dispatch-conf. Den Server starte ich nach einem solchen Update neu, wenn wichtige Systemdienste betroffen waren, um die Gefahr zu reduzieren, dass ich irgendwann mal nach einem Stromausfall o.ä. vor genau diesem Problem stehe: Die Maschine fährt unerwarteterweise nicht mehr hoch :-).

ro0 (not verified)

2. September 2010 - 13:44

Sehr unwahrscheinlich bei einem stable-Gentoo-System!

Evtl solltest du den Output von `emerge` zu den einzelnen Paketen mal genauer lesen, bevor die die Schuld auf Gentoo schiebst. Wahrscheinlich hätte es ein ganz normales `revdep-rebuild` schon getan ;-)

Und btw: Welchen Grund gibt es einen Server neu zu starten? Du sagtest ja selber, kein Kernel-update! Hmm? :P