GRUB defekt

[Haley]

Hallo!
Wir haben einen Server bei server4you (Debian 6.0, RAID 1). Der Server startet nicht mehr.
Lt. server4you liegt ein GRUB-Problem vor. Es handelt sich um einen Root-Server, welcher von uns selbst installiert wurde (incl. Debian).
Leider ist unser Linux-Spezialist, der uns bei der Installation unterstützt hat, nicht merh verfügbar.
Seitens server4you gibt es keinen Support für diesen Server. Server4you bietet über ihr Powerpanel ein Recoverysystem an. Dieses ist gestartet und per putty erreichbar.
In die Wiki (https://wiki.debianforum.de/Grub_reparieren) habe ich geschaut. Dort sind jedoch verschiedene Varianten, welche für usn zutreffend ist, ist mir unklar.

Nach meinen Recherchen ist als erstes das Hauptdateisystem zu mounten mit mount /dev/sdaX /mnt (wie stelle ich fest, ob sda1, sda2,.. richtig ist?).
Nun ist zum gemounteten Dateisystem zu wecheln: chroot /mnt.
Mit grub-install /dev/sda kann GRUB neu installiert werden.
Mit update-grub werden die GRUB-Konfigurationsdateien neu geschrieben.

Ist das richtig so? Bzw. gibt es wegen RAID 1 etwas zu beachten?

Danke für Eure Antworten!

[niemand]

Wir haben einen Server bei server4you (Debian 6.0, RAID 1). Der Server startet nicht mehr.

Dann ist die Lösung einfach: Daten sichern und ’n aktuelles System installieren. Wir sind bei Debian 12, der Support für euer Squeeze ist vor ziemlich genau zehn Jahren ausgelaufen – seit acht Jahren gibt es auch für LTS keine Sicherheitsupdates mehr, während in der Zwischenzeit natürlich diverse Schwachstellen gefunden worden sind!

Ihr könntet auch überlegen, in dem Zuge vielleicht gleich auf einen Managed Server umzusteigen – da kümmert sich dann zumindest um das System jemand, der (hoffentlich) Ahnung davon hat.

[Haley]

Neuinstallation scheidet aus verschiedenen Gründen aus. Außerdem ist der Server für uns physisch nicht erreichbar.

[niemand]

Neuinstallation scheidet aus verschiedenen Gründen aus.

Dann scheidet meine Unterstützung aus einem Grund aus – ein solches System heute öffentlich zu betreiben, kann je nach Umständen ziemlich teuer für jeden Beteiligten werden; entsprechend will ich mich da nicht beteiligt sehen.

Außerdem ist der Server für uns physisch nicht erreichbar.

Und? Die Wenigsten, die einen Server bei irgendeinem Anbieter gemietet haben, haben physischen Zugriff auf die Maschine. Dafür ist das Control-Panel da.

[Draal]

Grub kann man mit einem Lifesystem wieder herstellen. Dazu muss man die Maschine damit booten, dann reicht ein Dreizeiler, ohne chroot. Wenn server4you so etwas per ssh zur Verfügung stellt habt ihr 'ne Möglichkeit. ansonsten dürfte das schwierig werden.
Habt ihr denn keine Backups von den Daten?

[grubenlicht]

Grub kann man mit einem Lifesystem wieder herstellen. Dazu muss man die Maschine damit booten, dann reicht ein Dreizeiler, ohne chroot.

ach ja, und wie genau machst du das ohne chroot?

[Haley]

@Draal: Hatte ich doch bereits geschrieben: Ich erreiche das Recovery-System über putty.
Lt. Support ist GRUB auf beiden HDDs des RAIDs installiert.

Was sind denn die drei Zeilen?

[Draal]

Code: Alles auswählen

fdisk -l
mount  -> /dev/sdaX/ /mnt
grub-install --root -directory=/mnt/mnt /dev/sdaX

X steht natürlich für die anzusprechende Platte.

[Haley]

Wie gesagt, es ist ein RAID1 System.
Ich habe bisher folgendes gemacht (md1 ist das RAID mit zwei HDDs)

mdadm --assemble --run /dev/md0
mdadm --assemble --run /dev/md1
mount /dev/md1 /mnt

Im Directory mnt findet sich jetzt das Filesystem des RAID.

Eine weitere Frage: Mit welchen Mitteln des Recoverystems kann ich Daten übers Netz sichern?

[grubenlicht]

...
grub-install --root -directory=/mnt/mnt /dev/sdaX[/code]
X steht natürlich für die anzusprechende Platte.

was ein Unsinn!
Für die Platte steht sda, das von dir angegebene X steht für eine Partition.
Der von dir angegebene Befehl installiert einen grub auf den PBR, wie soll der booten in einem MBR/MPT System? (in so einem "legacy" Bootverfahren kann ausschließlich vom MBR – sdy mit y=a/b/c/etc – gebootete werden!)
'
EDIT.: O.K., gestrichen
Btw., wenn ich so einen grub installiere, ist das ein sog. 'stand-alone' grub, den muß man dann komplett händisch einrichten (grub.cfg mit entsprechenden menuenty); der wird nicht automatisch bei updates – z.B. kernel – angepaßt! Und für RAID muß der dann auch zusätzlich in beiden Platten stehen.

[Draal]

was ein Unsinn!

Du hast recht. Sorry, aber derzeit ist mein Mittelfinger der linken Hand steif und entzündet. Richtig wäre:

Code: Alles auswählen

fdisk -l
mount -> dev/sdXX /mnt
grub-install --root-directory=/mnt /dev/sdX

Wie schon erwähnt ist X ein Platzhalter.
Hat schon viele male funktioniert, wenn ich auf meinem Dualboot ein neues Windows installiert habe.

[MSfree]

Hat schon viele male funktioniert, wenn ich auf meinem Dualboot ein neues Windows installiert habe.

Das funktioniert aber nur dann ohne chroot, wenn Rettungssystem und auf der Platte installiertes System dieselbe Grubversion verwenden.

Bei einem Rettungssystem, das heutzutage eher auf Bookworm aufsetzt, und einem uralten Debian 6 (Squeeze) ist das aber nicht der Fall. Da steht es Grub 2.06 zu Grub 1.96. Will man also Grub 1.96 restaurieren, was bei dem alten System durchaus sinnvoll wäre, kommt man um chroot nicht herum.

Naja, aber wer so sorglos ein 13 Jahre altes Debian betreibt, das seit 8 Jahren keine Updates mehr bekommt, wird sowieso demnächst ganz andere Probleme bekommen. Die Hardware und somit die Festplatten, sind auch 13 Jahre alt und quittieren irgendwann ihren Dienst. Backups sind wohl auch keine Vorhanden, dann sind die Daten halt weg.

[Draal]

Das wusste ich, bis dato, nicht, allerdings würde ich auch nie auf die Idee kommen ein Sytem derart zu verstauben lassen.
Danke.

[Haley]

Die Kritik am alten Systems ist natürlich völlig berechtigt.
Aber wie ich eingangs erwähnte, ist unser Linux-Spezialist schon vor langer Zeit abhanden gekommen.
Es wäre sehr wichtig, das System wenigstens noch kurz zum Laufen zu bekommen, damit wir mit Mitteln, welche wir kennen (SFTP, PHPAdmin etc.) Daten sichern können.
Wir wären also sehr dankbar, wenn sich jemand finden würde, der trotzdem bereit ist, weiter zu helfen.

Ausgehend von dem, was ich im letzten Beitrag (RAID-Dateisystem auf md1 steht unter mnt zur Verfügung), ist etwas hiervon richtig:

1)
# chroot /mnt
# grub-install /dev/sdX
# update-grub

