[gelöst] Mal wieder Ärger mit Grub

[geier22]

Vor kurzem gab es mal wieder ein Update von Grub mit das mal wieder alles zerschossen hat:
Konfiguration: Dual-Boot

/dev/sdb --> Debian (sparky) Stretch Cinnamon --- > Bei der Installation wurde Grub in /dev/sdb/ installiert
/dev/sdc --> Debian (sparky) Stretch Xfce ----> Bei der Installation wurde Grub in /dev/sdc/ installiert

Code: Alles auswählen

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   2,7T  0 disk 
└─sda1   8:1    0   2,7T  0 part /media/Musik
sdb      8:16   1 465,8G  0 disk 
├─sdb1   8:17   1   5,9G  0 part [SWAP]
├─sdb2   8:18   1    40G  0 part 
└─sdb3   8:19   1 419,9G  0 part /media/cinnamonhome
sdc      8:32   0 119,2G  0 disk 
├─sdc1   8:33   0  34,2G  0 part /
└─sdc5   8:37   0  85,1G  0 part /home
sdd      8:48   0 698,7G  0 disk 
└─sdd1   8:49   0 698,7G  0 part /media/HD753LJ
sr0     11:0    1  1024M  0 rom  

Code: Alles auswählen

blkid -o list
device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/sdb1  swap             [SWAP]         cc37bf4c-84e1-425e-96f5-21e717c57b98
/dev/sdb2  ext4             (not mounted)  28ac974c-1558-4520-83ca-f6de8d814047
/dev/sdb3  ext4    cinnamonhome /media/cinnamonhome 92ad9934-c292-42d5-b881-faab5131d33a
/dev/sda1  ext4    Musik    /media/Musik   8b535dfa-0c3f-4c55-aa95-a6bd61679344
/dev/sdc1  ext4    Xfce Root /             6f9427a3-0897-4f59-8296-03676cc889c9
/dev/sdc5  ext4    Xfce Home /home         3bf6e217-677c-4f7d-bb6b-d69cada6fc5e
/dev/sdd1  ext4    Daten    /media/HD753LJ 8dc5668b-4c06-41e0-934e-01dd0eff6db9

sdb3 (/media/cinnamonhome) wird in Xfce durch die fstab gemountet, da die Datenverzeichnisse in /dev/sdc5 (/home/) nach dort verlinkt sind

installiert ist :

Code: Alles auswählen

dpkg -l *grub* |grep ii
ii  grub-common          2.02~beta2-36 amd64        GRand Unified Bootloader (common files)
ii  grub-pc              2.02~beta2-36 amd64        GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin          2.02~beta2-36 amd64        GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii  grub-theme-starfield 2.02~beta2-36 amd64        GRand Unified Bootloader, version 2 (starfield theme)
ii  grub2-common         2.02~beta2-36 amd64        GRand Unified Bootloader (common files for version 2)
ii  sparky-grub-theme    0.1.1         all          Sparky GRUB Theme

und os-prober 

Das hat nun mehrere Monate anstandslos funktioniert, egal, von welcher Platte ich bootete, auswählen konnte ich beide Systeme
Nun ist es nur noch möglich. Xfce auf /dev/sdc zu starten

als erste Massnahme hatte ich folgendes gemacht:

Code: Alles auswählen

dpkg-reconfigure grub-pc 
Installing for i386-pc platform.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found background image: /opt/artwork/sparky-grub.png
Linux-Abbild gefunden: /boot/vmlinuz-4.5.0-1-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.5.0-1-amd64
Debian GNU/Linux (stretch/sid) auf /dev/sdb2 gefunden
erledigt

Da ich dpkg-reconfigure grub-pc von xfce aus ausgeführt hatte dachte ich alles gut, da ja auf /sdb2 die richtige intrid.img gefunden wurde.
Leider nicht - egal von welche Platte ich starte und was ich auswähle Xfce startet.

meine grub.cfg sieht folgendermaßen aus: 39272

