• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] openSUSE Leap 42.3 bootet nicht

Hazel

Hacker
Hallo,

ich komme mit einer Neuinstallation einer Leap 42.3 nicht vorwärts.

Der PC, um den es geht
-- läuft unter BIOS
-- arbeitet nach MBR
-- hat zwei Festplatten, die wie folgt aufgebaut sind.

Code:
linux:~ # fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
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: 0x241c6624

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1  *        12678    4209029    4196352     2G 27 Hidden NTFS WinRE
/dev/sda2         4212332   88100459   83888128    40G  7 HPFS/NTFS/exFAT
/dev/sda3        88112467  119571794   31459328    15G  7 HPFS/NTFS/exFAT
/dev/sda4       119571856 1953520064 1833948209 874.5G  f W95 Ext'd (LBA)
/dev/sda5       119571858  123780824    4208967     2G 82 Linux swap / Solaris
/dev/sda6       123780888  148938614   25157727    12G 83 Linux
/dev/sda7       148938678  161517509   12578832     6G 83 Linux
/dev/sda8       161517573  186675299   25157727    12G 83 Linux
/dev/sda9       186675363  199254194   12578832     6G 83 Linux
/dev/sda10      199254258  224411984   25157727    12G 83 Linux
/dev/sda11      224412048  236990879   12578832     6G 83 Linux
/dev/sda12      236990943 1953520064 1716529122 818.5G 83 Linux


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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
Disklabel type: dos
Disk identifier: 0x00072ddc

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sdb1            2048   16771071   16769024     8G 82 Linux swap / Solaris
/dev/sdb2  *     16771072  100646911   83875840    40G 83 Linux
/dev/sdb3       100646912  117420031   16773120     8G 83 Linux
/dev/sdb4       117420032 1953523711 1836103680 875.5G  f W95 Ext'd (LBA)
/dev/sdb5       117422080  201310207   83888128    40G 83 Linux
/dev/sdb6       201312256  218083327   16771072     8G 83 Linux

linux:~ #

Auf den beiden primären Partitionen /dev/sdb2 und /dev/sdb3 läuft bereits eine Leap 42.2. Diese kann ich natürlich als Referenz hernehmen. Z.B. sagt dort YaST in seiner Bootloader-Konfiguration, dass die Festplatten-Reihenfolge laute: /dev/sda, /dev/sdb. Das entspricht dem, was das BIOS gespeichert hat (ohne dass ich in diesem Punkt jemals Hand angelegt hätte).

Die vorgesehene Neuinstallation der 42.3 soll nach /dev/sdb5 für / und /dev/sdb6 für /home. Die entsprechenden Partitionen wurden als logische Partitionen eingerichtet und mit EXT4 formatiert. Die Installation dort hinein läuft auch ohne irgendwelche Fehlermeldungen durch. GRUB2 wurde in den MBR installiert, wie es das Installationsprogramm vorgeschlagen hatte. Dass alternativ auch eine Installation in das Wurzelverzeichnis zur Auswahl stand, hat mich ein wenig irritiert, da es sich doch um eine logische Partition handelt.

Auf alle Fälle kam die 42.3 trotz wiederholter (scheinbar erfolgreicher) Installationen niemals ins Laufen. Es erscheint immer wieder das Bootmenü der 42.2, worin die frischinstallierte 42.3 nicht auftaucht.

Bei mehrfachen Installationsversuchen ist mir ausgefallen, dass bei der Installationszusammenfassung der 42.3 unter "Systemstart" als Festplatten-Reihenfolge steht: /dev/sdb, /dev/sda. Lasse ich es dabei und installiere den GRUB2 in den MBR, dann entsteht der erwähnte Effekt, dass die 42.3 zwar installiert wird, aber nicht auf die Beine kommt.

Versuche ich stattdessen die Festplatten-Reihenfolge umzudrehen, also /dev/sda, /dev/sbd vorzugeben, dann meckert bereits die Installationsroutine. Es gibt zwei Varianten der Fehlermeldung:
Das Installationsprogramm ändert den MBR der Festplatte nicht. Falls der MBR noch keinen Bootcode enthält, kann das BIOS nicht von dieser Festplatte gebootet werden.
Warnung: Kein Speicherort für Bootloader Stufe 1 ausgewählt. Wenn Sie nicht über Expertenkenntnisse verfügen, wählen Sie den obigen Speicherort aus.

Fazit: Ich muss wohl oder übel, um die Installation fortzusetzen, bei der vorgeschlagenen Festplatten-Reihenfolge bleiben, obwohl dadurch kein bootfähiges System zustande kommt.

