Grub Bootmanager findet Partition nicht [gelöst]

[hatel]

Guten Abend,

ich versuchte auf einem älteren 32 Bit Acer-Laptop, dessen 300 GB Festplatte MBR-partitioniert ist und auf der drei primäre Partitionenen vorhanden sind (Debian 9 und 2x Windows XP) in der erweiterten Partition ein weiteres Debian-System zum Experimentieren zu erstellen. Dies machte ich mit einer Debian 8 Live CD für 32 Bit Systeme (i386). Mit dem Debian 8 Installer der CD erstellte ich in der erweiterten Partition eine weitere logische Partition, in die ich Debian 8 ohne Probleme installierte. Allerdings stellte ich danach fest, daß dieses neue Debian 8 System im Grub Boot Menü nicht auftaucht, weil es dafür in der Datei /boot/grub/grub.cfg keinen Eintrag gibt, auch nicht nach dem Ausführen von update-grub. Es ist grub 2.02~beta3-5+deb9u2 installiert. Die Ursache des fehlenden Eintrags war schnell klar, weil in meinem Debian 9 System das Paket os-prober nicht installiert war. Nach dessen Installation (Version 1.76~deb9u1) fand dann update-grub das neue Debian 8 System und fügte entsprechende Einträge in grub.cfg ein.
Danach tauchten im Boot-Menü die üblichen Einträge für Debian 8 und dessen erweiterte Optionen auf.
Allerdings läßt sich das System nicht starten und meldet statt dessen folgenden Fehler
Fehler: no such device: hier folgt eine UUID-Angabe.
Fehler: keine solche Partition
Unverständlicherweise stimmt aber die in der Fehlermeldung angegebene UUID mit der UUID der neuen Debian 8 Partition komplett überein, wie ich per blkid und per GParted überprüfte. Genau diese UUID steht auch in den Zeilen der grub.cfg von Abschnitt
### BEGIN /etc/grub.d/30_os-prober ###, die die Menüeinträge von Debian 8 betreffen.
Die vom grub Boot Loader nicht gefundene Debian 8 Partition entspricht dem Befund der grub Kommandozeile, die man per "c" erreicht.
Das Kommando ls listet dann nur die drei primären Partitionen auf (msdos1, msdos2, msdo4) und eine einzige Partition msdos5 der erweiterten Partition, die eine NTFS Daten Partition darstellt. Die neue Debian 8 Partition müßte als msdos6 erscheinen (so wie sie auch in grub.cfg auftaucht), aber sie tut es leider nicht.
Im Debian 9 System läßt sich diese Partition /dev/sda6 (msdos6) auch problemlos mounten, das Dateisystem ist also i.O.
Warum findet der Boot-Loader diese Partition nicht, obwohl sie von update-grub gefunden und auch korrekt in die grub.cfg geschrieben wird?
Einige Infos zur Lage der Partitionen:
Auf dem Laptop waren ursprünglich nur 2 Windows XP Systeme vorhanden. Dementsprechend beginnt die ersten Partition (XP) schon auf Sektor 63, so wie es ganz früher üblich war, d.h. nach dem MBR hat grub nur die 62 Sektoren 1-62 zur Verfügung. Bei aktuellen MBR-Partitionierungen fängt ja die erste Partition erst bei Sektor 2048 an. Allerdings funktionierte die Installation von Debian 8 (später Upgrade auf Debian 9) in der primärem Partition 4 ohne Probleme. Könnte es sein, daß mein Problem dadurch verursacht wird, daß das boot.img, core.img von grub in den 62 Sektoren zu wenig Platz hat, um ein bootfähiges System in der erweiterten Partition zu finden?

Vielen Dank im Voraus, Gruß hatel

[smutbert]

Willkommen im Debianforum!