Um grub zu reparieren gibt es ja verschiedene Methoden:

Code: Alles auswählen

apt --reinstall install grub-common grub-pc os-prober 

Code: Alles auswählen

oder
dpkg-reconfigure grub-pc
oder
update-grub
oder
grub-setup /dev/sdX
oder
grub-install /dev/sdX

wobei mir der Unterschied zwischen den letzten 4 Varianten überhaupt nicht klar ist.
Vor einer Neuinstallation mittels

Code: Alles auswählen

apt --reinstall install grub-common grub-pc os-prober 

wird teilweise gewarnt.

Da dpkg-reconfigure-grub-pc ja nicht geklappt hat, scheint ja nur eine Neuinstallation infrage zu kommen.

Rettungs-CD's wie Rescatux habe ich noch nicht benutzt, Schreiben diese Programme die grub.cfg neu ?

Für tipps wäre ich sehr dankbar und für die Verhinderung zukünftiger Irrungen von Gub natürlich auch.

[smutbert]

oder
dpkg-reconfigure grub-pc
oder
update-grub
oder
grub-setup /dev/sdX
oder
grub-install /dev/sdX

• dpkg-reconfigure grub-pc macht im wesentlichen zwei Dinge
  • Es installiert grub auf die ausgewählten Geräte, in dem es grub-install /dev/sdX aufruft. Welche Geräte das sind müsste man zumindest mit

    Code: Alles auswählen

    # dpkg-reconfigure -p low grub-pc
    

    einstellen können.
  • Es ruft update-grub auf.
• update-grub
  Schreibt eine neue grub.cfg und ruft im Zuge dessen auch os-prober auf um andere Betriebssysteme zu finden. Die efi-Variante erstellt außerdem die Booteinträge in der Firmware.
• grub-setup
  Gibt es auf meinem jessie mit grub-efi gar nicht. Wenn es das doch wo gibt, würde ich vermuten, dass es nur ein Tool ist, das zB von grub-install verwendet wird, aber nichts, was ein Anwender/Administrator aufruft (ähnlich wie bei useradd vs adduser).
• grub-install /dev/sdX
  Installiert die ersten Teile von grub in den mbr/pbr des angegebenen Geräts (und möglicherweise wo sie sonst noch Platz finden). Der Rest des grub-Images und die Module werden auch erstellt und beim Booten von /boot/grub/… geladen.

Der Fehler liegt imho bei os-prober, denn die Einträge für die beiden Installationen übergeben dem jeweiligen Kernel denselben Parameter root=UUID=6f9427a3-0897-4f59-8296-03676cc889c9, beim Booten wird also die Xfce-/-Partition gemountet und damit auch dessen fstab und das restliche Xfce-System verwendet. Funktionieren tut das ganze nur mehr oder weniger zufällig, weil beide Systeme den gleichen Kernel verwenden, andernfalls würde der gestartete Kernel beim Aufruf des Cinnamon-Booteintrages nicht zu den dann auf der /-Partiton verfügbaren Kernelmodulen passen.

Ich würde auf os-prober verzichten (deinstallieren) und manuell einen Booteintrag für das zweite System erstellen, etwa indem du das an die Datei »/etc/grub.d/40_custom« hängst:

Code: Alles auswählen

menuentry 'Debian GNU/Linux (cinnamon)' {
    insmod part_msdos
    insmod ext2
    set root='hd1,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 --hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2  28ac974c-1558-4520-83ca-f6de8d814047
    else
        search --no-floppy --fs-uuid --set=root 28ac974c-1558-4520-83ca-f6de8d814047
    fi
    configfile /boot/grub/grub.cfg
}

Damit verwendest du zum Starten des cinnamon-Systems die grub-Konfigurationsdatei des cinnamon-Systems, du bist also nirgends mehr auf os-prober angewiesen und startest beide Systeme immer mit der aktuellen grub.cfg und nicht in dem Zustand (ie mit dem Kernel) in dem os-prober sie zuletzt erkannt hat.
Das setzt allerdings voraus, dass auf dem cinnamon-System ebenfalls grub installiert ist, ohne dass dieser Grub in den mbr geschrieben wurde.

