[Gelöst] 42.1 Bootproblem

dzug · 1 Feb. 2016

Hei.
Letztes Update gemacht mit Kernel 4.1.15-8.
Er Bootet daraufhin keinen Kernel 4.1.15-8.
Im Grub2 Menue ist der Kernel nicht da.
Folgendes Phänomen habe ich:
Sda1 und Sda2 sind / je 1x 42.1.
Grub2 bootet default von sda2 und zeigt sda1 an.
Sda2 upgedatet, alles gut, mit neuem Kernel gebootet.
Alten Kernel gelöscht.
Dann Sda1 upgedatet alles Installiert nur hier bootet er den alten Kernel.
Der neue Kernel ist laut Yast2 Installiert taucht aber im Bootmenue von Grub2 nicht auf.
Wo kann ich nachschauen?
Ich danke für eine freundliche Antwort.
Gruss dzug.

susejunky · 1 Feb. 2016

Hallo dzug,

dzug schrieb:
... Er Bootet daraufhin keinen Kernel 4.1.15-8. ...

Hat "Er" ein BIOS oder ein UEFI. Falls "Er" ein UEFI hat, nutzt "Er" den UEFI- oder den CSM-Modus um das System zum starten?

Viele Grüße

susejunky

towo · 1 Feb. 2016

Das Problem ist doch, daß hier 2 Installationen vorliegen, Grub aber nur von einer Installation gewartet wird.
Und wenn man keinen Plan hat, sollte man solche Setups eben nicht benutzen, zumal das sowieso recht sinnfrei ist.

dzug · 2 Feb. 2016

Danke susejunky.
Er hat ein Bios.
Er startet mit dem Bios.
Er hat UEFI.
Das ist ausgeschaltet.
CSM ??
Bootloader ist Grub2.
Danke towo.
Gruss dzug.

susejunky · 2 Feb. 2016

Hallo dzug,

dzug schrieb:
... Er hat ein Bios.
Er startet mit dem Bios.
Er hat UEFI.
Das ist ausgeschaltet.
CSM ??

CSM (= "Compatibility support mode" oder auch "Legacy mode" genannt) ist genau das, was Du anscheinend momentan nutzt. Du hast Dein UEFI so konfiguriert, dass es bootet wie ein BIOS; d.h. es lädt die ersten 512 Byte einer Festplatte (welche Festplatte genutzt wird, wird anhand der Bootreihenfolge oder über ein Boot-Auswahlmenü ermittelt) in den Hauptspeicher und führt diesen Code (= boot.img von GRUB2)aus. Da 512 Byte nicht ausreichen, um alle Funktionen, die für das Laden eines Betriebssystems benötigt werden, zu implementieren, hat boot.img hauptsächlich die Aufgabe weiteren Code (= core.img von GRUB2) von der Festplatte zu laden und auszuführen.

Hier eine Grafik, die das sowohl für MBR- als auch für GPT-partitionierte Festplatte gut veranschaulicht:
https://de.wikipedia.org/wiki/Datei:GNU_GRUB_components.svg
Und in diesem Artikel kannst Du auch noch einige Details dazu nachlesen:
https://de.wikipedia.org/wiki/GRUB2

Da zu Beginn des Bootvorgangs noch nicht allzuviel Funktionalität zur Verfügung steht, werden beim Installieren des Bootloaders auch einige Informationen "fest codiert"; z.B. wo core.img auf der Festplatte zu finden ist und welche grub.cfg genutzt wird. Und damit wären wir dann bei Deinem konkreten Problem:

Wenn ich Deine Konfiguration richtig verstehe, dann hast Du auf sda1 und sda2 jeweils ein Verzeichnis /boot/grub2 und dort je eine Datei grub.cfg. Bei der Installation des Bootloaders wird festgelegt, welche grub.cfg zum Starten genutzt wird (im Normalfall die grub.cfg des Systems, welches Du zum Zeitpunkt der Bootloader-Installation benutzt). Die andere grub.cfg wird beim Systemstart NICHT genutzt.

