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

wieder mal win10 aus bootmenü verschwunden

tomm.fa

Administrator
Teammitglied
gorgonz schrieb:
Was mich interessieren würde: Wird an der Behebung überhaupt gearbeitet? Der Fehler ist schon so lange drin ;-)
Noch nie gehabt hier. Aber wenn das öfters vorkommt und es dich bei GNU/Linux erheblich stört, dann nimm doch den Bootmanager von Windows, eventuell funktioniert dieser ja besser. Hattest du denn zwischendurch was an den Einstellungen zu GRUB verändert?
 
Kann es sein das es sich dabei gar nicht um einen Fehler handelt? Wenn mich nicht alles täuscht war/ist bei opensuse os-prober per Konfiguration abgeschaltet.
 
OP
G

gorgonz

Hacker
naja, ich kann es immer wieder auf die gleiche Art beheben:

  • YaST Boot Manager aufrufen
  • den Tab Bootloader Optionen aktivieren
  • Fremdes OS testen deaktivieren
  • Speichern

Dann das gleiche rückwärts:

  • YaST Boot Manager aufrufen
  • den Tab Bootloader Optionen aktivieren
  • Fremdes OS testen wieder aktivieren
  • Speichern

So war es auch diesmal wieder, aber es nervt langsam nach einem Jahr.
 
OP
G

gorgonz

Hacker
@geier0819: wahrscheinlich ist der prober abgeschaltet, was auch erklären würde, warum meine Behebung funktioniert ;-). Aber warum passiert es immer wieder mal, dass die fest gefundene Config wieder verloren geht?

Oder hängt es vielleicht damit zusammen, dass ja auch unter win10 immer mal wieder Updates anfallen?
 

susejunky

Moderator
Teammitglied
Hallo gorgonz,
gorgonz schrieb:
... Wird an der Behebung überhaupt gearbeitet? Der Fehler ist schon so lange drin ;-)
Nenne uns bitte die ID des von Dir zu diesem Problem eingestellten Bugzilla-Reports und zeige uns den Inhalt der Datei "/etc/default/grub".

Auf meinem System sind zur Zeit MS Windows 10, openSUSE Leap 15.0, openSUSE Leap 15.1 und openSUSE Tumbleweed installiert. Alle openSUSE-Systeme haben vor kurzen einen update für GRUB2 erhalten aber das von Dir beschriebene Problem ist bei keinem meiner Systeme aufgetreten. Selbst der Update 1903 von MS Windows hat keinerlei Probleme verursacht.

Viele Grüße

susejunky
 

Hazel

Hacker
Hallo

gorgonz schrieb:
Ist kein neues Problem: nach kernel update wird die win10 Partition nicht mehr im Bootmenü vorgeschlagen.
Ich kann gorgonz' Beschreibung bestätigen. Ich habe auf zwei Maschinen kein Windows, dafür aber jeweils einen Parallelbetrieb von Leap 42.3 und Leap 15.0. In beiden Fällen führten updates seit einigen Monaten zum Verschwinden der alternativen Bootoptionen.

Allerdings läuft meine Erfahrung in die Richtung, dass ein update von GRUB jeweils Auslöser der geschilderten Effekte ist.

Demnächst ersetze ich die 42.3 durch 15.1, und dann schau'n mer mal.

Grüße
Hazel
 

susejunky

Moderator
Teammitglied
Hallo Hazel,
Hazel schrieb:
... Ich kann gorgonz' Beschreibung bestätigen.
Startest Du Dein System aus einer ESP (UEFI) oder dem MBR (BIOS oder CSM)?

Verwendest Du ein GPT- oder ein MBR-Partitionsschema auf dem Laufwerk, von dem Du startetst?
Hazel schrieb:
... Allerdings läuft meine Erfahrung in die Richtung, dass ein update von GRUB jeweils Auslöser der geschilderten Effekte ist.
Zeige bitte einmal den Inhalt der Datei(en) "/etc/default/grub" (von 42.3 und 15.0).

Viele Grüße

susejunky
 

Hazel

Hacker
Hallo susejunky

susejunky schrieb:
Startest Du Dein System aus einer ESP (UEFI) oder dem MBR (BIOS oder CSM)?
Letzteres: BIOS und MBR.

susejunky schrieb:
Verwendest Du ein GPT- oder ein MBR-Partitionsschema auf dem Laufwerk, von dem Du startetst?
Auch hier letzteres: Partitionsschema nach MBR-Regeln.

susejunky schrieb:
Zeige bitte einmal den Inhalt der Datei(en) "/etc/default/grub" (von 42.3 und 15.0).