[rendegast]

'grub-install'
erzeugt Dateien in /boot/grub/, macht 'update-grub' und
schreibt den Boot-/Start-Sektor + stage2.
Embedded, also Startsektor einer Partition(/dev/sdXY) funktioniert nur mehr bei Partitionen /boot/ und / (/, falls /boot keine eigene Partition hat).

'update-grub' erzeugt/aktualisiert /boot/grub/grub.cfg.

'dpkg-reconfigure grub-pc/grub-efi'
macht obiges kombiniert
und führt eine Liste über die benutzten Startsektoren.
(nominell/theoretisch)

'grub-setup' war wohl ein Hilfsskript unter suse.
Es arbeitete mit 'setup', einem Kommando der grub-Shell, im grub-Shell-Modus.
grub-install ist aber komfortabler.



Das stage2 (in Dateiform core.img) wird nicht unbedingt aktualisiert
(insbesondere bei mehreren Platten ein Osterei),
und es ist problematisch eine Aktualisierung zu verifizieren.
Länge ist unklar (in gewissen Situationen wird scheinbar auch mit random aufgefüllt, zBsp. bei embedded in btrfs gesehen), Dekompilierung ist ?.
-> Zumindest Checksummenprüfung ist notwendig, denn
Dateien werden mit aktuellem Datum immer neu geschrieben (jessie).
Ein altes stage2 kann unpassend zur aktuellen grub-Installation sein und das Booten verhindern.




Das stage1/stage2 hat(te) das Problem, /boot/grub/ zu finden,
zBsp. /dev/sdbX/boot -> /dev/sdb/MBR,
beim nächsten Boot ist sdb aber irgendwie sda 0x80, sucht /boot/ dennoch auf sdb resp. zweite Platte 0x81 -> Fehler.
Dazu gibt es den grub-Rescuemode, darin ein paar Kommados und es kann gebootet werden, normalerweise sowas

Code: Alles auswählen

rescue> set root=..passend..
rescue> set prefix=..passend..
rescue> insmod linux
rescue> insmod normal
rescue> normal

(Am besten auf einen Klebezettel am Rechner,
google zBsp. "grub rescue insmod linux")
Mittlerweise ist das Problem wohl durch Benutzung von UUID obsolet.
Auch umgeht eine embedded-Installation (in /boot oder /) dieses Problem.

Eine embedded-Installation hat das systematische Problem,
daß nicht sicher ist ob der überschriebene Bereich wirklich frei ist
(vom Dateisystem aus) und auch in Zukunft nie benutzt wird.



Weiterhin gibt es einen problematischen "Schutzmechanismus".
grub-Stage schreiben funktioniert nur für den Plattenanfang, in /boot- oder /-Partition.
Separate, ansonsten unbenutzte Kleinpartitonen für diesen Zweck anlegen funktioniert nicht
(das device muß entweder partitioniert oder formatiert sein).
Bei grub-efi gibt es zwar die bios-grub-Partition,
davon darf aber wohl auch nur eine existieren.

raid-devices md* oder lvm noch gar nicht erwähnt.



Bei Dir hätte wohl der grub-Rescuemode funktioniert,
auf jeden Fall aber das explizite Aufrufen von kernel/initrd vom funktionierenden grub aus.
Durch die TAB-Completion der grub-shell ist das auch keine Hexerei.

[smutbert]

Bei grub-efi gibt es zwar die bios-grub-Partition,

Für grub-efi braucht man sowas gar nicht. Bei grub-efi wird das komplette grub-image ja in eine Datei auf der EFI System Partition geschrieben. Diese BIOS Bootpartition ist meines Wissens nur auf gpt-partitionierten Datenträgern mit grub-pc hilfreich oder notwendig.

