GRUB defekt

[MSfree]

Code: Alles auswählen

root@zulu981:/sys/module/md_mod/parameters# cat new_array
cat: new_array: Permission denied

Code: Alles auswählen

ls -l /sys/module/md_mod/parameters/new_array 
--w------- 1 root root 4096 Apr 19 18:46 /sys/module/md_mod/parameters/new_array

Die Datei kann man nicht lesen sondern nur beschreiben. Daß es da ein Permission denied gibt, wenn man den Inhalt mit cat ausgeben will, ist logisch und so gewollt.

[Haley]

Welchen Sinn macht es, wenn ein File nur geschrieben werden kann?
Alle anderen Files im Verzeichnis sind auch lesbar:

Code: Alles auswählen

root@zulu981:/sys/module/md_mod/parameters# ls -l
total 0
-rw------- 1 root root 4096 Apr 19 17:41 create_on_open
--w------- 1 root root 4096 Apr 19 17:41 new_array
-rw-r--r-- 1 root root 4096 Apr 19 17:41 start_dirty_degraded
-rw------- 1 root root 4096 Apr 19 17:41 start_ro

[MSfree]

Welchen Sinn macht es, wenn ein File nur geschrieben werden kann?

Bei Dateien, die nur Daten entgegen nehmen sollen und nicht wieder lesbar sein sollen, ergibt es durchaus Sinn, daß sie nur schreibbar sind. Pipes bestehen z.B. aus zwei Dateihandles, von denen eine nur schreibbar und der andere nur lesbar ist. Alles, was man in die Nurschreibdatei reinschreibt, kommt dann aus der Nurlesedatei wieder raus.

Im Fall von new_array kann man dort den Namen reinschreiben, den ein neu anzulegendes md haben soll. Daraufhin legt der Kernel unter /sys/block/ das neue md-Device mit dem vorher geschriebenen Namen an. Ein Lesen ist dann nicht mehr nötig, der Name wurde ja schon konsumiert.

Normalerweise braucht man sich aber nicht mit den rohen Datein in diesem Verzeichnis zu befassen, das macht letztlich mdadm.

[Haley]

OK, danke für die Erläuterung.

[Haley]

Bzgl. der Warnung beim Starten von md0 habe ich recherchiert.
Diese Meldung kommt z.B. dann, wenn mdadm älter ist als der Linux-Kernel.

In diesem Fall fällt mdadm in den alten Knotenerstellungsmodus zurück, der wie vorgesehen funktioniert, so dass er trotz der Fehlermeldung erfolgreich ist. Sie erhalten am Ende immer noch Ihr Array und alles ist gut

Dass dies wohl richtig ist, ergibt sich auch daraus, dass der RAID-Status fehlerfrei ist.
Also hat der Speicherschutzfehler damit wohl nichts zu zu tun.

[MSfree]

Ich gehe inzwischen auch davon aus, daß es irgendwie mit der Kernelversion zusammenhängen muß, daß du Crashes bekommst.

Der Kernel des Rettungssystems könnte deutlich neuer sein als der Kernel von Debian 6. Möglicherweise kommt das alte mdadm einfach nicht mehr mit der Kernelschnittstelle des Rettungskernels zurecht.

Welche Kernelversion hat denn das Rettungssystem?

Code: Alles auswählen

uname -a

?

[Haley]

Linux zulu981 5.4.44-gd #1 SMP Mon Jul 6 14:22:56 CEST 2020 x86_64 GNU/Linux

Ich habe nochmal getestet, wann genau mdadm -D /dev/md0 auf Segmentation fault läuft.
Das ist sofort nach chroot /mnt, also auch bevor grub-install versucht wird.

Die Kernelversion des Debian-Originalsystems ist von 2014, als der Server installiert wurde.

[Haley]

Möglicherweise kommt das alte mdadm einfach nicht mehr mit der Kernelschnittstelle des Rettungskernels zurecht.

Im Recoverysystem wird doch aber das mdadm des Recovery Systems benutzt oder?

[MSfree]

Linux zulu981 5.4.44-gd #1 SMP Mon Jul 6 14:22:56 CEST 2020 x86_64 GNU/Linux

Siehe hier: https://de.wikipedia.org/wiki/Debian#Versionsgeschichte
Debian 6 kam mit Kernel 2.6.32.

Das ist sofort nach chroot /mnt, also auch bevor grub-install versucht wird.

Das Problem hier ist, daß nach dem chroot mdadm von Debian 6 verwendet wird, das vermutlich nicht mehr kompatibel mit dem Kernel 5.4.44 des Rettungssystems ist.

[Haley]

Das leuchtet ein.
Die Frage ist, wieso wird während grub-install überhaupt mdadm angesprochen? Und zunächst jedenfalls nur mdadm -D.
Lässt sich das ggf. umgehen?