Im Fall der 42.3 schaut es so aus:
Code:
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/12bd40fc-2bbb-48ea-ac24-d87bcfc97f12 splash=silent quiet showopts"
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#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_LINUX_RECOVERY="true"
#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"

Während die 15.0 zeigt:
Code:
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/12bd40fc-2bbb-48ea-ac24-d87bcfc97f12 splash=silent quiet showopts"
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#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_LINUX_RECOVERY="true"
#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"

Abgesehen von den Festlegungen für Hintergrundgestaltung kann ich hier keine Unterschiede erkennen. Etwas irgendwie Auffälliges ebenfalls nicht.

Ich muss der Vollständigkeit halber hinzufügen, dass die 42.3 nach mehreren Wochen Ruhepause heute erstmals wieder in Betrieb genommen wurde und zunächst einmal einige Updates erfahren hat. Die besagte Datei 'grub' trägt aber immer noch das Datum 5.4.2019.

Dank und Grüße
Hazel
 

susejunky

Moderator
Teammitglied
Hallo Hazel,
Hazel schrieb:
... Abgesehen von den Festlegungen für Hintergrundgestaltung kann ich hier keine Unterschiede erkennen. Etwas irgendwie Auffälliges ebenfalls nicht.
ich auch nicht.

Du hattest geschrieben
Hazel schrieb:
... Parallelbetrieb von Leap 42.3 und Leap 15.0. In beiden Fällen führten updates seit einigen Monaten zum Verschwinden der alternativen Bootoptionen.
Was hast Du mit "Verschwinden der alternativen Bootoptionen" gemeint?

  • Die jeweils andere openSUSE-Version wird nicht mehr im GRUB2-Startmenü angezeigt.
  • Das GRUB2-Startmenü bietet ältere (noch installierte) Kernel-Versionen und/oder die Recovery-Mode-Optionen nicht mehr an?

Wenn Du direkt nach einer Aktualisierung
Code:
# grub2-mkconfig -o /boot/grub2/grub.cfg
ausführst, ist dann beim nächsten Neustart das Bootmenü auch fehlerhaft?

Hast Du bei der Installation von 42.3 und bei der Installation von 15.0 einen Bootloader installiert und wenn ja, wohin wurde dabei "boot.img" (aka stage1) geschrieben (MBR oder Partition)?

Viele Grüße

susejunky
 

Hazel

Hacker
Hallo susejunky

susejunky schrieb:
Was hast Du mit "Verschwinden der alternativen Bootoptionen" gemeint?

  • Die jeweils andere openSUSE-Version wird nicht mehr im GRUB2-Startmenü angezeigt.
  • Das GRUB2-Startmenü bietet ältere (noch installierte) Kernel-Versionen und/oder die Recovery-Mode-Optionen nicht mehr an?

Nachträglich korrigiert: Beide Antworten sind richtig.

susejunky schrieb:
Wenn Du direkt nach einer Aktualisierung
Code:
# grub2-mkconfig -o /boot/grub2/grub.cfg
ausführst, ist dann beim nächsten Neustart das Bootmenü auch fehlerhaft?

Dieser Test muss natürlich warten, bis die erwähnte Situation wieder eintritt.

susejunky schrieb:
Hast Du bei der Installation von 42.3 und bei der Installation von 15.0 einen Bootloader installiert und wenn ja, wohin wurde dabei "boot.img" (aka stage1) geschrieben (MBR oder Partition)?

In der 42.3 (Installationszeitpunkt: August 2017) meldet YaST:
[X] Aus Master-Boot-Record starten
[X] Aus Root-Partition starten
Bei der 15.0 steht an dieser Stelle
[_] Aus Partition booten
[X] Aus Master-Boot-Record starten
Warum genau diese Konfigurationsvarianten letztlich zustande kamen, kann ich heute auch nicht mehr erklären. Vermutlich war es einfach der Vorschlag von YaST, und nachdem ich mit diesem Vorgehen immer gut gefahren bin, habe ich es dabei belassen.

Danke und Gruß
Hazel
 

susejunky

Moderator
Teammitglied
Hallo Hazel,
Hazel schrieb:
... Dieser Test muss natürlich warten, bis die erwähnte Situation wieder eintritt.
Verständlich.

Momentan hast Du sowohl 42.3 als auch 15.0 so installiert, dass jedes System den Bootloader verwalten (d.h. wenn erforderlich aktualisieren) will.

Nutzen 42.3 und 15.0 getrennte Datenträger mit jeweils eigenem MBR (d.h. wählst Du über Dein BIOS aus, welcher Bootloader genutzt werden soll)?