Bei Dir hätte wohl der grub-Rescuemode funktioniert,

Hab ich was überlesen?
Das Booten funktioniert doch, nur booten alle Menüeinträge das Xfce-System (weil os-prober aus irgendeinem Grund die falsche UUID in das root=… des cinnamon-System-Eintrags geschrieben hat).

[geier22]

Hallo ihr beiden erst mal vielen Dank für das viele Licht, das ihr bei mir in das Grub- Dunkel gebracht habt.
Wenn die Birne bei mir auch erst noch ziemlich schwach leuchtet.

Für mich die einfachste Lösung erscheint mir erst mal folgendes:
ich deinstalliere os-prober
und mache dann nochmal ein

Code: Alles auswählen

dpkg-reconfigure grub-pc

erstmal vorsichtshalber einen Neustart

im Anschluss ergänze ich in der Datei /etc/grub.d/40_custom, die im Augenblick so aussieht (auch Neuland ] :

Code: Alles auswählen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

die Zeilen, die Smubert vorgeschlagen hat.

dann

Code: Alles auswählen

update-grub

dann Augen zu und Neustart.

sollte ich auf diese Weise Cinnamon wieder zum laufen bekommen, wäre die selbe Prozedur auch dort durchzuführen, natürlich mit geänderter UUID.