Beispiel:
Du startest Dein System von sda1 und führst "grub2-install /dev/sda" aus. Damit wird boot.img in die ersten 512 byte von sda geschrieben. core.img wird ebenfalls auf sda geschrieben, wohin ist allerdings konfigurationsabhängig. Dann führst Du "grub2-mkconfig -o /boot/grub2/grub,cfg" aus, womit auf sda1 unter /boot/grub2 eine grub.cfg erstellt wird, die - wenn der OS-Prober aktiviert war - auch Dein System von sda2 starten kann. Diese grub.cfg von sda1 (und nur diese) wird ab diesem Zeitpunkt bei allen Systemstarts verwendet.

Startest Du nun Dein System von sda2 und machst dort einen Kernel-update mit YaST2, dann erzeugt YaST2 zwar automatisch eine neue grub,cfg ABER auf sda2. Diese wird aber nicht beim Systemstart verwendet, sondern die grub,cfg von sda1. Diese wiederum beinhaltet aber nicht den auf sda2 vorgenommenen Kernel-update.

Lösung:
Finde heraus, welche grub.cfg (von sda1 oder von sda2) beim Systemstart verwendet wird. Wenn Du das System aktualisierst, dessen grub.cfg nicht verwendet wird, boote unmittelbar nach der Aktualisierung das System, dessen grub.cfg verwendet wird und aktualisiere sie mit

Code:

grub2-mkconfig -o /boot/grub2/grub,cfg

(Achtung! OS-Prober muss aktiviert sein).

ACHTUNG!
Updates von GRUB2 ziehen manchmal eine automatische Neu-Installation des Bootloaders nach sich. In Deiner Konfiguration kann das zur Folge haben, dass sich die zum Systemstart verwendete grub.cfg ändert (z.B. statt grub.cfg von sda1 wird dann grub.cfg von sda2 verwendet).

Viele Grüße

susejunky

marce · 2 Feb. 2016

Anders gesagt: Wenn man nicht mit dem Ansatz zu spielen an die Sache herangeht oder nicht sehr genau weiß, was man tut ist es sinnvoll, die Anzahl der installierten Bootloader irgendwo in einer sehr nahen Umgebung von 1 zu halten.

Es spricht auch nichts dagegen, einen der beiden Grubs zu deinstallieren.

dzug · 2 Feb. 2016

Danke susejunky für Deine ausführliche Antwort.
Das Booten default erfolgt mit Grub2 von sda2.
Da kann ich auch sda1 auswählen.
Ich scheue mich den Grub2 von sda1 zu Löschen.
Es wird dann wieder auf eine Neuinstallation hinauslaufen weil dann warscheinlich garnix mehr bootet.
Dann bringt mir ja auch nichts wenn die Meldung kommt:Reboot für den neuen Kernel.
Er bootet den neuen Kernel ja nicht.
Gruss dzug.

susejunky · 2 Feb. 2016

Hallo dzug,

dzug schrieb:
... Ich scheue mich den Grub2 von sda1 zu Löschen.

Aus meiner Sicht besteht kein Bedarf etwas zu löschen.

dzug schrieb:
... Das Booten default erfolgt mit Grub2 von sda2.

Du bist Dir also sicher, dass die Datei grub.cfg von sda2 zum Systemstart genutzt wird?

Falls Du Dir nicht sicher bist, kannst Du einen "menuentry-Eintrag" in der grub.cfg von sda2 anpassen; z.B.:

Code:

menuentry 'von sda2: openSUSE' --class opensuse ...

und danach das System neu booten. Wenn Du dann im Grub2-Bootmenü den Menüpunkt "von sda2: openSUSE" angezeigt bekommst, wird tatsächlich die grub.cfg von sda2 benutzt. Wenn nicht, dann ist Dein Bootloader so installiert, dass er die grub.cfg von sda1 benutzt.

Wrd die Datei grub.cfg von sda2 zum Systemstart genutzt, dann sollte es ausreichen, wenn Du das auf sda2 installierte System startest und mit

Code:

grub2-mkconfig -o /boot/grub2/grub,cfg

