[Eisfair] [e1] boot hängt: Enter runlevel

[Marcus Röckrath]

Hallo Wolfgang,

W. Loefstedt wrote:

> Am 11.01.2021 um 20:26 schrieb Marcus Röckrath:
> 
>> Kannst du den gesamten Bootvorgang mal abfilmen und dann den Film
>> irgendwo zu Download ablegen.
> 
> Hier ist der link:
>
https://drive.google.com/file/d/1xR7RFCaa337n9Asnwdz0nD8HoDsDKzX8/view?usp=sharing
> 
> Den Raid bilden die beiden WD-Platten, die Seagate soll die Backups
> aufnehmen. Bisher waren der Raid sda und sdb, nach Einbau der Seagate
> dann sdb und sdc, und die Seagate sda.
> 
> Heute hat sich die Zuordnung verändert: Raid sda und sdb, die Seagate
> sdc. Nach einem Reboot kam es dann zu dem geschilderten Fehler.

Nur um den Ablauf klar zu haben:

Ursprungssystem mit 2 Platten im Raid sda/sdb

Einbau der Seagate und erfolgreicher Boot: Raid dabei sdb/sdc; Seagate sda

Nach erneutem Boot wechselt das Raid wieder auf sda/sdb und die Seagate wird
zu sdc, wobei der Boot beim mit "Enter runlevel" hängt.

Möglicherweise kann man hier dann den Runlevel eingeben, nämlich 2, aber
richtig ist das nicht. Fehlt eventuell /etc/inittab bzw. ist "zerstört"?
Könnte man mit einem Rettungssystem nachsehen.

Ist das Problem insgesamt eine Folge des Ram-Problems, so dass im
Dateisystem doch mehr kaputtgegangen ist?

Ganz am Ende des Bootvorgangs, an der Stelle, an der das RAID gebildet wird,
kommen folgende Meldungen:

md: bind<sdc3>
md: bind<sdc2>
md: bind<sdc1>
md: bind<sdb2>
md: bind<sdb1>
md/raid1:md2: active with 2 out of 2 mirrors
md/raid1:md1: active with 2 out of 2 mirrors
md2: detected capacity change from 0 to 215495752
md: bind<sdb3>
md/raid1:md3: not clean -- starting background reconstruction
md/raid1:md3: active with 2 out of 2 mirrors
md3: detected capacity change from 0 to 77802831872
md: resync of RAID array md3
md: using 128k window, over a total of 75979328k.
md: using maximum available idle IO bandwith (but not more than 200000
KB/sec) for resync
md: resuming resync of md3 from checkpoint.
md1: detected capacity change from 0 to 65667072
md1:
Executing "mdadm --assemble --scan" ...
Executing "udevadm settle" ...
Executing "mdadm --incremental --run --scan" ...
rootdev is a UUID: UUID=6174a464-6b28-47b7-ab2b-9a92e9bef022
Converting UUID=6174a464-6b28-47b7-ab2b-9a92e9bef022 to device ...
UUIDDEV is /dev/md3.
rootdev is now /dev/md3.
rootdev is /dev/md3.
EXT4-fs (md3): mounting ext3 file system using the ext4 subsystem
EXT4-fs (md3): mounted filesystem with ordered data mode. Opts: (null)
Executing switch_root and spawning init ...
INIT: version 2.89 booting

Enter runlevel: 


Ich habe hier kein RAID-System, um die Meldungen vergleichen zu können.

Folgendes erscheint mir aber komisch:

Sind die "capacity change" Zeilen beim Boot korrekt, denn bei einem
gebooteten RAID-System tauchen die in der dmesg (im Gegensatz zu den
anderen md-Meldungen zu bind oder active Zeilen) nicht auf. Da das
Raid-System nicht vor Ort ist, kann ich dessen Bootmeldungen nicht sehen.

Wenn ich nach "detected capacity change" im Internet suche, könnte eine
solche Meldung durchaus auf ein Problem (Superblock?) hindeuten.

Auf ein Problem weist auch hin, dass das md3 nicht clean ist und resync
werden muss.

Bleibt die Frage, weil das Bootvideo hier keine merkloiche Wartezeit hat, ob
der Resync sehr schnell erledigt ist, wenn md3 zum rootdev wird oder das im
Hintergrund noch läuft.

Wie oben auch schon angedeutet, könnte auch ein Problem mit der /etc/inittab
vorliegen, wenn das System nicht weiß, wie es an der Stelle nun weitergehen
soll.

-- 
Gruß Marcus
[eisfair-Team]