Ich bin nicht sicher, was ich sonst noch prüfen soll. Alles unten sieht für mich vernünftig aus, aber das System hängt beim Booten. Dies ist ein Heimserver mit vier Festplatten, die in einen Dell OP620 gequetscht sind. Jedes Festplattenpaar ist als RAID1 zusammengestellt: /und data. Das ausgefallene Array ist /, daher die Unfähigkeit zu booten.
Der vollständige Fehler, der auf der Konsole unbegrenzt wiederholt wird, lautet:
incrementally starting raid arrays
mdadm: Create user root not found
mdadm: create group disk not found
incrementally started raid arrays
Ein ähnlicher Screenshot ist verfügbarHier. Dieses System lief bis zum letzten Neustart einwandfrei. Das Array lässt sich problemlos von einem Puppy Linux-Rettungs-USB-Stick zusammenbauen:
mdadm --assemble --scan
fdiiskzeigt die verfügbaren Datenträger an:
# fdisk -l|grep GB
Disk /dev/sda: 320.1 GB, 320072933376 bytes
Disk /dev/sdb: 320.1 GB, 320072933376 bytes
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes
Disk /dev/md127: 3000.5 GB, 3000457494528 bytes
Disk /dev/md126: 317.9 GB, 317938532352 bytes
Gefolgt von blkidder Anzeige der UUIDs:
# blkid
/dev/md126: UUID="fc836940-3c99-4f64-8751-decc9629abc5" TYPE="ext4"
/dev/md0: UUID="2b00d6da-aa0e-4295-a1bb-822f4224815b" TYPE="swap"
/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="908ccc1f-cb70-4d3e-9d81-43b8e0f519ff" TYPE="ext4"
/dev/sdb1: UUID="3a052c52-593f-47d5-8606-cb818619c50b" TYPE="ext4"
/dev/sde1: LABEL="8GB_BLACK_P" UUID="1CE1-AF11" TYPE="vfat"
und ich kann das md126Gerät mounten mit:
mount /dev/md126 /mnt/tmp
Meine (bisher funktionierende) fstab-Datei ist:
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/md1 during installation
UUID=fc836940-3c99-4f64-8751-decc9629abc5 / ext4 errors=remount-ro 0 1
# swap was on /dev/md0 during installation
UUID=2b00d6da-aa0e-4295-a1bb-822f4224815b none swap sw 0 0
/dev/mapper/3TB_RAID--1--LVM-lvol0 /data ext4 nosuid,auto 0 0
Antwort1
Ich hatte gerade auch dieses Problem. Mir ist aufgefallen, dass Ihr MD die Nummer md126 hat, was normalerweise eine zufällige Nummer ist, die beim Booten erstellt wird, nicht die Nummer vonmdadm.conf
In /boot/grub/grub.cfgbeziehen sich verschiedene Dinge sowohl auf /dev/md??als auchUUID=.....
Beides ist erforderlich. Wenn die Maschine jedes Mal mit einer zufälligen md???-Nummer hochfährt, hat initrd Probleme, das Raid zu finden, und gerät in eine Endlosschleife.
Ich musste diese Nummern ändern, weil ich mein MD-Gerät neu erstellt habe.
update-grubgreift die md?Nummer von dem ab, was gerade läuft, /proc/mdstatsund fügt sie ein in/boot/grub/grub.cfg
update-initramfsholt sich die md?Nummer aus der /etc/mdadm/mdadm.confDatei und fügt sie in /boot/initrd___ „Beide müssen übereinstimmen“ ein.
Wenn Sie über eine Rettungsdiskette booten, /dev/md...ist dies einfach die zufällige Zahl, die die Rettungsdiskette bildet. Diese unterscheidet sich von der md...Zahl in/etc/mdadm/mdadm.conf
mdadm --stop /dev/md...Ich habe es auf allen Festplatten ausgeführt . Dann lief ...
mdadm --assemble --config=/etc/mdadm/mdadm.conf --run
cat /proc/mdstat # To check that the numbers are correct.
update-grub
Wenn Sie ändern müssen /etc/mdadm/mdadm.conf, führen Sie auchupdate-initramfs
Sieht aus, als ob in Ihrer fstab steht ; das ist die Nummer, die in und / was on /dev/md1 during installationenthalten sein könnte ./boot/grub/grub.cfg/etc/mdadm/mdadm.conf
Antwort2
Ich habe diesen Fehler auf einer virtuellen Xen-Maschine erhalten, die tatsächlich über keine RAID-Konfiguration verfügt (die Dom0/Host-Maschine jedoch schon).
Der eigentliche Fehler liegt nicht beim RAID, aber Sie müssen im Protokoll etwas nach oben scrollen und auf meinem Computer besteht der eigentliche Fehler darin, dass keine Festplatten (oder Netzwerkadapter/VIF) vorhanden sind. Es besteht also ein Problem mit dem Xenbus, der die Geräte für die virtuelle Maschine bereitstellt:
[ 272.220880] xenbus_probe_frontend: Timeout connecting to device: device/vbd/51714 (local state 1, remote state 1)
[ 272.221595] xenbus_probe_frontend: Timeout connecting to device: device/vbd/51713 (local state 1, remote state 1)
[ 272.222102] xenbus_probe_frontend: Timeout connecting to device: device/vif/0 (local state 1, remote state 1)
Ich habe das Problem gelöst, indem ich den Hostcomputer neu gestartet habe. Danach wurden die erstellten virtuellen Xen-Maschinen wieder normal gestartet und alle Geräte erkannt.