Noch eine Beobachtung: Unter Systemstart > Bootloader-Optionen wird bei der 42.3 grundsätzlich kein Standard-Bootabschnitt angeboten, unabhängig von der gewählten Festplatten-Reihenfolge. Das Auswahlfeld ist immer leer.

Langer Rede kurzer Sinn: Hat jemand einen Tipp, wie ich eine bootfähige Leap 42.3 in die dafür vorgesehenen logischen Partitionen auf der zweiten Festplatte /dev/sdb kriege?

Danke
Hazel
 
Hast du in der 42.2 auch eingestellt, das der Bootloader auch andere Betriebsysteme berücksichtigt?
Stichwort os_prober?
 
OP
H

Hazel

Hacker
Danke, Sauerland

Ja, die 42.2 hat unter YaST, Bootloader-Optionen: [X] Fremdes OS testen.

Nützt aber leider nichts. Der GRUB2 der 42.2 sieht die frisch installierte 42.3 nicht.

Die anderen, teilweise schon recht alten SUSE-Installationen findet er dagegen alle.

Ich sollte vielleicht noch erwähnen, dass ich auf einem Notebook (mit einer SSD) eine 42.3-Installation habe, die nie irgendwelchen Ärger gemacht hat.

Grüße
Hazel
 
Hazel schrieb:
Die vorgesehene Neuinstallation der 42.3 soll nach /dev/sdb5 für / und /dev/sdb6 für /home. Die entsprechenden Partitionen wurden als logische Partitionen eingerichtet und mit EXT4 formatiert. Die Installation dort hinein läuft auch ohne irgendwelche Fehlermeldungen durch. GRUB2 wurde in den MBR installiert, wie es das Installationsprogramm vorgeschlagen hatte. Dass alternativ auch eine Installation in das Wurzelverzeichnis zur Auswahl stand, hat mich ein wenig irritiert, da es sich doch um eine logische Partition handelt.

Auf alle Fälle kam die 42.3 trotz wiederholter (scheinbar erfolgreicher) Installationen niemals ins Laufen. Es erscheint immer wieder das Bootmenü der 42.2, worin die frischinstallierte 42.3 nicht auftaucht.
Ich bin mir nicht sicher aber ich hätte versucht die sdb4 als aktive Partition zu markieren. Im Moment ist die sdb2 als aktive.
Wie das geht kannst hier nachlesen.

EDIT: Das könnte für dich interessant sein Vor Allem der Satz: Ein "generischer" Boot-Code im MBR sucht eine aktive (primäre bzw. erweiterte) Partition, um den in deren Boot-Sektor enthaltenen Boot-Code auszuführen, d. h. ohne aktive Partition startet nichts.
 

josef-wien

Ultimate Guru
Als erste Idee könnte 42.3 den Bootloader in den MBR der zweiten Platte installiert haben. Wie sieht es aus, wenn Du im BIOS die zweite Platte als Boot-Platte definierst?



Hazel schrieb:
Ja, die 42.2 hat unter YaST, Bootloader-Optionen: [X] Fremdes OS testen.
Hast Du nach der Installation von 42.3 den Bootloader in 42.2 neu installiert, damit 42.3 erkannt werden kann?

Falls beide Möglichkeiten nicht den gewünschten Erfolg bringen: Wie sieht das Verzeichnis /boot auf der Systempartition von 42.3 (/dev/sdb5) aus? Kannst Du 42.3 über die Super Grub2 Disk starten?
 
OP
H

Hazel

Hacker
Hallo

Danke für Eure Vorschläge und Rückfragen. Ich fange mal mit Josefs Punkten an.


josef-wien schrieb:
Wie sieht es aus, wenn Du im BIOS die zweite Platte als Boot-Platte definierst?
Das muss ich noch testen. Ehrlich gesagt, kann ich mich nicht erinnern, jemals im BIOS etwas verstellt zu haben (bis auf die Prioritätenliste der Bootmedien). Da es sich um einen Familien-PC handelt, bin ich in solchen Dingen höllisch vorsichtig. Analoges gilt für den Umgang mit der super_grub2_disk. Da wage ich mich nur nach entsprechender Vorbereitung (und einigen Tassen Kaffee) heran.

Egal wie der Test ausgeht: Es bleibt dann immer noch die Frage offen, weshalb der Installer für den GRUB in der 42.2 die Plattenreihenfolge /sda, /sdb einstellt, sein Gegenstück in der 42.3 aber auf /sdb, /sda besteht (und dann trotzdem nichts bootbares zustandebringt).

OK, das bringt mich jetzt auf die Idee, eine Dummy-Installation der 42.2 in die beiden logischen Partitionen auf der /dev/sdb, die eigentlich für die 42.3 vorgesehen sind, zu machen. Noch ein Test, noch mehr Kaffee...