Falls nicht, dann nutzen sowohl 42.3 als auch 15.0 den identischen Speicherplatz für "boot.img" und "core.img"; d.h. die tatsächlich im Einsatz befindliche GRUB2-Version hängt davon ab, welches System als letztes GRUB2 aktualisiert hat. Das muss nicht unbedingt kritisch sein, aber es vereinfacht auch nicht die Fehlersuche.

Mein Vorschlag wäre daher, zunächst openSUSE 42.3 so um zu konfigurieren, dass es den Bootloader nicht mehr verwaltet, sondern dass nur noch openSUSE 15.0 (oder die aktuellste, installierte openSUSE-Version) sich um GRUB2 "kümmert".

Tritt das Problem dann immer noch auf, kann man zumindest schon mal die Fehlersuche auf eine openSUSE-Version beschränken.

Viele Grüße

susejunky
 

Hazel

Hacker
Hallo,

ich musste an meinem Beitrag 2019-Jul-28 4:45 pm eine Korrektur vornehmen. Nichts, was die Situation irgendwie verändert, aber jetzt stimmt immerhin alles dort notierte.

Grüße
Hazel
 

Hazel

Hacker
Hallo susejunky

Ich bitte um Verständnis für mein mehrtägiges Schweigen. Aufgrund starker beruflicher Belastung sitze ich unter der Woche kaum noch am privaten Rechner.

Aber nun kann ich deine Frage
susejunky schrieb:
Wenn Du direkt nach einer Aktualisierung
Code:
# grub2-mkconfig -o /boot/grub2/grub.cfg
ausführst, ist dann beim nächsten Neustart das Bootmenü auch fehlerhaft?
kompetent beantworten: Nach Auffrischung der GRUB2-Konfiguration auf dem vorgeschlagenen Weg sind alle Bootoptionen wieder da.

"...direkt nach einer Aktualisierung..." stimmt hier natürlich nicht ganz. Das letzte Kernel-Update geschah vor 14 Tagen, das letzte GRUB-Update vor 9 Tagen.

Grüße aus Franken
Hazel
 

susejunky

Moderator
Teammitglied
Hallo Hazel,
Hazel schrieb:
... Nach Auffrischung der GRUB2-Konfiguration auf dem vorgeschlagenen Weg sind alle Bootoptionen wieder da.
nach meiner Erfahrung wird das GRUB2-Menü nach einer Kernel- und/oder GRUB2-Aktualisierung von zypper automatisch aktualisiert.

Bei den Systemen, bei denen ich http://download.opensuse.org/repositories/Kernel:/stable/standard/ verwende, funktioniert diese automatische Aktualisierung des GRUB2-Menüs nach einer Kernel-Aktualisierung allerdings nicht. Ich habe mir bislang noch nicht die Mühe gemacht herauszufinden, warum das so ist.

Diese Nicht-Aktualisierung des GRUB2-Menüs hat jedoch nur zur Folge, dass die neuste (aktualisierte) Kernel-Version nicht im GRUB2-Menü angezeigt wird. Es gehen jedoch keine Menü-Punkte aus dem GRUB2-Menü "verloren" (/boot/grub2/grub.cfg wird ja nicht verändert).

Dass Menü-Punkte, die vor einer Aktualisierung vorhanden waren, nach einer Aktualisierung plötzlich fehlen, ist meines Erachtens ein Hinweis darauf, dass das GRUB2-Menü (nach einer Aktualisierung) neu erstellt wird (allerdings nicht "korrekt"). Warum der von Dir beschriebenen Fehler auftritt, ist mir unklar.

Die Tatsache, dass Du mit grub2-mkconfig ein korrektes (d.h. "vollständiges") GRUB2-Menü erstellen kannst, zeigt dass Deine GRUB2-Konfiguration eigentlich in Ordnung ist. Die von Dir gezeigten Inhalte von /etc/default/grub haben das auch bereits nahegelegt.

Bleibt noch die Frage offen, ob es an der Art und Weise liegen kann, wie GRUB2 von Deinen Systemen "verwaltet" wird (siehe meinen Beitrag vom 28.07.2019, 19:43 Uhr).

Viele Grüße

susejunky
 
OP
G

gorgonz

Hacker
sorry zusammen, bei mir war Urlaubszeit. Lese, Einiges wurde schon geprüft. Bin jetzt nicht sicher, welche Infos derzeit sinnvoll sind und stelle Angesprochenes zusammen.

Beim letzten Update ist es wieder passiert. Kann ich irgendwo im Nachhinein feststellen, ob es kernel oder grub Update gewesen ist?