2) habe ich hier im Forum gefunden (vorherige vollständige Entfernung von GRUB)
# chroot /mnt
# apt-get purge grub
# apt-get install grub
# update-grub
# grub-install <Boot-Device>

Mir ist jedoch unklar, welches das Bootdevice ist (sdX bzw. <Boot-Device), deshalb eine Anzeige von fdisk -l

Disk /dev/md0: 488.19 MiB, 511901696 bytes, 999808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Alignment offset: 3584 bytes
Disklabel type: dos
Disk identifier: 0x00000000


Disk /dev/sda: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD2002FAEX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

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


Disk /dev/sdb: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: TOSHIBA DT01ACA2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

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

Partition 1 does not start on physical sector boundary.

[MSfree]

1)
# chroot /mnt
# grub-install /dev/sdX
# update-grub

Das sollte eigentlich funktionieren.

Die Idee eines RAID-1 ist, daß das System auch dann bootet, wenn eine der beiden Platten ausfällt. In deinm Fall ist es also sinnvoll, grub sowohl auf /dev/sda als auch auf /dev/sdb zu installieren.

2) habe ich hier im Forum gefunden (vorherige vollständige Entfernung von GRUB)
# chroot /mnt
# apt-get purge grub
# apt-get install grub
# update-grub
# grub-install <Boot-Device>