Ich überprüfe mal die mdadm-Versionen:

Rettungssystem: v4.1 - 2018-10-01
Debian: v3.2.5 - 18th May 2012

[Haley]

Ich hätte noch eine Idee...
Es ist doch möglich, dass GRUB garnicht neu installiert werden muss, weil ggf. nur die Konfiguration korrupt ist.
Dann könnte doch grub-install übersprungen und gleich update-grub ausgeführt werden.
Kann dabei etwas kaputt gehen?
Voraussetzung ist natürlich, dass update-grub nicht auch mdadm bemüht.

[Haley]

Weitere Ideen (sorry, wenn die verrückt sind):

Wenn ich mdadm aus /sbin des Rettungssystem nach /mnt/sbin kopiere (voher die dortige mdadm natürlich umbenennen) und erst danach chroot ausführe, kann das funktionieren?

Oder ich mounte das komplette Verzeichnis /sbin nach /mnt/sbin...

[MSfree]

Dann könnte doch grub-install übersprungen und gleich update-grub ausgeführt werden.
Kann dabei etwas kaputt gehen?

update-grub erzeugt eigetlich nur eine Datei, die die Menüeinträge für das grub-Menü beinhaltet. In alten grub-Versionen war das, wenn ich mich richtig erinnere, die Datei /etc/grub/menu.cfg. Wenn du die vorher wegsicherst, kann nicht mehr viel schiefgehen.

Wenn ich mdadm aus /sbin des Rettungssystem nach /mnt/sbin kopiere (voher die dortige mdadm natürlich umbenennen) und erst danach chroot ausführe, kann das funktionieren?

Ich glaube nicht, daß du damit viel Glück haben wirst. grub-install ist kein statisch gelinktes Programm und hängt auf meinem Debian 13 von linux-vdso.so., liblzma.so.5, libdevmapper.so.1.02.1, libefivar.so.1, libefiboot.so.1, libc.so.6, libselinux.so.1, libudev.so.1, libm.so.6, ld-linux-x86-64.so.2, libpcre2-8.so.0 und libcap.so.2 ab.

Die Bibliotheksversionen, von denen das grub-install deines Rettungssystems abhängt, sind auf jeden Fall neuer als die, die im Debian 6 installiert sind. Möglicherweise fehlt sogar die ein oder andere Bibliothek. Ich glaube nicht, daß das neuere grub-install überhaupt in der chroot-Umgebung startet.

[Haley]

Die Bibliotheksversionen, von denen das grub-install deines Rettungssystems abhängt

Sorry, aber ich verstehe jetzt etwas nicht.
Das Problem ist ja anscheinend, dass im chroot-Modus mdadm auf Fehler läuft, weil mdadm von Debian 6 gestartet wird, was inkompatibel mit dem Linux-Kernel des Rettungssystems ist.
Wieso sollte dann im chroot-Modus grub-install des Rettungssystem gestartet werden?
Ich denke auch, dass es im Rettungsystem gar kein grub gibt, denn dort kommt bei grub --help: grub not found.

[Haley]

In alten grub-Versionen war das, wenn ich mich richtig erinnere, die Datei /etc/grub/menu.cfg.

Ist dort nicht zu finden. Kann es sein, dass es statt dessen die Datei menu.lst in /boot/grub/ ist?
In dieser steht u.a.:

Code: Alles auswählen

title		Debian GNU/Linux, kernel 3.2.0-6-amd64
root		(hd0,0)
kernel		/vmlinuz-3.2.0-6-amd64 root=/dev/md1 ro 
initrd		/initrd.img-3.2.0-6-amd64

title		Debian GNU/Linux, kernel 3.2.0-6-amd64 (single-user mode)
root		(hd0,0)
kernel		/vmlinuz-3.2.0-6-amd64 root=/dev/md1 ro single
initrd		/initrd.img-3.2.0-6-amd64

title		Debian GNU/Linux, kernel 3.2.0-4-amd64
root		(hd0,0)
kernel		/vmlinuz-3.2.0-4-amd64 root=/dev/md1 ro 
initrd		/initrd.img-3.2.0-4-amd64

title		Debian GNU/Linux, kernel 3.2.0-4-amd64 (single-user mode)
root		(hd0,0)
kernel		/vmlinuz-3.2.0-4-amd64 root=/dev/md1 ro single
initrd		/initrd.img-3.2.0-4-amd64

[Haley]

Korrektur:

Ich hatte die Debian-Version 6 vor kurzem aus Plesk entnommen, als der Server noch lief.
lsb_release –d zeigt mir aber Version 7.11 also Kernel 3.2.41 (LTS) an.
Ändert aber sicher nicht viel.

[MSfree]

Wieso sollte dann im chroot-Modus grub-install des Rettungssystem gestartet werden?