Vermutlich stösst das BIOS da an eine Grenze, von denen es sehr viele gibt (32 GB, 64 GB und 128 GB waren glaube ich welche). grub kann nur auf den Teil der Festplatte zugreifen, der auch für das BIOS zugänglich ist.
Dann hilft es dafür zu sorgen, dass die grub-Konfiguration und -Module, der Kernel und die initrd in einem Dateisystem innerhalb der ersten xx GB liegen – genau zu dem Zweck hat man früher am Beginn von Festplatten eine vergleichweise kleine Bootpartition für /boot angelegt.

Zumindest ist das die einzige mögliche Erklärung, die mir auf Anhieb einfällt.

Zeig vielleicht der Übersicht halber eine Liste der beteiligten Partitionen und Dateisysteme her, zB die Ausgabe von

Code: Alles auswählen

lsblk -f

eventuell findet sich ja eine Partition, die man umwidmen könnte oder uns fällt etwas anderes sein.

[...]
Auf dem Laptop waren ursprünglich nur 2 Windows XP Systeme vorhanden. Dementsprechend beginnt die ersten Partition (XP) schon auf Sektor 63, so wie es ganz früher üblich war, d.h. nach dem MBR hat grub nur die 62 Sektoren 1-62 zur Verfügung. Bei aktuellen MBR-Partitionierungen fängt ja die erste Partition erst bei Sektor 2048 an. Allerdings funktionierte die Installation von Debian 8 (später Upgrade auf Debian 9) in der primärem Partition 4 ohne Probleme. Könnte es sein, daß mein Problem dadurch verursacht wird, daß das boot.img, core.img von grub in den 62 Sektoren zu wenig Platz hat, um ein bootfähiges System in der erweiterten Partition zu finden?
[...]

Das halte ich für ausgeschlossen. Sobald grub ein Menü anzeigt hat es ja bereits die Konfigurationsdatei und weitere Module aus dem Dateisystem nachgeladen und kann auf alle Partitionen und Dateisysteme der Datenträger, die über das BIOS zugänglich sind und für die es Treiber hat.

Konkret steht grub im MBR selbst immer genau gleich viel Platz zur Verfügung.
Was sich abhängig davon wo die erste Partition anfängt ändert ist ein weiterer freier Speicherbereich vor der ersten Partition und der ist für grub auch dann groß genug, wenn die erste Partition mit Sektor 63 beginnt.

[hatel]

Hallo smutbert,

danke für das freundliche Willkommen und die prompte Anwort, die mir schon neue Einsichten gebracht hat.
Dein Hinweis: "grub kann nur auf den Teil der Festplatte zugreifen, der auch für das BIOS zugänglich ist." scheint mir den Kern des Problems zu treffen.
Hier die Liste der Partitionen des Laptop:

arni@debian-acer:~$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0 squashfs /snap/core/10581
loop1 squashfs /snap/core/10576
sda
├─sda1 ntfs XP2A 12D67386066CA7A9
├─sda2 ntfs XP3B 16C85A4553C60671
├─sda3
├─sda4 ext4 debian8 d3bdba81-b3e7-4120-942a-434a6f7e9be9 /
├─sda5 ntfs DATEN A98A0FBFFDCC9CE9 /media/arni/DATEN
├─sda6 ext4 ae8d610b-903f-431b-88d3-35992752e2cd
└─sda7 swap ffb7e646-15de-45ba-8fa6-cf7f28a70dc0 [SWAP]
sr0