Davon würde ich abraten. Die Repositories für Debian 6 gibt es nur noch unter archive.debian.org. Hier müßtest du also vorher die Datei /etc/apt/sources.list anpassen und die Paketbezugsquellen ändern. Sonst wird der install-Schritt scheitern.

Die letze und vorletzte Zeile der Befehlreihenfolge müssen außerdem in umgekehrter Reihenfolge stattfinden.

Mir ist jedoch unklar, welches das Bootdevice ist (sdX bzw. <Boot-Device),

Siehe mein Kommentar oben.

Ich halte es dennoch für sinnvoll, vorher erstmal alle Daten zu sichen. Installierte Programme und Bibliotheken sind keine Daten, deren Sicherung ist also, vor allem auch wegen ihres alten Softwarestandes ziemlich sinnlos.

Eines kann ich dir aber vorweg schon garantieren, der Umzug auf neuere Software wird steinig.

[Haley]

@MSfree, herzlichen Dank für deine Antwort.

Wie kann ich denn aus dem Recoverysystem Daten sichern?
Ich habe ein NAS, welches über DynDNS, SFTP erreichbar ist.

Aber im Recoverysystem ist außer SSH vieles deaktiviert:

PORT STATE SERVICE
21/tcp closed ftp
22/tcp open ssh
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
111/tcp closed rpcbind
143/tcp closed imap
443/tcp closed https
993/tcp closed imaps
995/tcp closed pop3s
2083/tcp closed radsec
2087/tcp closed eli
3389/tcp closed ms-wbt-server
5900/tcp closed vnc
8443/tcp closed https-alt

[MSfree]

Wie kann ich denn aus dem Recoverysystem Daten sichern?

Du könntest du das Dateisystem des Maschine ins Rettungssystem mounten, was du ja wohl sowieso schonmal gemacht hast.

Ich habe ein NAS, welches über DynDNS, SFTP erreichbar ist.

Ich würde umgekehrt vorgehen. Das Rettungssystem, das ja per SSH erreichbar ist, sollte auch über sshfs von einer Linuxkiste aus erreichbar und mountbar sein.

Hast du den Server erst einmal gemountet, kannst du Dateien nach herzenslust irgendwo hinschieben, auch auf dein NAS.

Selbstverständlich kann man sich auch mehrfach über SSH am Rettungssystem anmelden, also auch einmal direkt per SSH und ein zweites Mal über sshfs.

[Haley]

Mein NAS ist eines von Buffalo, da habe ich leider keinen root-Zugriff, nur über eine Windows-GUI.
Ist das Sichern auf meinen lokalen Windows-PC evtl. auch über putty und scp bzw. rsync möglich?

[MSfree]