die Datei grub.cfg von sda2 aktualisierst. Allerdings muss OS-Prober aktiviert sein; d.h. die Datei /etc/default/grub auf sda2 muss den Eintrag "GRUB_DISABLE_OS_PROBER=false" enthalten.

Falls doch die Datei grub.cfg von sda1 zum Systemstart genutzt wird, dann startest Du das auf sda1 installierte System und aktualisierst die dortige grub.cfg.

Viele Grüße

susejunky

dzug · 3 Feb. 2016

Danke susejunky.
Nach Bios startet Grub2 mit folgender Anzeige:

Code:

openSUSE Leap 42.1
Advanced options for openSUSE Leap 42.1
openSUSE 42.1(x86_64)(on/dev/sda1)
Advanced options for openSUSE 42.1 (x86_64)(on/dev/sda1)

Gehe ich auf die 4.Zeile kommt ein weiteres Fenster:

Code:

openSUSE Leap 42.1 (on/dev/sda1)
openSUSE Leap 42.1 with Linux 4.1.13-5 default (on/dev/sda1

Es wird der neue Kernel nicht angezeigt.
Das ist mein Problem.
Mit dem Anpassen der Grub config (wie?) werde ich mir dann wohl das komplette System zerschiessen.
Gruss dzug.

susejunky · 3 Feb. 2016

Hallo dzug,

dzug schrieb:
... Nach Bios startet Grub2 mit folgender Anzeige:

Code:

openSUSE Leap 42.1 Advanced options for openSUSE Leap 42.1 openSUSE 42.1(x86_64)(on/dev/sda1) Advanced options for openSUSE 42.1 (x86_64)(on/dev/sda1)

Gehe ich auf die 4.Zeile kommt ein weiteres Fenster:

Code:

openSUSE Leap 42.1 (on/dev/sda1) openSUSE Leap 42.1 with Linux 4.1.13-5 default (on/dev/sda1

Es wird der neue Kernel nicht angezeigt.
Das ist mein Problem.

Aufgrund dieser Reihenfolge vermute ich, dass Dein Bootloader - so wie Du das auch bereits gesagt hast - die grub.cfg von sda2 nutzt.

Hast Du schon einmal ausprobiert, das System von sda2 zu starten (erster Eintrag in Deinem aktuellen Bootmenü) und dann als Administrator in einer Konsole mit Hilfe dieses Befehls

Code:

grub2-mkconfig -o /boot/grub2/grub.cfg

die grub.cfg zu aktualisieren?

Sollte das nicht zur Lösung führen, dann zeige bitte einmal die Ergebnisse folgender Befehle (am besten als Administrator in einer Konsole ausführen):

von der Festplatte sda2:

Code:

cat /etc/default/grub

Code:

ls -la /boot

von der Festplatte sda1:

Code:

ls -la /boot

Viele Grüße

susejunky

dzug · 3 Feb. 2016

Hier von Sda2:

Code:

       peter@linux-sda2-Platte-C:~> su
Passwort: 
linux-sda2-Platte-C:/home/peter # cat /etc/default/grub
# Modified by YaST2. Last modification on So Dez 13 14:21:19 CET 2015
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader

# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.
GRUB_DISTRIBUTOR=""
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdb2 splash=silent quiet showopts"
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY=single
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
# Skip 30_os-prober if you experienced very slow in probing them
# WARNING foregin OS menu entries will be lost if set true here
GRUB_DISABLE_OS_PROBER=false
# Set to 'y' for grub to be installed on an encrypted partition
GRUB_ENABLE_CRYPTODISK=n
SUSE_BTRFS_SNAPSHOT_BOOTING=true
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt

Code:

linux-sda2-Platte-C:/home/peter # ls -la /boot
insgesamt 24488
drwxr-xr-x  4 root root    4096 29. Jan 14:04 .
drwxr-xr-x 25 root root    4096  3. Feb 20:27 ..
-rw-r--r--  1 root root     512 13. Dez 14:21 backup_mbr
-rw-r--r--  1 root root    1725 13. Okt 15:06 boot.readme
-rw-r--r--  1 root root  164413 21. Jan 09:19 config-4.1.15-8-default
drwxr-xr-x  2 root root    4096 23. Nov 10:53 dracut
drwxr-xr-x  7 root root    4096 29. Jan 14:04 grub2
lrwxrwxrwx  1 root root      23 29. Jan 13:57 initrd -> initrd-4.1.15-8-default
-rw-r--r--  1 root root 7200748 29. Jan 13:58 initrd-4.1.15-8-default
-rw-r--r--  1 root root  499712 13. Dez 13:01 message
-rwxr-xr-x  1 root root     169 13. Dez 13:15 perl-BL_delayed_exec
-rw-r--r--  1 root root  938244 21. Jan 10:09 symtypes-4.1.15-8-default.gz
-rw-r--r--  1 root root  329098 21. Jan 10:08 symvers-4.1.15-8-default.gz
-rw-r--r--  1 root root     484 21. Jan 10:08 sysctl.conf-4.1.15-8-default
-rw-r--r--  1 root root 3118139 21. Jan 10:03 System.map-4.1.15-8-default
-rw-r--r--  1 root root 6894639 21. Jan 10:09 vmlinux-4.1.15-8-default.gz
lrwxrwxrwx  1 root root      24 29. Jan 13:57 vmlinuz -> vmlinuz-4.1.15-8-default
-rw-r--r--  1 root root 5875016 21. Jan 10:52 vmlinuz-4.1.15-8-default
-rw-r--r--  1 root root      65 21. Jan 10:52 .vmlinuz-4.1.15-8-default.hmac
linux-sda2-Platte-C:/home/peter #

Hier Sda1:

Code:

peter@linux-sda1-Platte-C:~> su
Passwort: 
linux-sda1-Platte-C:/home/peter # ls -la /boot
insgesamt 51216
drwxr-xr-x  4 root root     4096 31. Jan 14:08 .
drwxr-xr-x 26 root root     4096  1. Jan 2013  ..
-rw-r--r--  1 root root      512 10. Dez 13:18 backup_mbr
-rw-r--r--  1 root root     1725 13. Okt 15:06 boot.readme
-rw-r--r--  1 root root   164424 27. Nov 13:35 config-4.1.13-5-default
-rw-r--r--  1 root root   164413 21. Jan 09:19 config-4.1.15-8-default
drwxr-xr-x  2 root root     4096 23. Nov 10:53 dracut
drwxr-xr-x  7 root root     4096 31. Jan 14:07 grub2
lrwxrwxrwx  1 root root       23 31. Jan 14:06 initrd -> initrd-4.1.15-8-default
-rw-r--r--  1 root root 10004492 30. Jan 14:33 initrd-4.1.13-5-default
-rw-r--r--  1 root root  7218928 31. Jan 14:06 initrd-4.1.15-8-default
-rw-r--r--  1 root root   499712 28. Okt 21:33 message
-rwxr-xr-x  1 root root      338 30. Jan 14:30 perl-BL_delayed_exec
-rw-r--r--  1 root root   938244 27. Nov 15:47 symtypes-4.1.13-5-default.gz
-rw-r--r--  1 root root   938244 21. Jan 10:09 symtypes-4.1.15-8-default.gz
-rw-r--r--  1 root root   329098 27. Nov 15:41 symvers-4.1.13-5-default.gz
-rw-r--r--  1 root root   329098 21. Jan 10:08 symvers-4.1.15-8-default.gz
-rw-r--r--  1 root root      484 27. Nov 15:40 sysctl.conf-4.1.13-5-default
-rw-r--r--  1 root root      484 21. Jan 10:08 sysctl.conf-4.1.15-8-default
-rw-r--r--  1 root root  3117554 27. Nov 15:22 System.map-4.1.13-5-default
-rw-r--r--  1 root root  3118139 21. Jan 10:03 System.map-4.1.15-8-default
-rw-r--r--  1 root root  6891326 27. Nov 15:47 vmlinux-4.1.13-5-default.gz
-rw-r--r--  1 root root  6894639 21. Jan 10:09 vmlinux-4.1.15-8-default.gz
lrwxrwxrwx  1 root root       24 31. Jan 14:06 vmlinuz -> vmlinuz-4.1.15-8-default
-rw-r--r--  1 root root  5872072 27. Nov 17:44 vmlinuz-4.1.13-5-default
-rw-r--r--  1 root root       65 27. Nov 17:44 .vmlinuz-4.1.13-5-default.hmac
-rw-r--r--  1 root root  5875016 21. Jan 10:52 vmlinuz-4.1.15-8-default
-rw-r--r--  1 root root       65 21. Jan 10:52 .vmlinuz-4.1.15-8-default.hmac
linux-sda1-Platte-C:/home/peter #

Ich sehe das sda1 zwei kernel hat.
Er bootet 4.1.13 und sollte 4.1.15 booten.
Gruss dzug.

susejunky · 3 Feb. 2016

Hallo dzug,

vielen Dank für die Ergebnisse. Also

auf sda2 ist Grub2 so konfiguriert, dass der OS-Prober aktiviert ist.
der Kernel 4.1.15 ist sowohl auf sda1 als auch auf sda2 verfügbar.

Soweit alles in Ordnung und meines Erachtens müsste es ausreichen die Datei grub.cfg auf sda2 (so wie in meiner letzten Nachricht beschrieben) neu zu erstellen, um Dein Problem zu lösen. Hast Du das schon ausprobiert ? Falls nein, dann starte bitte Dein System von sda2 und führe (als Administrator in einer Konsole) folgende Befehle aus:

Code:

mv /boot/grub2/grub.cfg /boot/grub2/grub.cfg.save

grub2-mkconfig -o /boot/grub2/grub.cfg

und starte danach Dein System neu.

Sollte der Kernel 4.1.15 dann immer noch nicht für das System auf sda1 im Bootmenü enthalten sein, verbleibt nur noch, den Bootloader neu zu installieren. Dazu startest Du Dein System von sda2 und gibst folgende Befehle (als Administrator) in einer Konsole ein:

Code:

grub2-install /dev/sda

grub2-mkconfig -o /boot/grub2/grub.cfg

Wenn auch das Dein Problem nicht löst, dann kann ich Dir sehr wahrscheinlich auch nicht mehr weiterhelfen. Als letzten Versuch könntest Du dann noch den Inhalt der grub.cfg von sda2 hier zeigen, in der Hoffnung, dass deren Inhalt noch einen Hinweis auf die Problemursache gibt.

Viele Grüße

susejunky

dzug · 4 Feb. 2016

Vielen Dank susejunky.
Die zwei Befehle ausgeführt.
Der neue Kernel ist nun in Grub2 für sda1 eingetragen.
Sda1 gebootet und siehe da er bootet den neuen Kernel.
Damit gelöst.
Gruss dzug.

susejunky · 4 Feb. 2016

Hallo dzug,

dzug schrieb:
... Der neue Kernel ist nun in Grub2 für sda1 eingetragen.
Sda1 gebootet und siehe da er bootet den neuen Kernel.

das freut mich sehr! Ich hatte schon befürchtet, dass ich Dir nicht mehr weiter helfen könnte.

Da Du sowohl auf sda1 als auch auf sda2 openSUSE 42.1 installiert hast, kannst Du zukünftig ähnliche Probleme vermeiden, indem Du immer erst das System von sda1 aktualisierst und dann direkt danach das System von sda2 startest und ebenfalls aktualisierst. Damit sollte selbst nach einem umfassenden Grub2-Update (d.h. der Update installiert Grub2 neu) alles wieder funktionieren.

Viele Grüße

susejunky

dzug · 23 Juni 2016

Hei.
Ich habe noch was Rausgefunden.
Wenn ich den Grub2 welcher mir beide Systeme anzeigt zwangsweise Update dann zeigt Grub2 den "neuen"Kernel an.
Gruss dzug.

[Gelöst] 42.1 Bootproblem

dzug

Guru

susejunky

Moderator

towo

Moderator

dzug

Guru

susejunky

Moderator

marce

Guru

dzug

Guru

susejunky

Moderator

dzug

Guru

susejunky

Moderator

dzug

Guru

susejunky

Moderator

dzug

Guru

susejunky

Moderator

dzug

Guru