Hallo, ein Server bootet nicht mehr, Betriebssystem ist debian stretch. Fehlermeldung siehe kvm-Screenshot. Ich habe grub reinstalliert und konfiguriert, aber ohne Ergebnis. Der Server enthält zwei Festplatten, die als raid0 konfiguriert sind. Ich kann problemlos in ein rescue-System booten und habe auch Zugriff auf die raid Volumes. Hat vielleicht jemand einen Vorschlag zur Diagnose und/oder Reparatur? Herzliche Grüße Timm
Angehängte Dateien:
Direkt die UUID funktioniert mit Grub ggf. nicht sauber, ich hatte da teils Probleme, Workaround war einfach /dev/by UUID oder so zu nehmen. Gibt da einen Thread bei Stack/Serveroverflow/Reddit. Generell sieht deine UUID komisch aus, schon geprüft ob das wirklich so passt von der Syntax her in der Config? Wobei error reading sector auch nicht gut klingt. Was sagen die Smartwerte? Wie sieht die ganze dmesg Ausgabe aus?
Timm R. schrieb: > Der Server enthält zwei Festplatten, die als raid0 konfiguriert sind. Das klingt nicht gut. Bei Raid 0 bedeutet ein Problem mit einer Platte einen Verlust der Daten. Da zwei Platten involviert sind, verdoppelt das nahezu die Ausfallwahrscheinlichkeit. Brauchst du die erhöhte Performance? Dann wäre mein Vorschlag, das ganze System auf eine dritte kleine Platte zu installieren und das Raid0 nur für /home zu benutzen.
:
Bearbeitet durch User
Ich würde mal fsck über die boot partition laufen lassen. Ist das grub 1 oder grub2? Falls es grub2 ist, hat grub wohl was boot verzeichnis und seine Module nicht gefunden. Man könnte versuchen grub testweise auf die Sprünge zu helfen. Versuche mal mit ls und cat im grub prompt nachzusehen, wo diese sind. Wenn du diese gefunden hast, setze die Variable prefix entsprechend "set prefix=(hdX,Y)/boot/grub" und gib "normal" ein, oder falls das nicht klappt, versuche "insmod minicmd". Lade danach die Konfigurationsdatei "configfile /boot/grub/grub.cfg". Wie hast du grub reinstalliert? Mit apt-get, oder mit dpkg-reconfigure, oder manuell mit grub-install und update-grub? ich würde die letzteren 2 nochmal ausprobieren. Und wiso nutzt du raid0? Ich würde nichts unter raid1 verwenden, wenn überhaupt.
Daniel A. schrieb: > Ich würde mal fsck über die boot partition laufen lassen. Aber erstmal nur angucken und nichts reparieren lassen. Das kann Platten nämlich leider auch zermanschen - so hier mal erlebt. Also Vorsicht.
Hast Du mal die SGD probiert, https://www.supergrubdisk.org/super-grub2-disk/ damit habe ich mal einen Server mit RAID1 wieder zum laufen bekommen, der sonst nicht mehr wollte.
Im Rescue-System kontrolliere mal die UUID der Platte, von der gebootet werden soll. Edit: z.B. mit blkid Dann vergleiche das mit dem Eintrag in /boot/grub/grub.cfg und in der fstab.
:
Bearbeitet durch User
Beitrag #5272842 wurde vom Autor gelöscht.
Hallo, np r. schrieb: > Im Rescue-System kontrolliere mal die UUID der Platte, von der gebootet > werden soll. Edit: z.B. mit blkid > Dann vergleiche das mit dem Eintrag in /boot/grub/grub.cfg und in der > fstab. hm hm hm, also blkid liefert 6fe28fbd-5206-f2c8-e76b-83cbb63f5d0b in mdadm.conf steht 6fe28fbd:5206f2c8:e76b83cb:b63f5d0b und in grub.cfg steht set root='mduuid/6fe28fbd5206f2c8e76b83cbb63f5d0b' sind das die selben? Ich denke schon, oder spielen die Sonderzeichen eine Rolle? vlg Timm das chroot mache ich übrigens mit
1 | mount /dev/md2 /mnt |
2 | mount /dev/md1 /mnt/boot |
3 | mount -t dev -o bind /dev /mnt/dev |
4 | mount -t proc -o bind /proc /mnt/proc |
5 | mount -t sys -o bind /sys /mnt/sys |
6 | chroot /mnt |
das sollte doch ok sein? Also die Zuordnung von md1 und md2 stimmt so.
Wenns RAID1 ist kannst du doch einfach mal eine Platte wegnehmen und es müsste auch so laufen?
Timm R. schrieb: > Hallo, > > np r. schrieb: >> Im Rescue-System kontrolliere mal die UUID der Platte, von der gebootet >> werden soll. Edit: z.B. mit blkid >> Dann vergleiche das mit dem Eintrag in /boot/grub/grub.cfg und in der >> fstab. > > hm hm hm, > also blkid liefert 6fe28fbd-5206-f2c8-e76b-83cbb63f5d0b > in mdadm.conf steht 6fe28fbd:5206f2c8:e76b83cb:b63f5d0b > und in grub.cfg steht set root='mduuid/6fe28fbd5206f2c8e76b83cbb63f5d0b' > > sind das die selben? Ich denke schon, oder spielen die Sonderzeichen > eine Rolle? > > vlg > > Timm > > das chroot mache ich übrigens mit >
1 | > mount /dev/md2 /mnt |
2 | > mount /dev/md1 /mnt/boot |
3 | > mount -t dev -o bind /dev /mnt/dev |
4 | > mount -t proc -o bind /proc /mnt/proc |
5 | > mount -t sys -o bind /sys /mnt/sys |
6 | > chroot /mnt |
7 | > |
> > das sollte doch ok sein? Also die Zuordnung von md1 und md2 stimmt so. Hier noch der vollständige Output von blkid. Vlg Timm /dev/loop0: UUID="40c4ea95-0ecc-4c51-9f3e-e49d8f62f160" TYPE="ext2" /dev/sdb1: UUID="d5fe8d37-3287-8c0b-fc01-0aee6cf5611d" UUID_SUB="796f6a46-343f-1cd3-afda-cc8c9c0390fa" LABEL="rescue:0" TYPE="linux_raid_member" PARTUUID="4358a7a9-8a49-49d8-a264-efd5cc68b329" /dev/sdb2: UUID="6fe28fbd-5206-f2c8-e76b-83cbb63f5d0b" UUID_SUB="14c5bf19-7268-cd97-7c1e-c36197592d53" LABEL="rescue:1" TYPE="linux_raid_member" PARTUUID="40fdfdaa-781c-40d5-a1c9-28a7fb007a27" /dev/sdb3: UUID="edec77d8-74ba-0b98-579c-4c6ed2bcc582" UUID_SUB="28e59699-242f-d4f0-de33-1b025c7b30f2" LABEL="rescue:2" TYPE="linux_raid_member" PARTUUID="959b2337-e5b2-4b1f-86de-a32e95cc17ef" /dev/sdb4: UUID="0f494bf3-e327-5403-31ae-a6b6c90b5435" UUID_SUB="3c92a776-5fe4-9688-f353-1b4d4c0a130f" LABEL="rescue:3" TYPE="linux_raid_member" PARTUUID="6936c79d-cd8f-4f16-9008-2ceacf391467" /dev/sda1: UUID="d5fe8d37-3287-8c0b-fc01-0aee6cf5611d" UUID_SUB="cc55ab1c-8eae-3fa7-8c3b-2655d5605df9" LABEL="rescue:0" TYPE="linux_raid_member" PARTUUID="b6bbb7be-165c-4497-81e2-7e423ffdd0ba" /dev/sda2: UUID="6fe28fbd-5206-f2c8-e76b-83cbb63f5d0b" UUID_SUB="0270efa7-0c1b-8016-c5c1-ebaaaad52b1e" LABEL="rescue:1" TYPE="linux_raid_member" PARTUUID="4b3b6f8f-37e7-40f4-8024-1c711b1d96b1" /dev/sda3: UUID="edec77d8-74ba-0b98-579c-4c6ed2bcc582" UUID_SUB="2a61a9d0-cad4-5091-bea3-f13227e245f2" LABEL="rescue:2" TYPE="linux_raid_member" PARTUUID="9c6d400b-dbdc-4c57-af92-2a1b08b91bee" /dev/sda4: UUID="0f494bf3-e327-5403-31ae-a6b6c90b5435" UUID_SUB="3014ae17-2e77-ee71-5b39-852820dfcc6c" LABEL="rescue:3" TYPE="linux_raid_member" PARTUUID="7b02173f-e52e-4f57-aeb2-9c7eb74e6835" /dev/md0: UUID="fb485bdc-5465-4f58-b3a5-498b2411864b" TYPE="swap" /dev/md1: UUID="4545b7ea-d8a4-4584-880d-2ac4dfb410ba" TYPE="ext3" /dev/md2: UUID="9781ae9c-7a10-4ad8-930e-6702f8764d26" TYPE="ext4" /dev/md3: UUID="f0ce27f5-a88f-4327-ba4f-7337de3d9538" TYPE="ext4" /dev/sda5: PARTUUID="71bce636-daf6-4ea4-8ad8-ee5ddf9d290a" /dev/sdb5: PARTUUID="08f1585a-ff42-4874-9daf-dbbc7697a09a"
Also, wieviel Raid Arrays hast du da im System? Wenn mdadm das Raid1 gestartet hat, macht er aus 2 Platten eine und nennt die dann z.B. /dev/md0. Mein Raid1 unter jessie besteht z.B. aus /dev/sda1 und /dev/sdb1 (2 Stück WD Red 2TB), meine Systemplatte ist /dev/sdc1, die nichts mit dem Raid zu tun hat und die das Startvolume ist. 'mount' gibt folgendes aus, bei dem ich mal nur die Platten zitiere und den anderen Kram weglasse:
1 | /dev/sdc1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) |
2 | /dev/md0 on /home type ext3 (rw,relatime,data=ordered) |
ein /dev/md1 und ein /dev/md2 würden mich also stutzig machen. Dann checke doch bitte nochmal den berechtigten Einwurf T.roll schrieb: > Bootest du wirklich von Diskette (fd0)?
Daniel A. schrieb: > Wie hast du grub reinstalliert? Mit apt-get, oder mit dpkg-reconfigure, > oder manuell mit grub-install und update-grub? ich würde die letzteren 2 > nochmal ausprobieren. Ich habe apt-get update apt-get --reinstall install grub-pc grub-mkdevicemap -n dpkg-reconfigure grub-pc (dort habe ich sda, sdb ausgewählt und zwei Optionen nicht, eine davon war md1) update-grub grub-install /dev/sda /dev/sdb gemacht. vlg Timm
Edit: Ahh, jetzt versteh ich, du hast auf jeder Raidplatte nochmal extra Partitionen, ums kompliziert zu machen, und auch das Swap. Na gut, das machts nicht einfacher. Aber besorge dir am besten erstmal eine neue Platte und hänge die als Spare an mdadm ran.
Hallo, die Platten sind in Ordnung und das Raid auch nicht degraded. Der Grund für den Ausfall muss in einem regulären apt-get upgrade liegen. vlg Timm P.S: Platten austauschen wäre deswegen für mich auch nicht naheliegend, abgesehen davon müsste ich eine remote hand bezahlen ...
Die Sonderzeichen sind nur, damit Du's leichter lesen kannst. Die UUIDs sind identisch. /boot ist auf md1 (aus sda2/sdb2)? Dann könnte Daniel Abrecht (daniel-a) Recht haben, dass Dir da z.B. das mdraid1x Modul fehlt.
Timm R. schrieb: > P.S: Platten austauschen wäre deswegen für mich auch nicht naheliegend, > abgesehen davon müsste ich eine remote hand bezahlen ... Das hat auch niemand gesagt. Ich habe dir nur vorgeschlagen, eine Spare Platte zu addieren. Dann nimm die Diskette aus dem Laufwerk...
Hallo, np r. schrieb: > Die Sonderzeichen sind nur, damit Du's leichter lesen kannst. Die UUIDs > sind identisch. > /boot ist auf md1 (aus sda2/sdb2)? > Dann könnte Daniel Abrecht (daniel-a) Recht haben, dass Dir da z.B. das > mdraid1x Modul fehlt. koennte sein. In /etc/grub.d müsste es eine Konfiguration mit insmod mdraid1x geben, richtig? Gibt es nicht. folgende Konfigurationen gibt es 00_header 05_debian_theme 10_linux 20_linux_xen 30_os-prober 30_uefi-firmware 40_custom 41_custom In keiner ist mdraid1x vlg Timm
Wenn /boot und root auf md1 (aus sda2/sdb2) ist, dann versuch mal in grub rescue manuell zu booten: grub rescue> set prefix=(hd0,2)/boot/grub grub rescue> set root=(hd0,2) grub rescue> insmod normal grub rescue> normal grub rescue> insmod ... was auch immer Du brauchst: part_gpt, mdraid1x, ext2... grub rescue> insmod linux grub rescue> linux /boot/vmlinuz root=/dev/md1 grub rescue> initrd /boot/initrd.img grub rescue> boot
Hallo, das failure reading sector kommt doch nur, weil nach der HD noch die Floppy probiert wird, oder nicht? Da ist keine Diskette im Laufwerk, kann ich mir jedenfalls nicht vorstellen, dass da im Rechenzentrum jemand hingelatscht ist und mir eine Diskette ins Laufwerk gesteckt hat. vlg Timm
Ich sehe gerade, dass Du boot auf md1 hast und auf md2. Dann muss es oben heißen: grub rescue> set prefix=(hd0,2)/grub (da gibt's ja kein /boot Verzeichnis mehr) und: grub rescue> linux /boot/vmlinuz root=/dev/md2 Timm R. schrieb: >> mount /dev/md2 /mnt >> mount /dev/md1 /mnt/boot >> mount -t dev -o bind /dev /mnt/dev >> mount -t proc -o bind /proc /mnt/proc >> mount -t sys -o bind /sys /mnt/sys >> chroot /mnt Hmmm... hast Du nach dem chroot auch /dev/md1 in der chroot an /boot gemountet?
np r. schrieb: > Wenn /boot und root auf md1 (aus sda2/sdb2) ist, dann versuch mal in > grub rescue manuell zu booten: > > grub rescue> set prefix=(hd0,2)/boot/grub > grub rescue> set root=(hd0,2) > grub rescue> insmod normal > grub rescue> normal > grub rescue> insmod ... was auch immer Du brauchst: part_gpt, mdraid1x, > ext2... > grub rescue> insmod linux > grub rescue> linux /boot/vmlinuz root=/dev/md1 > grub rescue> initrd /boot/initrd.img > grub rescue> boot klingt spannend. Ich finde nur in der verf.... vkvm Konsole nicht das versch.... = Melde mich, wenn ichs gefunden habe vlg Timm
Timm R. schrieb: > das failure reading sector kommt doch nur, weil nach der HD noch die > Floppy probiert wird, oder nicht? Ja, genau. Da ist halt keine. Normalerweise sollte in grub.cfg so etwas wie 'search --no-floppy ... ' stehen.
np r. schrieb: > Timm R. schrieb: >>> mount /dev/md2 /mnt >>> mount /dev/md1 /mnt/boot >>> mount -t dev -o bind /dev /mnt/dev >>> mount -t proc -o bind /proc /mnt/proc >>> mount -t sys -o bind /sys /mnt/sys >>> chroot /mnt > > Hmmm... hast Du nach dem chroot auch /dev/md1 in der chroot an /boot > gemountet? hmm, da habe ich jetzt ein kleines Blackout? Ich habe doch mount /dev/md1 /mnt/boot nach dem mount /dev/md2 /mnt dann habe ich doch im chroot /mnt das boot-md2 unter /boot ?? Vlg Timm
:
Bearbeitet durch User
Timm R. schrieb: > In /etc/grub.d müsste es eine Konfiguration mit insmod > mdraid1x geben, richtig? Nein, in /boot/grub/grub.cfg. Und in /boot/grub/i386-pc sollte dann das Modul liegen (bzw. die Module).
Ich schicke Dir ersatzweise mal zwei Links: https://www.linux.com/learn/how-rescue-non-booting-grub-2-Linux https://www.gnu.org/software/grub/manual/grub/grub.html Ich geh' nämlich jetzt in die Heia. ;-)
np r. schrieb: > Timm R. schrieb: >> In /etc/grub.d müsste es eine Konfiguration mit insmod >> mdraid1x geben, richtig? > > Nein, in /boot/grub/grub.cfg. > Und in /boot/grub/i386-pc sollte dann das Modul liegen (bzw. die > Module). Hi, ok, in /boot/grub/grub.cfg ist insmod mdraid1x drin. vlg Timm
Timm R. schrieb: > ok, in /boot/grub/grub.cfg ist insmod mdraid1x drin Ähm, wie soll denn grub2 die Konfigurationsdatei und das Modul mdraid1x laden, wenn diese auf einer raid Partition sind, und es das mdraid1x modul noch nicht geladen hat (chicken egg Problem)? Ich vermute, grub hat beim installieren nicht korrekt erkannt, dass es das Modul mdraid1x als builtin benötigt. Bei einem Update sollte es eigentlich nicht zu einer neuinstallation kommen. Könntest du versuchen, dies beim grub-install zu ergänzen?
1 | grub-install --modules="mdraid1x ext2" /dev/whatever |
Ich habe das bisher erst bei EFI Systemen ausprobiert, ob die --modules Option auch auf nicht-EFI Systemen geht weiss ich nicht.
Daniel A. schrieb: > Timm R. schrieb: >> ok, in /boot/grub/grub.cfg ist insmod mdraid1x drin > > Ähm, wie soll denn grub2 die Konfigurationsdatei und das Modul mdraid1x > laden, wenn diese auf einer raid Partition sind, und es das mdraid1x > modul noch nicht geladen hat (chicken egg Problem)? > > Ich vermute, grub hat beim installieren nicht korrekt erkannt, dass es > das Modul mdraid1x als builtin benötigt. Bei einem Update sollte es > eigentlich nicht zu einer neuinstallation kommen. Könntest du versuchen, > dies beim grub-install zu ergänzen? > >
1 | grub-install --modules="mdraid1x ext2" /dev/whatever |
> > Ich habe das bisher erst bei EFI Systemen ausprobiert, ob die --modules > Option auch auf nicht-EFI Systemen geht weiss ich nicht. Hallo, ne hat nichts gebracht. vlg Timm
Hast Du schon versucht, die Schritte manuell in grub rescue auszuführen? Da musst Du doch dann eine Ansage bekommen, wo genau es hängt. Bei englischer Tatstaturbelegung sollte das '=' direkt neben backspace sein. Oder gib mal einfach 'set' ein in grub rescue, und 'ls' und berichte, was es sagt.
:
Bearbeitet durch User
Hi, np r. schrieb: > Hast Du schon versucht, die Schritte manuell in grub rescue auszuführen? > Da musst Du doch dann eine Ansage bekommen, wo genau es hängt. > > Bei englischer Tatstaturbelegung sollte das '=' direkt neben backspace > sein. > > Oder gib mal einfach 'set' ein in grub rescue, und 'ls' und berichte, > was es sagt. ja, das verf. = ist einfach nirgendwo. Ich bestelle für heue Nachmittag ein richtiges KVM, da habe ich das Problem mit dem Tastaturlayout nicht. Bin nur jetzt immer zu kurz im Büro dafür. Ich berichte! Danke! vlg Timm
Hallo, mea culpa! Einer der letzten Versuche muss geholfen haben. Vielleicht habe ich bei Remote Reset geschlampt oder bin mit den ganzen Fenstern durcheinander geraten. Grub geht jetzt! Ganz herzlichen Dank für eure Hilfe! Den Hiinweis mit dem manuellen Grub habe ich mir in mein Wiki kopiert, den kann ich bestimmt noch mal gebrauchen. Danke! Timm
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.