Abbruch beim Booten, Dateisystem vor e2fsck gemountet

[Hans-Martin]

Hallo zusammen,

ich habe mir eine neue Festplatte besorgt, die alte soll in einem anderen Rechner verwendet werden. Zum Umstellen sind aktuell noch beide Platten (als sda und sdb) gleichzeitig angeschlossen, es wird aber im BIOS jeweils eine Platte zum Booten ausgwählt. Ich habe nach Anlegen von Verzeichnissen den kompletten Inhalt von Jessie von den Verzeichnissen der alten in die entsprechenden Verzeichnisse der neuen Platte kopiert. Die uuid-Einträge in /etc/fstab wurden modifiziert.

Auf der Festplatte ist auf den ersten Partitionen ein unproblematisch startendes Stretch installiert, die Verzeichnisse für Jessie sind sdb7, sdb8, sdb9 und sdb10. Beim Bootvorgang bricht e2fsck mit der Meldung ab, dass /dev/sdb8, entsprechend /usr, bereits gemounted sei. Wenn ich mich in die angebotene Notconsole einlogge, komme ich mit umount /dev/sdb8 und ctrl-d unproblematisch weiter.

Die Dateien in rcS.d und rc2.d, die mit dem Mounten zu tun haben, wurden ohne Aufzeigen eines Unterschieds mit diff verglichen.

Was könnte der Grund sein, weiß jemand Abhilfe?

Vielen Dank im Voraus

Hans-Martin

[owl102]

dass /dev/sdb8, entsprechend /usr

Spätestens seit systemd ist eine eigene /usr Partition eine schlechte Idee. Siehe auch: https://freedesktop.org/wiki/Software/s ... is-broken/

[Hans-Martin]

Vielen Dank,

das ist eine wichtige Information, die ich allerdings erst zukünftig berücksichtigen werde.

Zu systemd: Ich habe sysvinit-core installiert. Nach dem Wechsel von debian zu systemd erlebte ich eine unangenehme Überraschung. Ich verwende als Standard-Kodierung iso-8859-15, de_DE@euro. Trotz Eintrag in /etc/default/console-setup wird diese Einstellung von systemd ignoriert. Folge: Beim Lesen einer entsprechend kodierten Textdatei mit less auf einer Textkonsole werden die Sonderzeichen fehlinterpretiert. Eine korrekte Darstellung ergibt sich erst durch Verwendung des Pakets sysvinit-core. Als ich in den später 90er-Jahren zu Linux kam, galt das System als frei konfigurierbar. Aus meiner Sicht gab es da einige negative Entwicklungen.

Ob die Startroutine, die zu meinem Problem führte, mit sysvinit-core anders läuft, weiß ich nicht. Ich nehme es nicht an. Ich habe auf derselben (neuen) Platte Stretch installiert und dort in der Datei /etc/rcS.d/S##checkfs.sh, bei deren Abarbeitung der Abbruch erfolgt, festgestellt, dass bei Stretch in der Zeile mit dem Aufruf von fsck die Paramener -M und -A, bei Jessie -R und -A gesetzt sind. Ich habe testweise den Parameter von -R nach -M verändert, woduch der Bootvorgang nicht mehr unterbrochen wird.

Freilich ist damit der Kern meiner Frage nicht beantwortet. Wie kann es sein, dass zwei SATA-Festplatten identische Konfigurationen von Jessie haben, jeweils unter Verwendung der Parameter -R -A, auf einer Platte der Bootvorgang nie abbricht, auf der anderen immer. Ich weiß, dass sich in diesem Forum viel Sachverstand tummelt. Rein spekulativ, da der Unteschied eine Ursache haben muss, dachte ich daran, dass eventuell die Plattengeschwindigkeit eine Rolle spielen könnte, wenn parallel Prüfungen durchgeführt werden.

Vielleicht weiß doch noch jemand etwas zur Erhellung des Problems?

[mludwig]

Dein Problem hört sich an wie der Debian Bug unter (1). Da das aber längst behoben sein sollte, könnte es eine (alte) initrd sein, die nach einem Debian-Upgrade nicht aktualisiert wurde (also noch ein altes Skript enthält?).

In dem Bugreport sind auch noch weitere Bugs verlinkt oder erwähnt, die auf ähnliche Probleme bei anderen Paketen hindeuten, z. .B. in util-linux (2), systemd und initscripts, die ineinander greifen und dem Admin das Leben schwer machen (gemacht haben).

(1) https://bugs.debian.org/cgi-bin/bugrepo ... bug=763157
(2) https://bugs.debian.org/cgi-bin/bugrepo ... bug=697002

[Hans-Martin]

Danke für die beiden Links. Allerdings wird sysvinit deinstalliert, wenn man, wie ich es vorstehend beschrieben habe, auf das core-Paket zugreift. Nur damit funktioniert bei meiner Konfiguration die Darstellung von Umlauten etc. Der erste Bug sieht allerdings so aus wie das Problem, das ich hatte.

Ich betrachte dieses Forum als Nachschlagewerk und werde deshalb darstellen, was ich mit verschiedenen Tests herausgefunden habe.

1) Das Problem trat bei der Verwendung des Debian-Kernels 4.6 auf, wie er mit Stretch geliefert wird. Der Aufruf von fsck im Startscript mit den Parametern -M -A führt bei Stretch zum Mounten der usr-Partition als readwrite, bei Jessie zu readonly, wie ich kurz nach der Änderung feststellte.

2) Ich hatte Jessie bisher (auf der alten Platte) mit einem 3.16er Kernel und dem 4.6er-Kernel aus den backports ohne Probleme gestartet, hierbei mit den fsck-Parametern -R -A. Ich konnte mir nicht vorstellen, dass die beiden 4.6er-Debian-Kernel so unterschiedliche Wrkung haben würden. Aber nach der Installation des 3.16er- und des 4.6er-backport-Kernels auf der neuen Festplatte stellte ich fest, dass die Partition für /usr jeweils korrekt gemounted war.

Die Konfigurations-Dateien für die Kernel findet man in /boot. Der Vergleich mit diff ergab, dass bis auf eine Maus-Konfiguration die Dateien identisch sind. Wenn nun die 4.6er-Kernel unterschiedlich arbeiten: was ist der Grund dafür? Wenn es nicht an der Konfiguration liegt, müsste etwas in den Quellcodes geändert worden sein. Interessant wäre es auch, einen Kernel von kernel.org vergleichsweise zu installieren.