Die erste Partition in der erweiterten Partition (sda5), die der bootloader noch findet, beginnt bei Sektor 57368576 = 29.7 GB = 27.4 GiB.
Die nicht gefundene Partition sda6 beginnt aktuell bei Sektor 531234816 = 253.3 GiB.
Übrigens befindet sich zwischen sda5 und sda6 physikalisch (d.h. in der LBA-Reihenfolge) noch eine weitere Debian-Partition, mit der ich experimentieren wollte (Debian 10), und die ich aber aktuell deaktiviert habe (aus der extended boot record (EBR) Kette herausgenommen), weil ich glaubte, der Fehler läge an der Reihenfolge in der EBR-Kette, die nicht der physikalischen LBA-Sektor-Reihenfolge der Partitionen entspricht. Diese Vermutung hat sich aber nicht bestätigt.
Diese weitere (aktuell mit lsblk nicht sichtbare) Partition beginnt bei Sektor 453109760 = 216.1 GiB und wurde vom Bootloader auch nicht gefunden. Damit könnte die ominöse BIOS-Grenze z.B. bei 64 oder 128 GB liegen, denn das originale HDD, welches ich später durch ein 300 GB LW ersetzte, hatte nur 60 GB.
In der alten MSDOS-Zeit der 1990er Jahre habe ich mich auch mal kurzzeitig mit Assembler beschäftigt und mich mit den BIOS-Software-Interrupts wie z.B. INT13 oder INT10 befaßt. Vielleicht kriege ich nach so langer Zeit noch ein Code-Stückchen zusammen, das beim INT13 testet, bis zu welchem Sektor das Sektorlesen noch funktioniert.

Da ich annehme, daß Deine Vermutung hinsichtlich der BIOS-Grenze zutrifft (ganz sicher sollte man aber aus der Erfahrung mit oftmals sehr plausiblen aber dennoch falschen Annahmen nicht sein), bestünde eine Lösung des Problems also darin, für jedes weitere Debian-System in der erweiterten Partition (EP) am Anfang der EP jeweils eine kleine Partitionen für das /boot-Verzeichnis anzulegen, auf das der grub Bootloader noch Zugriff hat, oder?
Platz dafür wäre leicht zu schaffen, denn die 190 GB DATEN-Partition sda5 ist nur zu 50% belegt und kann leicht verkleinert und nach hinten geschoben werden.

Herzlichen Dank für die Hilfe und viele Grüße von hatel

[smutbert]

[...] bestünde eine Lösung des Problems also darin, für jedes weitere Debian-System in der erweiterten Partition (EP) am Anfang der EP jeweils eine kleine Partitionen für das /boot-Verzeichnis anzulegen, auf das der grub Bootloader noch Zugriff hat, oder?
[...]

Genau, wobei du durchaus eine Partition für mehrere Systeme nutzen könntest, zB eine Partition mit btrfs formatieren und für jedes System ein eigenes Subvolume für /boot anlegen.

Eine andere Variante wäre für jede Installation Verzeichnisse im Dateisystem der boot-Partition anzulegen, die in allen Systemen zB unter »/mnt/boot« mounten und mit bind-Mounts das jeweils richtige Verzeichnis unter /boot mounten.
Sollte grub wider Erwarten mit den bind-Mounts nicht zurechtkommen, könntest du grub in allen Systemen bis auf eines komplett deinstallieren und die Booteinträge für die anderen Systeme dann ohne Hilfe von os-prober selbst in die grub-Konfiguration schreiben.
(Ein Vorgehen in der Art ist zwar etwas komplizierter zum Einrichten hat allerdings auch Vorteile.)

[hatel]

Vielen Dank für die verschiedenen Vorschläge zur Lösung des Problems.
Wenn ich davon etwas erfolgreich getestet habe, gebe ich Bescheid.
Gruß, hatel

[MSfree]

Da ich annehme, daß Deine Vermutung hinsichtlich der BIOS-Grenze zutrifft

Hier mal ein Artikel, der die verschiedenen BIOS-Grenzen beschreibt:
https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html

Demnach war die 128GiB-Grenze (auch als 137GB-Grenze bezeichnet, weil 137GB=128GiB) die letzte wirklich kritische Grenze, aber das war 2001. Erst 2006 ist die erste 2.5"-Patte mit 160GB erschienen, deine 300er ist also nochmal neuer. Da du einen 32Bit-Rechner hast, dürfte es ein spätes Pentium-M Modell handeln, bereits 2007 ist der 64Bit Mobile Core2 erschienen. Zu der Zeit war aber das 128GiB-Problem längst aus allen BIOSen beseitigt.