Ja sorry, falscher Film. Mit mdadm verhält es sich aber ähnlich, da wird ein mdadm aus dem Rettungssystem nicht kompatibel mit dem alten Bibliotheken von Linux 6 sein. Wenn du also mdadm aus dem Rettungssystem in das alte System kopierst, wird es mit großer Wahrscheinlichkeit nicht laufen. Das gute ist, daß es so auch nicht beschädigen kann.

Ich hatte die Debian-Version 6 vor kurzem aus Plesk entnommen, als der Server noch lief.
lsb_release –d zeigt mir aber Version 7.11 also Kernel 3.2.41 (LTS) an.

Na hoffentlich ist das nicht der Grund für dein Problem. Kommst du eigentlich irgendwie in das Grubmenu, so daß du dort einen älteren Kernel auswählen kannst, der zu Debian 6 paßt.

[Haley]

In das Grub-Menü kommt kann man doch nur kommen, wenn man vor der Konsole ist oder?
Der Server ist in Strasbourg.
Beim Starten des Recovery-Systems gibt es doch kein Bootmenü.

Ist denn die Datei menu.lst in /boot/grub/ die richtige (anstatt menu.cfg, siehe oben)?

[MSfree]

In das Grub-Menü kommt kann man doch nur kommen, wenn man vor der Konsole ist oder?

Jein. Es gibt KVM-over-IP-Lösungen, mit denen man die Konsole über das Netzwerk/Internet transportieren kann. Ob dein Provider sowas anbietet, weiß ich halt nicht.

Ich habe aber oben deine menu.lst (ja, das ist die Datei, die update-grub erzeugt) gesehen. Dort steht kein 2.6er Kernel mehr drin. Es wird wohl auch keinen mehr auf deinen Festplatten geben.

[Haley]

@MSFree: Ich muss mich bei dir entschuldigen.
Unsere Diskussion seit "Segmentation Fault" hätten wir uns schenken können.
Ich muss wohl beim ersten Versuch etwas falsch gemacht haben, ich vermute ich hatte proc nicht gemountet.
Warum auch immer, ich habe die ganze Prozedur sicherheitshalber wiederholt und siehe da, der Server bootet wieder normal.

Hier noch einmal die komplette, richtige Befehlsfolge:

Code: Alles auswählen

mdadm --assemble --run /dev/md0
mdadm --assemble --run /dev/md1
mount /dev/md1 /mnt
mount /dev/md0 /mnt/boot
mount --bind /dev /mnt/dev		           	        
mount --bind /dev/pts /mnt/dev/pts                   
mount --bind /sys /mnt/sys                                    
mount --bind /proc /mnt/proc
chroot /mnt
grub-install /dev/sda
grub-install /dev/sdb
update-grub

@MSFree: Ganz herzlichen Dank für deine geduldige Unterstützung, ohne diese hätte ich es wohl nicht hinbekommen.

[juhu]

Mir ist aufgefallen.........

Device Boot Start End Sectors Size Id Type
/dev/sdb1 1 1000000 1000000 488.3M fd Linux raid autodetect
/dev/sdb2 1001472 4999167 3997696 1.9G 82 Linux swap / Solaris
/dev/sdb3 4999168 3726032895 3721033728 1.8T fd Linux raid autodetect

das auf der sdb Platte das Sternchen fehlt. Der Stern sagt dem BIOS dass das eine Boot-Partition ist.
Ich bin mir nicht sicher, aber müssten nicht beide Platten als bootable gekennzeichnet sein, sonst funktionierte RAID 1 im Falle eines Falles nicht.
Hat da jemand noch nähere Infos?

Denn wenn ich richtig liege würde es reichen sdb1 einfach als bootable zu markieren und noch einmal neu zu starten.

[MSfree]

Warum auch immer, ich habe die ganze Prozedur sicherheitshalber wiederholt und siehe da, der Server bootet wieder normal.

Herlichen Gückwunsch.

Jetzt solltest du dich aber ans Werk machen und die Daten exportieren, um einen Server mit einem aktuellen Betriebssystem aufsetzen zu können. So alte Linuxe haben Sicherheitslücken, die nie geflickt werden und als Einfallstor für Angreifer gelten müssen. Die Hardware ist ebenfalls alt und kann jederzeit ausfallen. Wenn da nur ein Elko auf dem Mainboard hochgeht, kommst du an nichts mehr ran, die Kiste steht halt nicht bei dir und du kannst nichtmal die noch intakten Platten an anderer Hardware anschließen.

[juhu]

Fang sofort an, wenn du die Daten noch willst. Das Wetter ist nicht besonders.
1 TB wird ein bisschen dauern und nimm eine Kabelverbindung ins Internet.
Kabel sind normalerweise stabiler als WLAN oder ähnliches.
Viel Glück