Ist das Sichern auf meinen lokalen Windows-PC evtl. auch über putty und scp bzw. rsync möglich?

SCP (WinSCP) sollte gehen.

Mein NAS ist eines von Buffalo, da habe ich leider keinen root-Zugriff, nur über eine Windows-GUI.

Du könntest mit deinem Windows-PC über WinSCP eine Verbindung zu dem Server aufbauen und gleichzeitig das NAS mit deinem Windows-PC verbinden. Dann kannst du direkt vom Server auf das NAS kopieren.

[Haley]

@MSFree: Du bist ein Schatz
WinSCP kenne ich doch, hatte ich vor Jahren schon mal für unseren Server benutzt, aber völlig aus dem Auge verloren
Mit dem SCP-Protokoll funktioniert das auch.
Mit dem NAS bin ich unter Windows ohnehin über Netzlaufwerke verbunden.
Danke!!!

[Haley]

Ich hoffe, ich nerve nicht...
Ich habe mal den RAID-Status überprüft.

md1 ist ja das eigentliche Filesystem (ca. 1,8 TB) mit den Partitionen sda3 und sdb3.
Was ist denn das kleinere md0 (ca. 480 MB) mit den Partitionen sda1 und sdb1?

~# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md1 : active raid1 sda3[0] sdb3[1]
1860516800 blocks [2/2] [UU]
md0 : active raid1 sda1[0] sdb1[1]
499904 blocks [2/2] [UU]
unused devices: <none>

~# mdadm --detail /dev/md1
/dev/md1:
Version : 0.90
Creation Time : Wed Nov 12 08:51:13 2014
Raid Level : raid1
Array Size : 1860516800 (1774.33 GiB 1905.17 GB)
Used Dev Size : 1860516800 (1774.33 GiB 1905.17 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Tue Apr 16 15:56:42 2024
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
UUID : f8940aed:7e0ac080:44ae0f49:56644815 (local to host zulu981)
Events : 0.31410
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3


~# mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Wed Nov 12 08:50:55 2014
Raid Level : raid1
Array Size : 499904 (488.19 MiB 511.90 MB)
Used Dev Size : 499904 (488.19 MiB 511.90 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Wed Apr 10 16:36:00 2024
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
UUID : 0a057f66:a165e916:44ae0f49:56644815 (local to host zulu981)
Events : 0.420
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

[MSfree]

Was ist denn das kleinere md0 (ca. 480 MB) mit den Partitionen sda1 und sdb1?

Der Größe nach zu urteilen dürfte das die Partition sein, die unter Linux nach /boot gemountet wird. Dort befinden sich der Linuxkernel, die initiale RAM-Disk (initrd) und grub.

Wenn du /dev/md1 im Rettungssystem nach /mnt gemountet hast, kannst du nachsehen, was in der Datei /mnt/etc/fstab steht.

[Haley]

Danke, ja so ist es:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md1 / ext4 defaults,usrquota 0 1
/dev/md0 /boot ext2 defaults 0 2
/dev/sda2 none swap sw 0 0
/dev/sdb2 none swap sw 0 0

[Haley]

>Der Größe nach zu urteilen dürfte das die Partition sein, die unter Linux nach /boot gemountet wird. Dort befinden sich der Linuxkernel, >die initiale RAM-Disk (initrd) und grub.

GRUB sehe ich in der Partition nicht:

root@********:/boot# ls
System.map-5.4.44-gd config-5.4.44-gd vmlinuz-5.4.44-gd

[MSfree]

GRUB sehe ich in der Partition nicht:

root@********:/boot# ls
System.map-5.4.44-gd config-5.4.44-gd vmlinuz-5.4.44-gd

/boot dürfte die Bootpartition deines Rettungssystems sein. Wenn du die Bootpartition deines RAIDs ansehen willst, kannst du sie mit

Code: Alles auswählen

mount /dev/md1 /mnt/boot

mounten und dort dann unter /mnt/boot nachsehen.