Mandriva Linux bootet nach der Installation von systemd nicht

2014
thkala

Ich habe ein Mandriva Linux-System, das urpmidirekt von Version 2010.0 auf 2010.1 und dann auf 2011.0 aktualisiert wurde. Ich hatte einige kleinere Probleme, aber nichts, mit dem ich nicht umgehen konnte.

Vor einigen Wochen informierte mich der Mandriva-Updater, dass ich zum Aktualisieren shorewallauch sysvinitmit systemdund ersetzen müsste systemd-sysvinit. Natürlich wollte ich nicht, dass der Updater ohne Grund etwas so Wichtiges wie das Boot-System berührt, also schiebe ich es ab. Natürlich störte mich das Mandriva-Updater-Applet immer wieder. Natürlich gab ich schließlich auf und stimmte zu. Und natürlich machte es so viel Durcheinander, dass mein System nicht von alleine starten kann.

Es startet normal, spuckt ein paar Nachrichten aus und dann bekomme ich eine Menge Nachrichten in diesem Format:

Starting XXXX aborted because a dependency failed. 

wobei XXXX etwas Dateisystem ist, entweder ein fsckAufruf oder ein Dateisystem-Mount. Es versetzt mich in die Root-Shell, in der die ausfallende Abhängigkeit bald offensichtlich wird: Die meisten MD-Arrays wurden noch nicht gestartet. Manuell ausführen

# mdadm -As # mount -a # systemctl default 

In dieser Reihenfolge kann das System den Bootvorgang abschließen.

Ich habe mehrere physikalische Laufwerke, die in Partitionen aufgeteilt sind, die dann in einigen RAID-1- (z. B. /boot) und RAID-5- /Arrays (, Swap und so ziemlich alles andere) kombiniert werden . Die Partitionen und Arrays sowie die darin enthaltenen Dateisysteme wurden manuell erstellt und anschließend Mandriva Linux installiert. Es gab keine nennenswerten Probleme und alles funktionierte gut, bis dahin systemd.

Ich denke, ich habe dieses Problem bis zu einem gewissen Grad aufgespürt. Das alte sysvinitSystem lief früher, /etc/rc.d/rc.sysinitdas, wie von Mandriva bereitgestellt, folgende Zeile enthält:

MDADM_RETURN=`/sbin/mdadm -As --auto=yes --run 2>&1` 

Dadurch wird ein MD-Array, das in /etc/mdadm.confdiesem Verzeichnis angegeben ist, nicht gestartet. Soweit ich das beurteilen kann, wird diese Datei nach systemder Installation nicht mehr verwendet und die Zeile oben wurde durch folgende Zeile ersetzt /lib/systemd/fedora-storage-init:

[ -r /proc/mdstat -a -r /dev/md/md-device-map ] && /sbin/mdadm -IRs 

Unglücklicherweise. meinem System scheint die /dev/md/md-device-mapDatei zu fehlen, also mdadmwird sie nicht ausgeführt. Ich kann mir ein paar Möglichkeiten vorstellen, dieses Problem zu "beheben", z. B. das Bearbeiten der systemdSkripts oder das Ändern meiner /boot/initrd.img, um alle MD-Arrays zu starten, aber ich würde es lieber so machen, dass es beim nächsten Paketupgrade nicht kaputt geht.

  • Was ist das Format /dev/md/md-device-mapund wie erstelle ich es? Ist diese Datei häufig, z. B. bei neueren mdadmVersionen, oder ist sie Fedora / Mandriva-spezifisch? Ich habe ein paar Beispiele in den Fedora-Foren gesehen, aber nichts solides.

  • Was ist der "richtige" Weg, um diesen Startfehler zu beheben? Ich würde lieber nicht auf eine Gehirnoperation zurückgreifen, wenn ich es vermeiden kann ...

  • Warum, warum, warum habe ich mich nicht an die Frage gehalten "Wenn es nicht kaputt ist, repariere es nicht!" Maxime? (Ja, das ist eine rhetorische ...)

1

1 Antwort auf die Frage

1
thkala

Ich konnte dieses Problem aufspüren. /dev/md/md-device-mapist anscheinend die mdadmGerätezuordnungsdatei auf Fedora-Systemen, während mein Mandriva-System /dev/.mdadm/mapstattdessen verwendet. Daher konnte das /lib/systemd/fedora-storage-initSkript nicht gestartet werden, mdadmda an der falschen Stelle gesucht wurde.

Anstatt die Skriptdatei zu bearbeiten und die Änderungen bei einem zukünftigen Paketupdate zu verlieren, habe ich mein eigenes Skript hinzugefügt:

$ cat /lib/systemd/mdadm-array-start  #!/bin/bash  # Start any MD RAID arrays that have not been started yet [ -r /proc/mdstat ] && /sbin/mdadm --assemble --scan  exit 0 

Ich habe auch eine Unit-Datei erstellt für systemd:

$ cat /lib/systemd/system/mdadm-array-start.service  [Unit] Description=Start MD arrays DefaultDependencies=no Conflicts=shutdown.target After=fedora-wait-storage.service Before=fedora-storage-init.service local-fs.target shutdown.target Wants=fedora-wait-storage.service  [Service] ExecStart=/lib/systemd/mdadm-array-start Type=oneshot TimeoutSec=0 RemainAfterExit=yes  [Install] WantedBy=basic.target 

Dann habe ich gerade den Dienst aktiviert:

# systemctl enable mdadm-array-start.service ln -s '/lib/systemd/system/mdadm-array-start.service' '/etc/systemd/system/basic.target.wants/mdadm-array-start.service' 

Dadurch wird sichergestellt, dass MD-Arrays ohne Eingreifen eines Administrators gestartet werden.

Zu Ihrer Information: Vom Benutzer erstellte Units sollten zu `/ etc / systemd / system` gehen. grawity vor 12 Jahren 0
@grwity: Stimmt, da `/ etc / systemd /` Einheiten Vorrang haben. In meinem Fall betrachte ich jedoch meine Einheit als Teil des Systems, ähnlich wie ein Bugfix-Patch. thkala vor 12 Jahren 0
Der Unterschied hier ist nicht "Teil des Systems" oder nicht; es ist vielmehr "vom Paketmanager aus einem Paket installiert" gegenüber "manuell vom Benutzer / sysadmin installiert". grawity vor 12 Jahren 0
@ grawity: ähm ... meine Regel * wurde mit einem Paket-Manager installiert. Dies war der einzige Weg, um unglückliche Zwischenfälle zu vermeiden, die mein System töten könnten, wenn ich eine 4-stündige Autofahrt entfernt bin ... Auf diese Weise `rpm `fängt an zu jammern, wenn jemand versucht, meine Ergänzungen zu überschreiben ... thkala vor 12 Jahren 1