So ganz möchte ich an die Theorie mif der BIOS-Begrenzung nicht glauben.

Um das zeitlich etwas näher einzugrenzen, wäre es sinnvoll zu erfahren, welche CPU in dem Rechner steckt. Mit der genauen Bezeichnung, kann man das Alter auf etwa 1 Jahr einordnen. Aber wie gesag, die Platte ist deutlich jünger als das BIOS-Limit aus dem Jahr 2001, das eigentlich spätestens 2002 in allen Rechner beseitigt hätte sein sollen.

[smutbert]

Hehe

[...] Damit könnte die ominöse BIOS-Grenze z.B. bei 64 oder 128 GB liegen, denn das originale HDD, welches ich später durch ein 300 GB LW ersetzte, hatte nur 60 GB.
[...]

[hatel]

Da mich das Problem mit der BIOS-Grenze sehr interessiert, und ich meine uralt Assemblerkenntnisse wieder auffrischen wollte, habe ich mich erst einmal diesem Problem gewidmet.
Außerdem hat MSfree heute ganz früh vermutet, daß es bei meinem Laptop gar nicht an der 128 GiB Grenze liegen würde.
Hier ein paar detaillierte Angaben zum Laptop (Kauf: 2004):
Modell: Acer Extensa 2902LMi
Prozessor: Intel Pentium M 715 (1.5 GHz, 32 Bit, 400 MHz FSB, 2 MB L2 cache)
BIOS: Inside Software SCU V1.30.00
dmidecode meldet: BIOS release date 05/21/2004