josef-wien schrieb:
Hast Du nach der Installation von 42.3 den Bootloader in 42.2 neu installiert, damit 42.3 erkannt werden kann?
Ja. Und der bizarre Effekt dabei ist der, dass im YaST der 42.2 bei der Auswahl der bootbaren Systeme die 42.3 erwähnt wird, sogar als Standard definiert werden kann, beim nächsten Hochfahren aber nicht mehr auftaucht.

Die Neuinstallation des GRUB2 ist aber tatsächlich durchgelaufen, wie ich an den Änderungszeitpunkten einiger Dateien unter /boot/grub2 sehen kann.

Ergänzung: Der Befehl 'cat /boot/grub2/grub.cfg | grep 42.3' zeigt, dass in der Tat Einträge zur Leap 42.3 erstellt wurden. Warum sie im Startmenü nicht angezeigt werden, muss ich noch verstehen.


josef-wien schrieb:
Wie sieht das Verzeichnis /boot auf der Systempartition von 42.3 (/dev/sdb5) aus?
Code:
lothar@linux:/42p3/boot> ls -laF
insgesamt 26900
drwxr-xr-x  3 root root     4096  4. Nov 11:17 ./
drwxr-xr-x 22 root root     4096  4. Nov 10:56 ../
-rw-r--r--  1 root root      512  4. Nov 11:16 backup_mbr
-rw-r--r--  1 root root     1725 17. Mai 17:41 boot.readme
-rw-r--r--  1 root root   179969 16. Jul 11:42 config-4.4.76-1-default
-rw-r--r--  1 root root        0  4. Nov 11:05 do_purge_kernels
drwxr-xr-x  7 root root     4096  4. Nov 11:17 grub2/
lrwxrwxrwx  1 root root       23  4. Nov 11:05 initrd -> initrd-4.4.76-1-default
-rw-------  1 root root 10183268  4. Nov 11:17 initrd-4.4.76-1-default
-rw-r--r--  1 root root   502272  4. Nov 11:01 message
-rw-r--r--  1 root root   340794 16. Jul 12:31 symvers-4.4.76-1-default.gz
-rw-r--r--  1 root root      377 16. Jul 12:31 sysctl.conf-4.4.76-1-default
-rw-r--r--  1 root root  3266760 16. Jul 12:27 System.map-4.4.76-1-default
-rw-r--r--  1 root root  7022105 16. Jul 12:33 vmlinux-4.4.76-1-default.gz
lrwxrwxrwx  1 root root       24  4. Nov 11:05 vmlinuz -> vmlinuz-4.4.76-1-default
-rw-r--r--  1 root root  6006440 16. Jul 13:04 vmlinuz-4.4.76-1-default
-rw-r--r--  1 root root       65 16. Jul 13:04 .vmlinuz-4.4.76-1-default.hmac
lothar@linux:/42p3/boot>

Das war der aktuelle Zwischenstand. Ich melde mich wieder.

Hazel
 

dzug

Guru
Hei.
Ich mache es immer so:
Grub2 welcher das betreffende linux nicht Anzeigt einfach Updaten.
Pc rebooten.
Dann zeigt er mir auch das neue linux an.
Gruss dzug.
 
OP
H

Hazel

Hacker
Danke, dzug

Dein Konzept funktioniert! Ich dachte, ich hätte es bereits früher so umgesetzt (siehe oben), das war aber nicht korrekt.

Aber der Reihe nach:
  1. Der GRUB, dem ich beibringen wollte, alle vorhandenen Systeme zum Booten anzubieten, war der aus der aktuell laufenden openSUSE Leap 42.2. Er hat die Installation der 42.3 erkannt und seine Konfigurationsdaten in den MBR der zweiten Festplatte geschrieben.
  2. Derselbe GRUB hatte als Festplattenreihenfolge gespeichert: /dev/sda, /dev/sdb. Deshalb bin ich davon ausgegangen, dass der bootfähige Code in den MBR der ersten Festplatte eingetragen würde. Das stimmte aber nicht.
  3. Das mir seit Monaten gezeigte GRUB-Startmenü -- ohne dass ich es wusste -- war jenes aus einer älteren Leap 42.1-Installation auf der ersten Festplatte. Dieses wusste naturgemäß ursprünglich nichts von der später erfolgten Installation der 42.3. Erst als ich aus der 42.1 heraus den dortigen GRUB neu in den ersten MBR gebracht hatte, erschien ein Eintrag für die 42.3. Damit konnte ich dann booten.

Was habe ich daraus gelernt? Jede der beiden Festplatten hat ihren eigenen MBR, und ich kann (wie von Josef vorgeschlagen) im BIOS einstellen, in welchem der beiden zuerst nach bootfähigem Code gesucht werden soll. Den GRUB grundsätzlich immer in den MBR der ersten Festplatte zu schreiben und die Festplattenreihenfolge niemals anzufassen (was eigentlich mein Plan gewesen war), geht nicht.