Ich leg mal los.:
/etc/default/grub:
Code:
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12PNEAD109827R-part4 splash=silent quiet showopts resume=/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12PNEAD109827R-part4 splash=silent quiet showopts"
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#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_LINUX_RECOVERY="true"
#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16 vga=gfx-1024x768x16"

Es wird nur OSS 15.1 und advanced options zu OSS 15.1 im Bootmenü angeboten.

Hab jetzt
Code:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
ausgeführt, hier das konsole log:
Code:
GRUB-Konfigurationsdatei wird erstellt …
Thema gefunden: /boot/grub2/themes/openSUSE/theme.txt
Linux-Abbild gefunden: /boot/vmlinuz-4.12.14-lp151.28.10-default
initrd-Abbild gefunden: /boot/initrd-4.12.14-lp151.28.10-default
Linux-Abbild gefunden: /boot/vmlinuz-4.12.14-lp151.28.7-default
initrd-Abbild gefunden: /boot/initrd-4.12.14-lp151.28.7-default
ERROR: asr: reading /dev/sdc[Input/output error]
ERROR: ddf1: reading /dev/sdc[Input/output error]
ERROR: isw: reading /dev/sdc[Input/output error]
ERROR: jmicron: reading /dev/sdc[Input/output error]
ERROR: lsi: reading /dev/sdc[Input/output error]
ERROR: nvidia: reading /dev/sdc[Input/output error]
ERROR: sil: reading /dev/sdc[Input/output error]
ERROR: via: reading /dev/sdc[Input/output error]
ERROR: isw: wrong number of devices in RAID set "isw_cjchfdghfi_SATA00" [1/2] on /dev/sdb
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
Fehler: »/dev/sdc« ist nicht lesbar: Eingabe-/Ausgabefehler.
openSUSE Leap 42.2 auf /dev/sda2 gefunden
Windows 10 auf /dev/sdd1 gefunden
erledigt
Es stimmt, dass es noch ein (altes) drittes System 42.2 gibt, dass ich jedoch schon ewig nicht mehr gebootet habe.
Zur Sicherheit grub nochmal verglichen, hat gleichen Inhalt behalten
Poste das jetzt und dann boote ich mal ;-)
 
OP
G

gorgonz

Hacker
Ok, das mkconfig hat das Problem bei mir behoben, ich sehe wieder
  • 15.1,
  • 15.1 advanced,
  • 42.2,
  • 42.2 advanced
  • windows 10

Behebt also das Problem bei mir. Bleibt die Frage, warum es überhaupt passiert.
 

susejunky

Moderator
Teammitglied
Hallo gorgonz,
gorgonz schrieb:
... Bleibt die Frage, warum es überhaupt passiert.
eine mögliche Erklärung könnte sein, dass GRUB2 von 42.2 zum Systemstart genutzt wird.

Updates von GRUB2 oder kernel führen in aller Regel dazu, dass grub2-mkconfig angestoßen und /boot/grub2/grub.cfg neu erstellt wird. ABER 42.2 ist EOL; d.h. es erhält keinerlei updates mehr (weder GRUB2 noch kernel). Somit würde die zum Systemstart genutzte /boot/grub2/grub.cfg von 42.2 nie automatisch aktualisiert.

Viele Grüße

susejunky
 
OP
G

gorgonz

Hacker
Erst mal vielen Dank für Deine Erläuterungen :). Ja, das leuchtet mir durchaus ein, auch wenn mir nicht ganz klar ist, wie ich feststellen kann, ob der grub2 von 42.2 noch aktiv ist. Daher doch noch 2 Fragen:

Wie kann ich feststellen, welcher Bootloader derzeit aktiv ist?
Wie kann ich ihn zum Loader von 15.1 umstellen?

Was bekannt ist:
YaST meldet: grub2 wird aus dem Master Boot Record gestartet, aber ich sehe nicht, welche Partition das Flag bootable hat
 

susejunky

Moderator
Teammitglied
Hallo gorgonz,
gorgonz schrieb:
... Wie kann ich ihn zum Loader von 15.1 umstellen?
meines Erachtens geht das am einfachsten, indem Du Deine openSUSE-Leap-15.1-Installation startest und GRUB2 über die Konsole, so wie hier https://www.gnu.org/software/grub/manual/grub/grub.html#Installing-GRUB-using-grub_002dinstall beschrieben, nochmals installierst.

Bitte beachte, dass bei openSUSE die grub-xxx-Befehle alle in grub2-xxx-Befehle umbenannt sind (d.h. grub-install ist bei openSUSE grub2-install).

Viele Grüße

susejunky
 
Oben