Nach Installation: error:disk 'mduuid/-hexwert-' not found

[vdvogt]

Hallo,
ich brauche mal wieder Hilfe von Debian-Experten.

Ich habe Debian Stretch installiert. Soweit lief alles gut.
Als der Rechner aber nach der Installation rebootet hat, kam folgende Fehlermeldung:
error: disk 'mduuid/-----hexwert----' not found
Entering rescue mode...

Ich habe dann im Internet recherchiert und folgenden Loesungsvorschlag gefunden:

ls und set ausfuehren und dann

set root=(hd0,gptX)
set prefix=(hd0,gptX)/boot/grub

dann entweder
insmod normal oder
insmod normal.mod
(da wusste der Schreiber selbst nicht, was denn richtig ist)

Anschliessend

linux /vmlinuz-hexwert ro
initrd /initrd-hexwert
boot

Allerdings habe ich jetzt das Problem, herauszufinden, was ich fuer X setzen mus.

Ich habe auf den vier gleichen 3TB-Platten folgende Partitionierung vorgenommen (genau in dieser Reihenfolge und auf sda, sdb, sdc und sdd)

Partition 1: Anfang primaer 148,9MB biosgrub
Partition 2: Ende primaer 2GB Swap
Partition 3: Anfang primaer 3TB raid

Die 4 Platten sind als RAID5 konfiguriert, darauf ist ein ext4 mit /.

Vor den Partitionen hat Linux einen 1MB grossen Bereich und dahinter 466,4kB als freien Speicher gelassen.

Was muss ich jetzt fuer X einsetzen?

ls gibt mir folgendes aus:
(hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1) (hd2) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1) (hd3) (hd3,gpt3) (hd3,gpt2) (hd3,gpt1)

set gibt folgende Ausgabe:
cmdpath=(hd0)
perfix=(mduuid/---hexwert---)/boot/grub
root=mduuid/---hexwert---

beide hexwerte sind identisch.

Wie kann ich herausfinden, was ich fuer X einsetzen muss, welche Version des Befehls mit insmod ist richtig?
Ist dieser Leosungsweg ueberhaupt richtig?

Viele Gruesse
Veit

[rendegast]

Du könntest Dir die Dateisysteme ja ansehen, zBsp.

Code: Alles auswählen

grub> ls (hd0,gpt1)/boot/

Hier wären zBsp. die zu sehenden Kernel Erkennungsmerkmale.
Gegebenenfalls einen expliziten Marker setzen

Code: Alles auswählen

# touch /hallo-debian-testing

set gibt folgende Ausgabe:
cmdpath=(hd0)
perfix=(mduuid/---hexwert---)/boot/grub
root=mduuid/---hexwert---

Typo beim Post-Erstellen?

[vdvogt]

Hallo rendegast,
danke fuer den ls-Befehl!

Aber leider muss ich Dir sagen, dass ich den Rest Deiner Antwort nicht verstanden habe.

Hier wären zBsp. die zu sehenden Kernel Erkennungsmerkmale.
Gegebenenfalls einen expliziten Marker setzen

Code: Alles auswählen
# touch /hallo-debian-testing

Bitte erklaere mir das mal.
Was den Typo anbetrifft, so muss ich Dir Recht geben: es muss natuerlich "prefix" heissen.

Gruesse
Veit

[rendegast]

set root=(hd0,gptX)
set prefix=(hd0,gptX)/boot/grub
...
Wie kann ich herausfinden, was ich fuer X einsetzen muss,