Nun zu meinen Ergebnissen zur Ermittlung der Plattenzugriffsgrenze meines BIOS, die - ich sag's gleich - existiert, so wie smutbert es vermutet hat.
Zur Ermittlung der Grenze habe ich ein Assembler-PGM geschrieben, dessen Objectcode (erstellt mit nasm) ich in den Bootrecord einer Floppy kopiert habe.
Der Laptop erlaubt Booten vom USB-Gerät, und ich hatte gerade mein altes Floppy-USB-LW zur Hand, hätte natürlich den Bootrecord gleich auf einen USB-Stick schreiben können.
Das Assembler-Programm (Codelänge < 512 Bytes, paßt also problemlos in den Bootrecord) nutzt im wesentlichen den Interrupt INT 13h, AH = 42h (Extended Read) der das LBA-Sektorlesen meines 320 GB-HDDs besorgt.
Es prüft das carry-Flag nach Ausführen von INT 13h (zeigte in jedem Falle keinen Lesefehler, ist also zum Ermitteln der Grenze nicht geeignet) und liest dann einen oder mehrere Sektoren in den freien RAM-Bereich oberhalb des Boot-Sektors (z.B. 8E00h). Danach erfolgt die Prüfung, ob am Ende des gelesenen Sektors (Positionen 1FEh und 1FFh) der Bootsektor-Kenner (BSK) vorhanden ist.
Dabei muß man natürlich vorher einen entsprechenden Sektor (alles 00 außer den letzten beiden Bytes 0xAA55 (BSK)) mit dd auf die zu testenden Sektoren der Platte schreiben.
Dazu hatte ich vorher mit GParted einen hinreichend großen freien Platz (der die absoluten LBA-Sektorpositionen 64 GiB und 128 GiB umfaßt) in der erweiterten Partition geschaffen (wo ja später die Partition mit den /boot-Verzeichnissen meiner zusätzlichen Debian-Systeme hinein soll).
Testergebnis:
- Der BSK wurde richtig gelesen natürlich beim MBR der Platte, beim ersten EBR (ext. boot rec.) der erweiterten Partition (liegt bei ca. 27 GiB), beim Sektor 64 GiB und beim Sektor 128 GiB -1.
- Beim Sektor 128 GiB (10000000h) gab es ein seltsam undefiniertes Ergebnis mit mehrfachen unsinnigen Ausgabe-Wiederholungen auf dem Laptop-Screen.
- Beim Sektor 128 GiB + 1 (10000001h) war die Ausgabe wieder ok, allerdings wurde kein BSK angezeigt. Das gleiche natürlich auch beim EBR der zweiten log. Partition innerhalb der erweiterten, auf dem sich das Debian 8 System befindet, welches vom Grub-Loader nicht mehr gefunden wurde.
Übrigens meldet das Kommandozeilen-PGM des Bootmanagers von U. Straub (https://www.boot-us.de/) (ausgeführt auf einer Bootdiskette) bei der Option report genau für die Sektorposition des EBR hinter der BIOS-LW-Zugriffsgrenze "kein Bootrecord-Kennung gefunden", obwohl der EBR an dieser Stelle natürlich existiert und i.O. ist.

Damit scheint mir die Existenz der BIOS-Grenze beim Sektor 128 GiB zumindest für das BIOS meines Laptops hinreichend bewiesen zu sein und die Vermutung von smutbert bestätigt, danke Dir.

Gruß, hatel

[hatel]

Inzwischen habe ich nun endlich ein Debian System zum Laufen gekriegt, welches sich in einem Plattenbereich befindet, der wegen der BIOS-Grenze von 128 GiB vom BIOS und damit auch vom Grub-Bootloader nicht erreichbar ist. Da ich zu den von smutbert vorgeschlagenen Lösungsvarianten ( a) btrfs-Dateisystem mit Subvolumes, b) nutzen von bind-mounts) noch keine eigene Erfahrung habe, habe ich zunächst kleine Brötchen gebacken und den alten Weg über das Anlegen einer Extra-Partition für das /boot-Verzeichnis im vom BIOS zugänglichen Plattenbereich gegangen.
Dies war jedoch auch mit Fallstricken versehen, weil die neue mit GParted erstellte ext4-Partition für /boot natürlich ganz ans Ende der EBR-Kette der Partitionen der erweiterten Partition gestellt wurde. Die drei Partitionen davor befanden sich jedoch hinter der 128 GiB-Grenze und so fand Grub trotzdem die /boot-Partition nicht, obwohl diese sich vor der Grenze befindet. Bei der Suche nach nutzbaren Partitionen geht also der Grub-Bootloader die EBR-Kette (extended boot record chain) der Reihe nach durch und wenn dabei einer der EBR-Sektoren im nicht zugänglichen Bereich liegt, bricht die weitere Suche an dieser Stelle ab, wie bei mir geschehen. Mit dem Grub-Kommandozeilenbefehl search -f filename kann man übrigens schnell herausfinden, welche Partitionen noch erreichbar sind.
Nachdem ich die EBR-Kette manuell (per dd) so geändert hatte, daß die notwendige /boot-Partition als Erste in der Kette auftaucht, funktionierte dann alles reibungslos.
Ich habe nur noch die grub.cfg Datei manuell angepaßt hinsichtlich der korrekten Partitionsnummern (msdosX für das Suchen des kernels mit BIOS-Befehlen, /dev/sdaY für das Suchen des root-Systems, wenn der kernel schon in Betrieb ist). Das hätte man aber auch automatisch per update-grub machen können.
Ich denke, daß damit mein Problem gelöst ist und würde es gerne als "gelöst" kennzeichnen, zumal es ja um eine Sache ging, die für aktuelle Rechner nicht mehr relevant ist.
Wie aber kennzeichne ich das Problem als gelöst? Bei anderen Foren gibt es da einen "Gelöst"-Button, den ich hier vergeblich suchte.
Gruß, hatel

[schwedenmann]

Hallo

Editier deinen 1.post und ändere die Überschrift in [gelöst]Überschrift sonst beibehalten

mfg
schwedenmann