Danke an alle, die sich mit mir zusammen den Kopf zerbrochen haben.

Grüße aus dem herbstlichen Franken
Hazel
 

josef-wien

Ultimate Guru
Hazel schrieb:
als Festplattenreihenfolge gespeichert: /dev/sda, /dev/sdb
Das allein sagt nichts aus. Schau Dir die Datei /boot/grub2/device.map an, der Begriff (hd0) ist eine der möglichen GRUB*-Schreibweisen für die BIOS-ID 0x80 und bezeichnet immer jene Platte, die beim Systemstart im BIOS als Boot-Platte definiert ist, und wenn die Eintragungen in der Datei nicht mit der Realität des aktuellen Systemstarts übereinstimmen, sind Probleme bei der Bootloader-Einrichtung zu erwarten. Die Zuordnung der Gerätenamen /dev/sda usw. hat absolut nichts mit der im BIOS definierten Reihenfolge zu tun.
 
OP
H

Hazel

Hacker
Hallo Josef

josef-wien schrieb:
Schau Dir die Datei /boot/grub2/device.map an, der Begriff (hd0) ist eine der möglichen GRUB*-Schreibweisen für die BIOS-ID 0x80 und bezeichnet immer jene Platte, die beim Systemstart im BIOS als Boot-Platte definiert ist

OK, ich schaue mir die beiden Dateien an -- erst unter der 42.2, dann unter der 42.3:
Code:
linux:~ # cd /boot/grub2
linux:/boot/grub2 # 
linux:/boot/grub2 # cat device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/sdc
linux:/boot/grub2 # 
linux:/boot/grub2 # cd /42p3/boot/grub2
linux:/boot/grub2 # 
linux:/42p3/boot/grub2 # cat device.map
(hd0)   /dev/sdb
(hd1)   /dev/sda
linux:/42p3/boot/grub2 #
Offensichtlich ist der GRUB-Bezeichnung (hd0) jeweils eine andere Platte zugeordnet, oder? Wenn sich der GRUB aus dem BIOS die Device-Namen holt, bevor er die device.map schreibt, dann müsste ich doch in beiden Fällen denselben Plattennamen unter (hd0) finden...?

Grüße
Hazel
 
OP
H

Hazel

Hacker
Hallo Heinz-Peter
Heinz-Peter schrieb:
Meinst mit einfach Updaten das Kommando
grub2-mkconfig -o /boot/grub2/grub.cfg
Ich verstehe diesen Satz als Frage. Und die Antwort (oder Gegenfrage) lautet: Dasselbe macht der YaST doch auch, oder etwa nicht?

Grüße
Hazel
 
Hallo @Hazel
Hazel schrieb:
Hallo Heinz-Peter
Heinz-Peter schrieb:
Meinst mit einfach Updaten das Kommando
grub2-mkconfig -o /boot/grub2/grub.cfg
Ich verstehe diesen Satz als Frage. Und die Antwort (oder Gegenfrage) lautet: Dasselbe macht der YaST doch auch, oder etwa nicht?

Grüße
Hazel
Ich möchte in Zukunft neue Leap Version installieren und falls ich am Grub2 stecken bleibe hätte ich gerne gewusst wie habt ihr das gelöst.
Wie man es macht ist egal, wichtig ist das Ergebnis :wink:

Grüße Heinz-Peter
 

josef-wien

Ultimate Guru
Hazel schrieb:
Wenn sich der GRUB aus dem BIOS die Device-Namen holt
Genau das passiert nicht. GRUB* ist darauf ausgerichtet, dann zu agieren, wenn nach dem Systemstart nur der Boot-Manager läuft. Zu diesem Zeitpunkt kann er nur über die vom BIOS festgelegte BIOS-ID mit einer Platte kommunizieren. Er hat aber keine Ahnung, welche BIOS-ID zu welcher Platte gehört, das zu wissen ist Aufgabe des Menschen, der GRUB*-Befehle absetzt (bzw. in der Menü-Datei gespeichert hat).

Die Erzeugung der device.map (ob sie nun durch die Installationsroutine oder durch GRUB* erfolgt) war immer schon eine Art Wahrscheinlichkeitsrechnung. Diese Datei wird nur im laufenden System verwendet, und die Eintragungen werden herangezogen, unabhängig davon, ob sie die Realität abbilden oder nicht (zumindest ist das bei GRUB der Fall, GRUB2 habe ich nie verwendet, daher kann ich zu allfälligen anderen Vorgangsweisen nichts sagen).
 
Oben