Funktioniert das alles nicht , bliebe noch der Grub-Rescue Modus (wusste garnicht, wie man den aufruft (Birne= Heller )
oder Rescatux oder ----------????

[geier22]

hab grad os-prober deinstalliert
was mir auffällt:
die Datei /etc/grub.d/30_os-prober_proxy
wurde nicht gelöscht
da steht was drin, was vielleicht der Grund der Fehler sein könnte. Die muss schon uralt sein, da ich kde schon länger nicht mehr installiert habe

Code: Alles auswählen

!/bin/sh
#THIS IS A GRUB PROXY SCRIPT
'/etc/grub.d/proxifiedScripts/os-prober' | /etc/grub.d/bin/grubcfg_proxy "+*
+#text
+'SparkyLinux (4) (auf /dev/sda1)'~0c3f74c4d207fa44d1311eec915a7965~ as 'KDE-Plasma'
+'SUBMENU' as 'Erweiterte Optionen für SparkyLinux (4) (auf /dev/sda1)'{+'Erweiterte Optionen für SparkyLinux (4) (auf /dev/sda1)'/*, +'Erweiterte Optionen für SparkyLinux (4) (auf /dev/sda1)'/'Sparky GNU/Linux (auf /dev/sda1)'~ef5db5e5584ca3d82446713a79150547~, +'Erweiterte Optionen für SparkyLinux (4) (auf /dev/sda1)'/'Sparky GNU/Linux, mit Linux 4.3.0-1-amd64 (auf /dev/sda1)'~ef5db5e5584ca3d82446713a79150547~, +'Erweiterte Optionen für SparkyLinux (4) (auf /dev/sda1)'/'Sparky GNU/Linux, with Linux 4.3.0-1-amd64 (recovery mode) (auf /dev/sda1)'~88e8524fe928aff6763e275852693252~}

ich denke die datei sollte gelöscht werden ??
Ebenso die Datei /etc/grub.d/10_linux_proxy:

Code: Alles auswählen

#!/bin/sh
#THIS IS A GRUB PROXY SCRIPT
'/etc/grub.d/proxifiedScripts/linux' | /etc/grub.d/bin/grubcfg_proxy "+*
+#text
+'Sparky GNU/Linux'~e54f685b3c2eac121e62199086d6a6bb~ as 'Sparky Xfce/Linux'
+'SUBMENU' as 'Erweiterte Optionen für Sparky GNU/Linux'{+'Erweiterte Optionen für Sparky GNU/Linux'/*, +'Erweiterte Optionen für Sparky GNU/Linux'/'Sparky GNU/Linux, mit Linux 4.3.0-1-amd64'~49a3437f77a6592549ec71144340c060~, +'Erweiterte Optionen für Sparky GNU/Linux'/'Sparky GNU/Linux, with Linux 4.3.0-1-amd64 (recovery mode)'~a31ba1a968d484a6480156e7556e6db0~}
"

Langsam weiss ich nicht wass in /etc/grub.d/ "nativ" drin stehen sollte, und was irgend ein alter Schrótt ist, der eventuell für die Fehler verantwortlich ist.

Wie sinnvoll wäre ein

Code: Alles auswählen

apt --reinstall install grub-common grub-pc

werden bei diesem reinstall --install alle Dateien gelöscht (=purge)?

Fallstricke ? funktioniert das Überhaupt im laufenden System?

[geier22]

der Inhalt des Verzeichnisses bei meiner "normalen" Xfce - Installation : 39273

der Inhalt bei der Minimalen Installation ist "etwas" übersichtlicher (VM):

Code: Alles auswählen

hans@debian:/etc/grub.d$ ls -laR /etc/grub.d
/etc/grub.d:
insgesamt 80
drwxr-xr-x  2 root root  4096 Apr 15 04:57 .
drwxr-xr-x 96 root root  4096 Apr 29 16:54 ..
-rwxr-xr-x  1 root root  9791 Feb  5 18:30 00_header
-rwxr-xr-x  1 root root  6258 Jan 22 12:00 05_debian_theme
-rwxr-xr-x  1 root root 12261 Feb  5 18:30 10_linux
-rwxr-xr-x  1 root root 11082 Feb  5 18:30 20_linux_xen
-rwxr-xr-x  1 root root 11692 Feb  5 18:30 30_os-prober
-rwxr-xr-x  1 root root  1418 Feb  5 18:30 30_uefi-firmware
-rwxr-xr-x  1 root root   214 Feb  5 18:30 40_custom
-rwxr-xr-x  1 root root   216 Feb  5 18:30 41_custom
-rw-r--r--  1 root root   483 Feb  5 18:30 README
hans@debian:/etc/grub.d$ 

[geier22]

So step 1 ist erst mal gemacht:
allerdings brauchte es 2 Anläufe, da die Neuinstallation von grub automatisch os-prober mit sich zieht
danach war der gleiche Fehler wieder da:
Zwei Einträge, beide starten xfce, trotz "purge",

os-prober scheint also einen bug zu haben, da es nicht in der Lage ist, korrekte Einträge für zwei Systeme mit gleichen Kernel zu machen.

Jetzt gibt es erstmal ein "sauberes" Menü mit einem Eintrag, das Xfce startet.

Code: Alles auswählen

apt purge grub* os-prober
apt install --no-install-recommends grub-pc grub-common grub-pc-bin grub2-common

Dann werde ich mal Smubert's Vorschlag in Angriff nehmen.

[geier22]

so alles wieder im Lot

hab die /etc/grub.d/40_custom in Xfce (dev/sdc) ergänzt ---> Grub-Menue von /dev/sdb erschien

Allerdings klappte der Start von Cinnamon erst mit einer alten Intrid-Version (Erweiterte Optionen für Debian GNU/Linux..)

wie auch immer.. In Cinnamon Grub gepurgt und neu installiert wie vor.
Jetzt Startet Cinnamon via Grub (/dev/sdc) und im Anschluss dann über Grub (dev/sdb) bzw. Via Bios (Startplatte auswählen) direkt

Das ist mir aber wurst - wenns nur so bleibt.

Nochmals Danke für die Hilfe

[rendegast]

/etc/grub.d/10_os-linux_proxy
/etc/grub.d/30_os-prober_proxy

Langsam weiss ich nicht wass in /etc/grub.d/ "nativ" drin stehen sollte,

Erstmal gäbe es

Code: Alles auswählen

dpkg-query -S grub.d/  |  sort

Einen Schritt weiter ginge

Code: Alles auswählen

egrep "os-linux_proxy|os-prober_proxy|grub[.]d" /var/lib/dpkg/info/*

falls die Datei nicht von einem Paket mitgebracht, sondern bei Paketinstallation konstruiert wird
(muß dann natürlich auch so in einem der Installations-Skripte auftauchen).



os-prober ließe sich auch deaktivieren, /etc/default/grub[.d/...cfg]:

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=true

Statt 40_custom zu ändern und bei Änderung jedesmal 'update-grub' durchzuführen,
gingen auch Einträge in (41_custom->) /boot/grub/custom.cfg.
(Ich habe einen Link angelegt
/etc/grub.d/09_custom -> 41_custom
sodaß im grub-Menü meine Einträge vor denen des debian-Systems aufgeführt werden.)

[WPSchulz]

In einem anderen Zusammenhang war ich auch darauf gestossen, das os-prober die UUID völlig falsch für andere erkannte Installationen setzt. Eben habe ich mal
https://bugs.debian.org/cgi-bin/pkgrepo ... ist=stable
aufgerufen und gesehen, daß bugs überhaupt nicht bearbeitet werden. Es ist daher anzuraten os-prober zu purgen und mit "locate os-prober" nach verbliebenen Resten zu suchen und zu entfernen.

[geier22]

Ich habe gerade bei http://www.linuxmintusers.de/index.php? ... _chainload
noch was interessantes gefunden:

Wendet man die herkömmliche Methode an, die Grub dafür vorgesehen hat, kann das schnell sehr unübersichtlich werden:
Grub bringt ein Skript namens "os-prober" (Pfad: /etc/grub.d/30_os-prober) mit, das bei der Installation von Grub und auch bei jedem Aufruf von

Code: Alles auswählen

sudo update-grub

nach allen Betriebssystemen auf dem System (egal auf welchen Festplatten oder sonstigen angeschlossenen Speichermedien!) sucht und diese dann automatisch in das Grub-Menü aufnimmt.

Mint empfiehlt, das skript, das ja unabhängig davon, ob os-oprober installiert ist oder nicht existiert mit dem Befehl

Code: Alles auswählen

chmod -x /etc/grub.d/30_os-prober

zu deaktivieren.
wäre ja mal interessant ob das zufügen der Zeile in /etc/default/grub

Code: Alles auswählen

 GRUB_DISABLE_OS_PROBER=true

den selben Effekt hat oder diese zeile sich nur auf das eventuell installierte os-prober bezieht

[smutbert]

Wenn man einmal einen Blick in besagtes Skript wirft (»/etc/grub.d/30_os-prober« aus grub-common), dann sieht man das genau dasselbe zur Folge hat. Das Skript 30_os-prober prüft zuerst ob GRUB_DISABLE_OS_PROBER auf 1 oder true gesetzt ist und bricht ab, falls ja. Dann überprüft es ob os-prober vorhanden ist und bricht ab, falls nicht.
Entzieht man dem Skript die Rechte zum Ausführen, kann es natürlich gar nicht erst starten.

Das sind also 3 mehr oder weniger gleichwertige Methoden die Bootmenüeinträge für andere installierte Betriebssysteme nicht erstellen zu lassen.

[WPSchulz]

Ich habe eben das os-prober Script aus '/etc/grub.d/' allein gestartet und die Ausgabe in eine Textdatei umgeleitet. os-prober erstellte für die andere, gespiegelte Linuxinstallation einen Menu- sowie 14 erweiterte Menüeintrage. Alle 15 waren falsch, demnach Schrott.

[geier22]

Ich habe eben das os-prober Script aus '/etc/grub.d/' allein gestartet und die Ausgabe in eine Textdatei umgeleitet. os-prober erstellte für die andere, gespiegelte Linuxinstallation einen Menu- sowie 14 erweiterte Menüeintrage. Alle 15 waren falsch, demnach Schrott.

oh ja, das kenn ich auch:
viewtopic.php?f=12&t=159374&hilit=grub#p1076790