Unabhängig von Deiner Situation.
Das richtige Dateisystem soll identifiziert werden.
Es wird die TAB-Completion der grub-Shell benutzt:
grub>ls ( TAB
Alle gerade verfügbaren grub-Blockdevices

Verfeinerung, zBsp.
grub>ls (hd TAB
grub>ls (hd0, TAB
Es werden die Partitionen und ihre Dateisystem-Eigenschaften aufgelistet.

grub>ls (hd0,msdos1)/ TAB
grub>ls (hd0,msdos1)/boot/
Es wird /boot/ und damit seine Kernel aufgelistet,
ein suse hat andere kernel als ein debian.

Dafür müssen die benötigten Dateisystemtreiber geladen sein,
zBsp. ext2 ist eigentlich immer in grubs core.img enthalten.
Im Normalfall werden für /boot benötigte von grub-install mit eingeschlossen.
Andere sind nicht nötig, können aber mit Zugriff auf /boot/grub/ nachgeladen werden.



In Deinem Fall bringen Dateisystemmodule erstmal nichts,
da wohl das raid zusammengebaut werden muß:

error: disk 'mduuid/-----hexwert----' not found

und das 'ls' gibt Dir nur gpt-Partitionen aus

Normalerweise sollte das nicht nötig sein,
da grub-install das Benötigte im core.img einschließen sollte.

Problem: Ohne das passende raid-Modul kommst Du nicht an das passende raid-Modul auf einem raid-/boot/grub heran.
(also eines der /boot/grub/i386-pc/*raid*)
-> Mit einem generischen grub starten, zBsp. von einer live-CD

Geladene Module anzeigen:

Code: Alles auswählen

Da die Liste meist länger ist:
grub> set pager=1

grub> lsmod

dann entweder
insmod normal oder
insmod normal.mod
(da wusste der Schreiber selbst nicht, was denn richtig ist)
...
Wie kann ich herausfinden, ... welche Version des Befehls mit insmod ist richtig?

Das geschilderte soll aus dem grub-Rescuemode
(nur das core.img gestartet)
das grub-Menü (aus /boot/grub/) aufbauen.
Im Normalfall findet das core.img einfach nur /boot nicht
(meist vertauschte Platten),
hat aber die Voraussetzungen zum Zugriff.
Nach der Nachhilfe über den richtigen Ort

Code: Alles auswählen

grub> set root=...
grub> set prefix=...

(Zur Identifizierung müssen und sollten die Mittel des core.img ausreichen)
kann das benötigte Modul nachgeladen und gestartet werden

Code: Alles auswählen

grub> insmod normal
grub> normal

Jetzt ist das Menü verfügbar und Spielereien mit
grub> linux ...
grub> initrd ...
sollten nicht mehr nötig sein, da ja der Editor 'e' des grub-Menü zur Verfügung steht.

[vdvogt]

Hallo rendegast,
ich komme heute erst dazu, Deine Ratschlaege auszuprobieren.
Aber leider funktioniert die TAB-Completion bei grub rescue nicht.

Da mir ja auch nicht das Grubmenu angezeigt wird, kann ich auch nicht e druecken, um in die grub-shell zu kommen.
Ich habe versucht, mit -h, help ...
eine Hilfe angezeigt zu bekommen, aber es kam nichts, nur unknown command.
Ich habe aber auch im Internet nichts dazu gefunden.

Ich habe dann einfach mal das eingegeben, was Du vorgeschlagen hast:

ls (hd0,3)/, ls (hd0,2)/, ls (hd0,1)/ , ls (hd1,3)/ usw...
Leider kam immer nur unknown filesystem.
Auch die Variante mit
ls (hd0,gpt3)/, ls (hd0,gpt2)/, ls (hd0,gpt1)/ , ls (hd1,gpt3)/ usw...
so wie es mir mit ls angezeigt wird, ergibt keine Aenderung.

Was schlaegst Du vor, wie kann ich hier weiter vorgehen?

Viele Gruesse
Veit

[rendegast]

Aua, ja, Du hast recht,
die netten Sachen von grub gibt es nicht im grub-rescuemode.
Nicht mal 'lsmod'.
In dem Zustand muß in gewissem Sinne "blind" gearbeitet werden.
(Hier funktioniert (bei einem einfachen ext-Dateisystem) aber zumindest Bsp.
grub> ls (hd1,msdos1)/
)



Da die raid nicht angeboten werden beim 'ls' fehlen wohl die raid-Module im core.img.

Dann brauchst Du zum Systemstart wohl einen generischen grub,
welcher Dir zumindest die Möglichkeit bietet, Module nachzuladen um das raid aufzuschließen
ZBsp. http://www.supergrubdisk.org/

[vdvogt]

Hallo rendegast,
OK.
Das lade ich mir dann mal runter und starte von der Live-CD.

Ich berichte dann mal wie's gelaufen ist.

Was muss ich denn noch nachladen, wenn ich es geschaft habe, den PC zum richtigen booten zu bewegen?

Gruesse
Veit

[rendegast]

Hier habe ich jetzt mal ein raid1-/boot/ erstellt.
'mdadm --create' warnt gleich, dieses raid enthält Metadaten und braucht (falls als /boot) speziellen geeigneten Bootloader
(sprich ein grub-core.img mit raid-Modulen),
andernfalls '--metadata=0.90'.
Ich verzichte auf '--metadata=...'.

Das raid formatiere ich und mounte nach /boot.
# grub-install ... für alle drei VM-Images.
# update-grub
Nochmal
# grub-install ... für alle drei VM-Images
(zur Sicherheit)

Reboote die VM -> grub ohne Menü (das raid-/boot war ja leer über das /boot-Verzeichnis gemountet)
Geladen ist grub-Modul mdraid1x.
root / prefix sind mduuid/.....
grub> ls (md/md-boot)/
....
(Paßt, das device habe ich aufgesetzt als /dev/md/md-boot)


Die beiden raid-Partitionen haben Partitionstyp 0xfd (linux-raid-auto),
als Partitionstyp 0x83 (linux) funktioniert es genauso.






Setze ich in der grub-shell des raid-/boot nun
grub> set root=hd2,msdos1
grub> set prefix=(hd2,msdos1)/boot/grub
grub> normal
so wird mir das grub-Menü des Linux-Systems der VM angezeigt.

[vdvogt]

Hallo rendegast,
entschuldige bitte, dass ich erst jetzt antworte, letzte Woche bin ich nicht dazu gekommen in dieser Sache was zu unternehmen.

Ich habe mir von supergrubdisk alles heruntergeladen, was ich gefunden hatte, weil ich nicht entscheiden konnte, was genau ich brauche.
Allerings sieht mir die Seite sehr suspekt aus; viel Werbung und irrefuehrende Links.
Gibt es da nicht eine serioese Seite fuer den Download?

Ausserdem stand mir zu dem Zeitpunkt der Downloads nur ein windoofrechner zur Verfuegung.
Damit habe ich die ISOs gebrannt.
Aber entweder brennt windoof die ISOs nicht richtig, oder meine Rechner weigern sich standhaft, von solchen Disks zu booten???

Ich werde demnaechst mal mit einem Linux-Rechner den Download wiederholen.
Inzwischen weiss ich auch, dass ich ein NON-EFI-Boot brauche.
Das MB kann zwar auch EFI, habe ich aber abgeschaltet.

Wahrscheinlich hast Du bezueglich meiner Partitionierung etwas falsch verstanden.
Nicht die grubboot-Partition ist im RAID, sondern nur die Systempartition.
Hier nochmal meine Partitionierung der vier HDDs:
(alle vier HDDs sind vom gleichen Typ; gleicher Hersteller, gleiche Baureihe, gleiche Groesse)

sda:
P1 am Anfang primaer 150MB grubboot; ausschliesslich auf sda
P2 am Ende primaer 2GB Swap
P3 am Anfang primaer 3TB raid

sdb, sdc und sdd:
P1 am Anfang primaer 150MB freier Speicher (Partition nicht benutzt), ist dazu da, damit die Partitionirung auf allen HDDs weitestgehend symmetrisch ist.

P2 am Ende primaer 2GB Swap
P3 am Anfang primaer 3TB raid

Auf dem RAID5 ist nur /root, sonst nichts.

Viele Gruesse
Veit

[rendegast]

sda:
P1 am Anfang primaer 150MB grubboot; ausschliesslich auf sda

Dann sollte auch nur sda1 als /boot gemountet sein.
Was imo diesem wiederspräche

set gibt folgende Ausgabe:
cmdpath=(hd0)
perfix=(mduuid/---hexwert---)/boot/grub
root=mduuid/---hexwert---

wonach /boot auf einem raid gesessen hätte.
Eventuell hast Du einen (gravierenden) Bug (im grub des Installers) gefunden?

Mal mit einem live-System booten und

Code: Alles auswählen

blkid  [ | sort -V ]

------------------------------------------------------

zu dem Zeitpunkt der Downloads nur ein windoofrechner windowsrechner zur Verfuegung.
Damit habe ich die ISOs gebrannt.
Aber entweder brennt windoof die ISOs nicht richtig, oder meine Rechner weigern sich standhaft, von solchen Disks zu booten???

eventuell das heruntergeladene Image nicht raw(!) gebrannt, sondern als Datei in einem CDROM-Dateisystem?

[vdvogt]

Hallo rendegast,
kann es sein, dass Debian 9 Stretch den Fehler im Installer hat?
Sollte ich vielleicht besser auf Debian 8 Jessie zurueckgreifen?

Ich versuchs mal.

Gruesse
Veit

[rendegast]

Ich würde halt ein grml booten, dann
'mount /dev/sdXY /boot'
dann
'grub-install --no-floppy /dev/sdX'

Weitere Aktionen aus dem dann wohl funktionsfähigen grub-Menü
und dem dann wohl bootbaren System.


Aber klar, solange noch keine weitere Aktion gelaufen ist
sollte eine Neuinstallation kein großes Ding sein.

[vdvogt]

Hallo rendegast,
ich habe heute die ganze Installation auf Deinen Rat hin nochmals mit Debian 8.4 gemacht.
Die Partitionierung ist die gleiche wie unter Stretch.
Partition 1: Anfang primaer 148,9MB biosgrub; nur auf sda; auf den anderen Platten freier Speicher, nicht benutze Partition
Partition 2: Ende primaer 2GB Swap
Partition 3: Anfang primaer 3TB raid

Aber wieder kommt am Schluss die gleiche Meldung wie bei der Installation mit Debian 9.
Grub kann dei biosgrub-Partition nicht finden und meldet:
error: disk 'mduuid/-----hexwert----' not found
obwohl die biosgrub-Partition ausschliesslich auf sda liegt; kein RAID.
Auf den anderen Platten hab ich an der gleichen Stelle einen gleich grossen freien Speicher, der nicht verwendet wird, um die Geometrie auf den Platten gleich zu halten.

Es schein wirklich so zu sein, wie Du vermutet hast, dass der Debian-Installer hier einen Fehler hat.

Versuch mal das auf einem anderen System nachzuvollziehen, um den Fehler zu finden.

Viele Gruesse
Veit

[rendegast]

Partition 1: Anfang primaer 148,9MB biosgrub; nur auf sda; auf den anderen Platten freier Speicher, nicht benutze Partition

Hier ist wohl etwas nicht ganz klar.
Eine Partition vom (gpt-)Typ

Code: Alles auswählen

  4 BIOS boot                      21686148-6449-6E6F-744E-656564454649

wird nur gebraucht, um zBsp. grub-Bootcode (core.img) unterzubringen, 1MB sollte dafür ausreichend sein.
Wird benötigt auf Rechnern im BIOS-Bootmodus mit einem GPT-Datenträger.
(<-> grub-pc, siehe auch wikipedia-en)

In (gpt-)Typ
1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B
wird EFI-Code untergebracht, normalerweise ein vfat-Dateisystem
(von windows normalerweise überaus großzügig mit 100MB angelegt).
Die Partition wird unterhalb von /boot/grub/ gemountet.
Wenn linux und windows auf eine EFI-System zugreifen,
sollte mal die Groß-Kleinschreibung der Verzeichnisse/Dateien kontrolliert werden, damit nicht Doppeldeutigkeiten bei den Pfaden entstehen.
(<-> grub-efi)

/boot/
/boot/grub/ liegen auf einem regulären Dateisystem.
Entweder auf einer separaten Partition oder innerhalb des /-Dateisystems.
Falls ein separates Dateisystem, sollte es die beabsichtigte Anzahl kernel/initrd fassen können (mittlerweile jeweils ~ 20MB).

[vdvogt]

Hallo rendegast,
wenn ich Deine Ausfuehrungen richtig verstehe, dann brauche ich gar keine biosgrub Partition.

Dann werde ich das morgen nochmals versuchen und nur folgende Partitionen anlegen:
Partition 1: Ende primaer 2GB Swap
Partition 2: Anfang primaer 3TB raid
auf allen vier Platten gleich.

Dann sollte Grub sich "freiwillig" in den MBR der ersten Platte (/dev/sda) installieren?

Der Installer fragt aber immer nach, wohin er installiert werden soll und gibt die vier Platten /dev/sda, b,c und d zur Auswahl.
Ich habe bisher immer /dev/sda gewaehlt.

Viele Gruesse
Veit

[vdvogt]

Hallo rendegast,
ich habs heute tatsaechlich geschafft, den Rechner ohne Fehler aufzusetzen!

Ich hatte mir gestern Abend mal die Debian-Installer-Doku durchgelesen.
Da wird im Zusammenhang mit RAID-Konstellationen eine /boot-Partition empfohlen.
Das habe ich heute dann mal ausprobiert.
Statt der biosgrup-Partition auf /dev/sda, habe ich eine /boot-Partition angelegt und diese mit ext4 formatiert.

Als es dann soweit war und die Installation von Grub dran war, habe ich dem Installer gesagt, dass er Grub in den MBR von /dev/sda installieren soll.
Das hat auch wunderbar funktioniert, ohne Fehlermeldungen!
Auch der Restart nach der Installation verlief einwandfrei und ich konnte in mein neues Debian 8.5 booten.

Kann es ein, dass Grub im Zusammenhang mit RAID-Konstellationen nicht mit einer biosgrub-Partition umgehen kann?
Diese ist ja meines Wissens RAW, also nicht formatiert.
Die /boot-Partition ist bei mir ext4.

Es kann aber auch daran liegen, dass die biosgrub-Partition auf meiner Platte nicht mehr wirklich RAW ist, denn ich habe die Platten ja schon bei den vielen Installationsversuchen beschrieben, so dass dort Daten in einem Filesystem liegen. Das koennte der Stoerfaktor sein.
Was meinst Du dazu?

Viele Gruesse
Veit