(gelöst) grub.cfg editieren und sichern

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Gerd50

(gelöst) grub.cfg editieren und sichern

Beitrag von Gerd50 » 01.06.2023 10:57:13

Wenn Grub bzw. initramfs oder systemd aktualisiert werden, wird jedesmal eine neue grub.cfg generiert
und jedesmal erhalte ich seit gefühlten Ewigkeiten dabei eine Datei mit falschen Inhalten. Installiert habe
ich Debian testing, daneben auf derselben Platte sid, beide xfce. Grub ist in testing installiert.

Ein Fehler, der schon auf dem Vorgängerrechner auftrat, waren Mehrfacheinträge für sid. Kurzfristig konnte
das durch erstellen einer Mini grub.cfg in sid /boot/grub behoben werden. Langfristig half aber nur, eine durch Akualisierungen verwürgte grub.cfg durch eine funktionierende zu ersetzen. Die Einträge, die beim booten zur
Auswahl stehen, habe ich selbst geschrieben und die möchte ich erhalten.

Laut Ubuntu Wiki ist das möglich, aber nur erfahrenen Nutzern empfohlen:

https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/
Manuelles Erstellen der grub.cfg
Neben der automatischen Generierung der Konfiguration durch die vorgegebenen GRUB-2-Skripte, spricht grundsätzlich überhaupt nichts dagegen, die Laufzeit-Konfigurationsdatei grub.cfg manuell zu erstellen. Schließlich bietet diese Möglichkeit die größtmögliche Flexibilität der Konfiguration. Man muss dabei neben den bereits [oben] erwähnten Nachteilen aber berücksichtigen, dass man sich dann auch um das Außerkraftsetzung der von den GRUB-Entwicklern und Ubuntu-Paketbetreuern eingerichteten Automatismen kümmern muss, damit die manuell erstellte Konfiguration nicht überschrieben wird.

Da man dabei die Vorgaben der Ubuntu-Paketbetreuer verlässt, wird diese Vorgehen nur erfahrenen Anwendern empfohlen und ist auch nicht Gegenstand dieses Artikels!

Es sei diesbezüglich nochmals auf das GRUB-Handbuch 🇬🇧 verwiesen.
Meine Erfahrungen reichen leider nicht aus, um mein Vorhaben zu verwirklichen. Das Grub
Handbuch bietet keine Hinweise.

Weiß jemand, wie ich meine grub.cfg vor Überschreibung schützen kann, wenn grub, initramfs oder systemd
mich mal wieder mit einer neu generierten grub.cfg beglücken wollen? Eigentlich ist das auch gar nicht nötig.
Meine selbst gebastelte ist schon fünfeinhalb Jahre alt, so alt wie meine Systeme und funktioniert.

Ein weiterer Grund, warum ich meine grub.cfg schützen möchte, ist grub. In der letzten Zeit gab es zwei
Aktualisierungen, beide male fuschte grub dabei an der /etc/default/grub rum.

Der Eintrag

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=false
wurde auskommentiert, folglich funktionierte 30_os-prober nicht, Einträge für sid fehlten völlig.
Zuletzt geändert von Gerd50 am 03.06.2023 21:26:01, insgesamt 1-mal geändert.

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 01.06.2023 11:35:01

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Wenn Grub bzw. initramfs oder systemd aktualisiert werden, wird jedesmal eine neue grub.cfg generiert
Ja was denn sonst?
Wenn es Updates für den Kernel gibt, dann gibt es auch ne neue initrd. Wie stellst du dir das vor, wenn grub in der alten Version bliebe? :roll:

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
und jedesmal erhalte ich seit gefühlten Ewigkeiten dabei eine Datei mit falschen Inhalten. Installiert habe
ich Debian testing, daneben auf derselben Platte sid, beide xfce. Grub ist in testing installiert.
Dinn Sinn versteh ich nicht wirklich. Die Unterschiede zwischen testing und sid sind nun wirklich nicht so groß, dass man da zwei Installationen zu haben müsste. Und warum testest du du die andere Version nicht in einer VM?

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Meine selbst gebastelte ist schon fünfeinhalb Jahre alt, so alt wie meine Systeme und funktioniert.
Nein, das kann und wird nicht funktionieren.

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Ein weiterer Grund, warum ich meine grub.cfg schützen möchte, ist grub. In der letzten Zeit gab es zwei
Aktualisierungen, beide male fuschte grub dabei an der /etc/default/grub rum.

Der Eintrag

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=false
wurde auskommentiert, folglich funktionierte 30_os-prober nicht, Einträge für sid fehlten völlig.
Siehe viewtopic.php?t=186781
Ich denke mit deinem jetzigen Wissenstand ist sowas wie testing oder gar sid und das in Dualboot für dich völlig ungeeignet.

Benutzeravatar
MSfree
Beiträge: 10753
Registriert: 25.09.2007 19:59:30

Re: grub.cfg vor überschreiben schützen

Beitrag von MSfree » 01.06.2023 11:43:40

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Weiß jemand, wie ich meine grub.cfg vor Überschreibung schützen kann, wenn grub, initramfs oder systemd mich mal wieder mit einer neu generierten grub.cfg beglücken wollen?
Neue initial RAM-Disks werden immer dann erstellt, wenn ein neuer Kernel installiert wird, gelegentlich auch wenn eine neue Version von systemd isntalliert wird, dann aber auch mit einem neuen Dateinamen (neue Versionsnummer). Würde der neue Kernel samt seiner initrd nicht in dir grub.cfg eingetragen werden, würde dein System nie den neuen Kernel booten.

Wie man einen Schreibschutz für grub.cfg implementieren könnte, weiß ich nicht. Die Prozesse, die aktiv werden, um eine neue grub.cfg zu erzeugen, laufen mit root-Rechten, so daß ein chmod hier unwirksam wäre. Kontraproduktiv, weil keine neuen Kernel eingatragen würden, ist es obendrein.

Die Problematik um GRUB_DISABLE_OS_PROBER wurde offen kommuniziert, und auch, warum man es gemacht hat.

An deiner Stelle würd ich schauen, warum du doppelte Einträge bekommst und das dann abstellen.

JTH
Moderator
Beiträge: 3023
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: grub.cfg vor überschreiben schützen

Beitrag von JTH » 01.06.2023 11:46:07

cosinus hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 11:35:01
Wenn es Updates für den Kernel gibt, dann gibt es auch ne neue initrd. Wie stellst du dir das vor, wenn grub in der alten Version bliebe? :roll:

[…]

Nein, das kann und wird nicht funktionieren.
Das kann schon funktionieren. Bei jedem Kernel- oder initrd-Update werden in / versionsunabhängige Symlinks angelegt, die immer auf das aktuellste zeigen:

Code: Alles auswählen

$ ls -l /{initrd.img,vmlinu?}{,.old}
lrwxrwxrwx 1 root root 29 May 12 19:12 /initrd.img -> boot/initrd.img-6.1.0-9-amd64
lrwxrwxrwx 1 root root 29 May 12 19:12 /initrd.img.old -> boot/initrd.img-6.1.0-8-amd64
lrwxrwxrwx 1 root root 26 May 12 19:12 /vmlinuz -> boot/vmlinuz-6.1.0-9-amd64
lrwxrwxrwx 1 root root 26 May 12 19:12 /vmlinuz.old -> boot/vmlinuz-6.1.0-8-amd64
Die kann man halbwegs problemlos langfristig in einer grub.cfg benutzen.

MSfree hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 11:43:40
An deiner Stelle würd ich schauen, warum du doppelte Einträge bekommst und das dann abstellen.
Das wär hier auch mein bevorzugter Ansatz, bevor man zu tief in diesen ganzen update-grub-Mechanismus eingreift – und die Modifikationen dann wirklich nach Upgrades regelmäßig überprüfen muss.
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 01.06.2023 11:50:33

JTH hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 11:46:07
Das kann schon funktionieren. Bei jedem Kernel- oder initrd-Update werden in / versionsunabhängige Symlinks angelegt, die immer auf das aktuellste zeigen:
Aber in der grub.cfg steht doch sowas hier:

Code: Alles auswählen

initrd	/boot/initrd.img-5.10.0-23-amd64
Da muss man doch dann selber Hand anlegen und jedes Mal wenn auch wieder ein update-grub ausgeführt wird wieder zurückändern? :?

Benutzeravatar
MSfree
Beiträge: 10753
Registriert: 25.09.2007 19:59:30

Re: grub.cfg vor überschreiben schützen

Beitrag von MSfree » 01.06.2023 12:13:55

JTH hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 11:46:07
Das kann schon funktionieren. Bei jedem Kernel- oder initrd-Update werden in / versionsunabhängige Symlinks angelegt, die immer auf das aktuellste zeigen:
Die symlinks haben meines Wissen eher historische Bedeutung, als man Rechner noch via Lilo gebootet hat. Für die Skripte zur Erstellung der grub.cfg haben die meines Wissens keine Bedeutung mehr.

JTH
Moderator
Beiträge: 3023
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: grub.cfg vor überschreiben schützen

Beitrag von JTH » 01.06.2023 12:35:59

cosinus hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 11:50:33
Aber in der grub.cfg steht doch sowas hier:

Code: Alles auswählen

initrd	/boot/initrd.img-5.10.0-23-amd64
Da muss man doch dann selber Hand anlegen und jedes Mal wenn auch wieder ein update-grub ausgeführt wird wieder zurückändern? :?
Du meintest ja, eine halbwegs statische, von Hand angelegte grub.cfg würde wegen Kernel- und initrd-Updates nicht funktionieren (weil dann eben diese Einträge nicht angepasst werden). Das kann aber schon funktionieren, wenn man in der grub.cfg eben die Symlinks benutzt, die werden an anderer Stelle auf den neuesten Kernel + initrd verschoben.

Ich hab mich also auf eine selbst angelegte grub.cfg bezogen. Das der update-grub-Mechanismus die Symlinks nicht benutzt, ist mir klar.

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Der Eintrag

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=false
wurde auskommentiert, folglich funktionierte 30_os-prober nicht, Einträge für sid fehlten völlig.
Ein

Code: Alles auswählen

dpkg-reconfigure -plow grub
mit einem „Ja“ bei der Frage nach os-prober schafft da Abhilfe.
Manchmal bekannt als Just (another) Terminal Hacker.

mat6937
Beiträge: 2953
Registriert: 09.12.2014 10:44:00

Re: grub.cfg vor überschreiben schützen

Beitrag von mat6937 » 01.06.2023 12:52:03

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Weiß jemand, wie ich meine grub.cfg vor Überschreibung schützen kann, ...
Meine selbst gebastelte ist schon fünfeinhalb Jahre alt, so alt wie meine Systeme und funktioniert.
Versuch mal mit dem i-flag (chattr):

Code: Alles auswählen

stat /boot/grub/grub.cfg

Code: Alles auswählen

chattr +i /boot/grub/grub.cfg

Code: Alles auswählen

:~$ lsattr /boot/grub/grub.cfg
----i--------e-- /boot/grub/grub.cfg

Code: Alles auswählen

stat /boot/grub/grub.cfg
Zuletzt geändert von mat6937 am 01.06.2023 14:33:03, insgesamt 1-mal geändert.

Benutzeravatar
thunder11
Beiträge: 1301
Registriert: 19.04.2023 09:08:30

Re: grub.cfg vor überschreiben schützen

Beitrag von thunder11 » 01.06.2023 14:06:31

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Ein Fehler, der schon auf dem Vorgängerrechner auftrat, waren Mehrfacheinträge für sid. Kurzfristig konnte
das durch erstellen einer Mini grub.cfg in sid /boot/grub behoben werden.
Ich vermute,mal, dass dabei OS-Prober noch aktiv war (ist) ?
Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Meine selbst gebastelte ist schon fünfeinhalb Jahre alt, so alt wie meine Systeme und funktioniert.
Da wirst du dann aber jedesmal die Kernel- Version händisch ändern ?
Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Die Einträge, die beim booten zur
Auswahl stehen, habe ich selbst geschrieben und die möchte ich erhalten.
Die Änderungen hast du in eine Datei in /etc/grub.d/xx_custom geschrieben ?
Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Kurzfristig konnte
das durch erstellen einer Mini grub.cfg in sid /boot/grub behoben werden
Fragen:
Willst du auf der SID- Partition auf keinen Fall einen Grub haben ?
Wenn das nicht so schlimm wäre, müsste man in beiden Systemen OS_Prober deaktivieren (oder Purgen)
Dann wäre im Start- Grub nur ein Verweis auf dein SID-System von Nöten.

Ich hatte selbst vor ca. 2 Jahren ein ähnliches Problem mit allerdings 2 Platten (OS-Porber aktiv).

Ich hatte dann hier im Forum dies gefunden und an meine Verhältnisse angepasst (auch zwei M.2 Disks) :
viewtopic.php?t=178120&hilit=chainloader

Etwas "Literatur" hat der TE dort verlinkt.

Seitdem habe ich Ruhe und dutzende neue Kernels und Grubs überlebt, ohne irgendetwas zu ändern.
OS-Prober ist auf beiden Systemen deaktiviert.
Nach meinem Verständnis sollte das auch auf einer Platte funktionieren.
Meine /etc/grub.d/40_custom :

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.
menuentry "Debian SID Xfce" {
	insmod ext2
	search --fs-uuid --no-floppy --set=root 26ea7215-fd95-461a-bd84-e341e87e09cc
	configfile /boot/grub/grub.cfg
	chainloader +1
}

Gerd50

Re: grub.cfg vor überschreiben schützen

Beitrag von Gerd50 » 01.06.2023 16:59:21

Vielen Dank für die vielen Antworten!

Zunächst einmal möchte ich dem user cosinus empfehlen, auf Beiträge nicht zu antworten, wenn du
cosinus nicht in der Lage bist richtig und vollständig zu lesen was ein Fragesteller, in diesem Falle ich,
geschrieben hat. Es fiel mir schon an anderer Stellen auf, das du dazu neigst anderen Nutzern die Eignung
für Debian Systeme ab zu sprechen, nur dich für das einzig schlaue Kerlchen dieser Welt hältst.

Das Thema grub.cfg habe schon einmal versucht zu lösen:

viewtopic.php?p=1253425#p1253425

und wie ich geschrieben habe, war es nur eine kurzfristige Lösung. Das Problem Mehrfacheinträge für sid
trat erneut auf. Eine Modifizierung der grub.cfg in sid brachte keine Abhilfe. Seitdem tausche ich wieder,
so wie schon seit Jahren, automatisch erstellte, fehlerhafte grub.cfg's gegen mein funktionierendes
Eigengewächs aus:

Code: Alles auswählen

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian testing' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-3775f247-f700-4ef8-ae2f-1e544dc6dd5a' {
	load_video
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	else
	  search --no-floppy --fs-uuid --set=root 3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	fi
	echo	'Loading Linux 5.10.0-3-amd64 ...'
	linux	/boot/vmlinuz-5.10.0-3-amd64 root=UUID=3775f247-f700-4ef8-ae2f-1e544dc6dd5a ro  
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initrd.img-5.10.0-3-amd64
}
submenu 'Erweiterte Optionen für Debian testing' $menuentry_id_option 'gnulinux-advanced-3775f247-f700-4ef8-ae2f-1e544dc6dd5a' {
        menuentry 'Debian testing' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-3-amd64-advanced-3775f247-f700-4ef8-ae2f-1e544dc6dd5a' {
	        load_video
	        insmod gzio
	        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	        insmod part_msdos
	        insmod ext2
	        set root='hd0,msdos5'
	        if [ x$feature_platform_search_hint = xy ]; then
	          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	        else
	          search --no-floppy --fs-uuid --set=root 3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	        fi
	        echo	'Loading Linux 5.10.0-3-amd64 ...'
	        linux	/boot/vmlinuz-5.10.0-3-amd64 root=UUID=3775f247-f700-4ef8-ae2f-1e544dc6dd5a ro  
	        echo	'Loading initial ramdisk ...'
	        initrd	/boot/initrd.img-5.10.0-3-amd64
	}
        menuentry 'Debian testing (Wiederherstellungsmodus)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-3-amd64-recovery-3775f247-f700-4ef8-ae2f-1e544dc6dd5a' {
	        load_video
	        insmod gzio
	        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	        insmod part_msdos
	        insmod ext2
	        set root='hd0,msdos5'
	        if [ x$feature_platform_search_hint = xy ]; then
	          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	        else
	          search --no-floppy --fs-uuid --set=root 3775f247-f700-4ef8-ae2f-1e544dc6dd5a
	        fi
	        echo	'Loading Linux 5.10.0-3-amd64 ...'
	        linux	/boot/vmlinuz-5.10.0-3-amd64 root=UUID=3775f247-f700-4ef8-ae2f-1e544dc6dd5a ro single 
	        echo	'Loading initial ramdisk ...'
	        initrd	/boot/initrd.img-5.10.0-3-amd64
	}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Debian sid' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-0a79419a-4b14-4c91-bf8f-0f793e3729ec' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  0a79419a-4b14-4c91-bf8f-0f793e3729ec
	else
	  search --no-floppy --fs-uuid --set=root 0a79419a-4b14-4c91-bf8f-0f793e3729ec
	fi
	echo	'Loading Linux 5.10.0-3-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-3-amd64 root=UUID=0a79419a-4b14-4c91-bf8f-0f793e3729ec ro quiet
	echo	'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-3-amd64
}
submenu 'Erweiterte Optionen für Debian sid' $menuentry_id_option 'osprober-gnulinux-advanced-0a79419a-4b14-4c91-bf8f-0f793e3729ec' {
        menuentry 'Debian sid' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-5.10.0-3-amd64--0a79419a-4b14-4c91-bf8f-0f793e3729ec' {
	        insmod part_msdos
	        insmod ext2
	        set root='hd0,msdos6'
	        if [ x$feature_platform_search_hint = xy ]; then
	          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  0a79419a-4b14-4c91-bf8f-0f793e3729ec
	        else
	          search --no-floppy --fs-uuid --set=root 0a79419a-4b14-4c91-bf8f-0f793e3729ec
	        fi
	        echo	'Loading Linux 5.10.0-3-amd64 ...'
                linux   /boot/vmlinuz-5.10.0-3-amd64 root=UUID=0a79419a-4b14-4c91-bf8f-0f793e3729ec ro quiet
	        echo	'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-5.10.0-3-amd64
	}
        menuentry 'Debian sid (Wiederherstellungsmodus)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-5.10.0-3-amd64-root=UUID=0a79419a-4b14-4c91-bf8f-0f793e3729ec ro single-0a79419a-4b14-4c91-bf8f-0f793e3729ec' {
	        insmod part_msdos
	        insmod ext2
	        set root='hd0,msdos6'
	        if [ x$feature_platform_search_hint = xy ]; then
	          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  0a79419a-4b14-4c91-bf8f-0f793e3729ec
	        else
	          search --no-floppy --fs-uuid --set=root 0a79419a-4b14-4c91-bf8f-0f793e3729ec
	        fi
	        echo    'Loading Linux 5.10.0-3-amd64 ...'
                linux   /boot/vmlinuz-5.10.0-3-amd64 root=UUID=0a79419a-4b14-4c91-bf8f-0f793e3729ec ro single
	        echo	'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-5.10.0-3-amd64
        }
}

### END /etc/grub.d/30_os-prober ###
Wie schon gesagt ist diese grub.cfg fünfeinhalb Jahre alt. Bei Kernel Updates habe ich Versionsnummern
manuell angepasst. Die Einträge erhalten, die im Grub Menü beim Start angezeigt werden, ist mein Anliegen.

Die User thunder11 und mat69337 haben das erkannt, Vorschläge gemacht die ich testen werde. Vielen
Dank dafür, ich werde berichten ob es klappt.

Eigentlich ist es nicht wirklich ein Problem, auf die Dauer eben nur immer wieder mal ein bischen ärgerlich.
Und auch meine Frau nutzt den Rechner. Sie hat eine Hirnblutung mit u.a der Folge Konzentrationsschwierigkeiten
erlitten. Ein Grub Menü mit Einträgen wie 'debian gnu linux testing bookworm on /dev/sda5 with kernel xxx'
überfordern sie. Wenn da aber steht 'testing' oder 'sid' weiß sie was das ist und was sie starten möchte :D

schwedenmann
Beiträge: 5528
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: grub.cfg vor überschreiben schützen

Beitrag von schwedenmann » 01.06.2023 17:58:54

Hallo

Ein Grub Menü mit Einträgen wie 'debian gnu linux testing bookworm on /dev/sda5 with kernel xxx'
überfordern sie. Wenn da aber steht 'testing' oder 'sid' weiß sie was das ist und was sie starten möchte :D
Dann reciht es doch os-prober in testing zu deaktivieren

In Testing ein 40-custom Eintrag mit sid + restliche erforderliche Einträge für den kernel und einen 2. Eintrag mit Testing und du hast 3 einträge
1. Von testing generierten Eintrag debian-testing blablabla
2. Sid
3. Testing

Wenn du dann noch den timeout auf 30s stellst und Sid als 1. startendes system bei grub einträgst sollte deine Frau locker Sid oder Testing erkken können.

mfg
schwedenmann

P.S.
Ich betreibe eine Multiboot -PC mit 10 Linuxen und nur einer Grubinstallation und dort ein 40_custom menü mit den manuellen Einträgen der kernel und der UUID der anderen Rootsysteme. Funktioniert prima, man muß halt nur bei den Nicht-grub-Systemen händisch die kernel + Initrdversion anpassen.

Benutzeravatar
thunder11
Beiträge: 1301
Registriert: 19.04.2023 09:08:30

Re: grub.cfg vor überschreiben schützen

Beitrag von thunder11 » 01.06.2023 18:18:07

hmm
Wie deine grub.cfg interpretiere, wird da aus 2 Dateien
aus /etc/grub.d/ ein eingelesen.
aus
/etc/grub.d/10_linux (normal)
und aus
/etc/grub.d/30_os-prober
Wobei Kernel 5.10.0-3 in Sid ja schon Schimmel angesetzt haben müsste
(wahrscheinlich wirst das bei einem Kernel-Update dann immer "liebevoll" pflegen)
die /etc/grub.d/30_os-prober ist bei mir natürlich leer.

Ob da ein Schreibschutz hilft, wage ich zu bezweifeln, denn entweder kann Root da auch nicht schreiben (keine Ahnung)
was dann aber mit ziemlicher Sicherheit zu einer Fehlermeldung und Abbruch der Installation führt.
Wenn nicht, musst du trotzdem die grub.cfg im Anschluss händisch bearbeiten, da es bei beiden Systemen
zu unterschiedlichen Zeiten Updates gibt.

Der Weg über einen zweiten Grub (beide Systeme ohne OS.Prober) wäre aus meiner Sicht, der Einfachste und vor allem wartungsfrei.
Ich meine irgendwo gelesen zu haben, dass das auch ohne "Chainloader" geht, finde es aber nicht mehr.
Vielleicht hat jemand anderes eine Idee.

Im Anhang mal meine grub.cfg NoPaste-Eintrag41917

Ergibt:
4072

Benutzeravatar
grubenlicht
Beiträge: 419
Registriert: 10.06.2021 22:35:56

Re: grub.cfg vor überschreiben schützen

Beitrag von grubenlicht » 01.06.2023 19:10:28

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Wenn Grub bzw. initramfs oder systemd aktualisiert werden, wird jedesmal eine neue grub.cfg generiert
und jedesmal erhalte ich seit gefühlten Ewigkeiten dabei eine Datei mit falschen Inhalten. Installiert habe
ich Debian testing, daneben auf derselben Platte sid, beide xfce. Grub ist in testing installiert.
da wäre zunächst mal zu klären, in welchem Modus gebootet wird, aus diesem Wirrwar schließe ich mal auf CSM, darüberhinaus womöglich bei jeder Installation grub jedesmal in ein und denselben MBR. (Falls das so ist, kannst du die Katastrophe nur "reparieren", indem du entscheidest, welches System den grub regieren soll, bei allen anderen verbannst du grub z.B. in die "/", also auf /dev/sdxy)
Die Einträge, die beim booten zur
Auswahl stehen, habe ich selbst geschrieben und die möchte ich erhalten.
sowas macht man gewöhnlich mit einem stand-alone grub, welcher von den Steuerdateien einer Distri nicht abhängig ist.

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 01.06.2023 19:43:18

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 16:59:21
Zunächst einmal möchte ich dem user cosinus empfehlen, auf Beiträge nicht zu antworten, wenn du
cosinus nicht in der Lage bist richtig und vollständig zu lesen was ein Fragesteller, in diesem Falle ich,
geschrieben hat. Es fiel mir schon an anderer Stellen auf, das du dazu neigst anderen Nutzern die Eignung
für Debian Systeme ab zu sprechen, nur dich für das einzig schlaue Kerlchen dieser Welt hältst.
Und du solltest dich mal an die Netiquette halten. Gehts noch?
Du hast da nun mal Vorstellungen die so nicht bzw sehr schwierig umzusetzen sind und du hast selbst ausgesagt, dass du kein Experte bist.

BTW: Der Computer ist auch keine Schreibmaschine mehr, ein Zeilenumbruch passiert automatisch. Da musst du nicht mehr für dein visuelles Ende der Zeile ein ENTER reinknallen. :facepalm:

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 16:59:21
Wie schon gesagt ist diese grub.cfg fünfeinhalb Jahre alt.
Klar doch. Anno 2018 war ja auch schon
initrd /boot/initrd.img-5.10.0-3-amd64
da :facepalm: :mrgreen:
Zuletzt geändert von cosinus am 01.06.2023 20:06:01, insgesamt 1-mal geändert.

mat6937
Beiträge: 2953
Registriert: 09.12.2014 10:44:00

Re: grub.cfg vor überschreiben schützen

Beitrag von mat6937 » 01.06.2023 19:59:41

thunder11 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 18:18:07
..., denn entweder kann Root da auch nicht schreiben (keine Ahnung) ...
Bei gesetztem i-flag (+i) kann auch root nicht schreiben/ändern. Wenn man das wieder zulassen will, muss man den Schreibschutz _vorher_ aufheben (mit chattr -i <...>).

Gerd50

Re: grub.cfg vor überschreiben schützen

Beitrag von Gerd50 » 01.06.2023 21:43:50

@cosinus, ich habe auf deinen ersten Beitrag mit konstruktiver Kritik reagiert, da ich es als arrogant
und überheblich empfinde, wenn du auf meinen Beitrag antwortest obwohl du nicht richtig gelesen hast,
meine Frage nicht verstanden hast.

Mit konstruktiver Kritik habe ich reagiert, da ich es als dummdreist empfinde, wenn du, obwohl nichts verstanden, schreibst, du hältst mich für ungeeignet Systeme wie testing oder gar sid überhaupt zu betreiben.

Und als dummdreist empfinde ich, wenn du dir anmaßt, Kritik an meiner Dualboot Installation zu üben.
Das geht dich einen Scheiß an, war und ist nicht Thema!

So, ich merke, ich könnte noch ein wenig weiter ausholen, lasse es aber im Sinne von

viewtopic.php?t=186543

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 01.06.2023 21:53:38

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 21:43:50
@cosinus, ich habe auf deinen ersten Beitrag mit konstruktiver Kritik reagiert, da ich es als arrogant
und überheblich empfinde, wenn du auf meinen Beitrag antwortest obwohl du nicht richtig gelesen hast,
meine Frage nicht verstanden hast.
Aha. Nette Auffassung von "konstruktiver Kritik":

...nur dich für das einzig schlaue Kerlchen dieser Welt hältst.

:roll:

rjh

Re: grub.cfg vor überschreiben schützen

Beitrag von rjh » 01.06.2023 23:17:19

Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 10:57:13
Ein weiterer Grund, warum ich meine grub.cfg schützen möchte, ist grub. In der letzten Zeit gab es zwei
Aktualisierungen, beide male fuschte grub dabei an der /etc/default/grub rum.

Der Eintrag

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=false
wurde auskommentiert, folglich funktionierte 30_os-prober nicht, Einträge für sid fehlten völlig.
Darauf hatte ich in viewtopic.php?t=186781 jetzt schon mehrmals hingewiesen. Ich frag mich, warum da nicht mehr, wie früher in Debian absolut üblich, bei der Aktualisierung nachgefragt wird, ob man seine ursprüngliche Konfigurationsdatei (hier: /etc/default/grub) behalten will. Und komischerweise scheint das auch niemand weiter zu stören außer uns zwei. Meines Erachtens ist das ein Bug, der von Debian behoben gehört.

Benutzeravatar
thunder11
Beiträge: 1301
Registriert: 19.04.2023 09:08:30

Re: grub.cfg vor überschreiben schützen

Beitrag von thunder11 » 02.06.2023 00:10:16

So das hat mal wieder meinen Spieltrieb geweckt :facepalm:

Habe meinen Vorschlag in eine VM übertragen.
war etwas Tricky, da ich in der VM vorher Debiangrml-rescueboot installiert hatte, Os-Prober auch noch
Müll rein geschrieben hatte. Die Auswahlen von grml-rescueboot wollten aber nicht starten.

Also erstmal mit ner normalen Netinst-CD Xfce auf den freien Platz der *.vdi installiert (Vorher vergrößert)
Ergebniss: nur noch die Neuinstallation startete. :oops:

Dann erstmal die andere Hälfte der vdi gemountet, dort die fstab (swap hatte falsch UUID) editiert
in XFCE os-prober gepurgt / update grub / ---> Neustart
jetzt kam ich in KDE wenigsten in den Rescue- Mode :roll:

Dann wie in XFCE alles gepurged / grml-rescueboot ebenso.
in xfce die /etc/grub.d//etc/grub.d/40_custom wie oben eingetragen (nur die UUDI geändert /
XFCE startet als erstes)

Und : voilà ---> Es läuft :mrgreen: :mrgreen:
Einzige kleines Manko : KDE denkt vor dem Start ca. 30 Sekunden nach, bevor es bootet.
Da hab ich jetzt aber keine Lust mehr, dem auf den Grund zu gehen.
Wie auch immer:
Jetzt hab ich ne schicke Dual-Boot VM -- Was es so alles gibt :wink:

Edit:

Habe das so gemacht, weil die Konfiguration in einer VM (=eine Platte) ja deiner Konstellation entsprechen dürfte.
Das "Nachdenken" liegt eventuell an der Syntax in der /etc/grub.d/40_custom. Da werde ich
mal bei Gelegenheit forschen.

Benutzeravatar
GregorS
Beiträge: 2596
Registriert: 05.06.2008 09:36:37
Wohnort: Freiburg
Kontaktdaten:

Re: grub.cfg vor überschreiben schützen

Beitrag von GregorS » 03.06.2023 10:11:53

cosinus hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 19:43:18
Gerd50 hat geschrieben: ↑ zum Beitrag ↑
01.06.2023 16:59:21
Zunächst einmal möchte ich dem user cosinus empfehlen, auf Beiträge nicht zu antworten, wenn du
cosinus nicht in der Lage bist richtig und vollständig zu lesen was ein Fragesteller, in diesem Falle ich,
geschrieben hat. Es fiel mir schon an anderer Stellen auf, das du dazu neigst anderen Nutzern die Eignung
für Debian Systeme ab zu sprechen, nur dich für das einzig schlaue Kerlchen dieser Welt hältst.
Und du solltest dich mal an die Netiquette halten. Gehts noch?
Welchen Punkt welcher Netiquette meinst Du?

Gruß

Gregor
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 03.06.2023 10:23:11

GregorS hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 10:11:53
Welchen Punkt welcher Netiquette meinst Du?
Findest du, dass Formulierungen wie
nur dich für das einzig schlaue Kerlchen dieser Welt hältst.
die Netiquette einhalten? Wenn haben wir da wohl völlig unterschiedliche Auffassungen.

Benutzeravatar
GregorS
Beiträge: 2596
Registriert: 05.06.2008 09:36:37
Wohnort: Freiburg
Kontaktdaten:

Re: grub.cfg vor überschreiben schützen

Beitrag von GregorS » 03.06.2023 11:06:25

cosinus hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 10:23:11
GregorS hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 10:11:53
Welchen Punkt welcher Netiquette meinst Du?
Findest du, dass Formulierungen wie
nur dich für das einzig schlaue Kerlchen dieser Welt hältst.
die Netiquette einhalten? Wenn haben wir da wohl völlig unterschiedliche Auffassungen.
Ich frage Dich noch einmal: Welchen Punkt welcher Netiquette meinst Du?

Bitte antworte konkret. Z.B. mit einem Link.

Gruß

Gregor
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])

Benutzeravatar
cosinus
Beiträge: 3423
Registriert: 08.02.2016 13:44:11
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Bremen

Re: grub.cfg vor überschreiben schützen

Beitrag von cosinus » 03.06.2023 12:22:36

GregorS hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 11:06:25
Ich frage Dich noch einmal: Welchen Punkt welcher Netiquette meinst Du?
Gegenfrage: wo verstößt denn meine erste Antwort gegen die Netiquette bzw was war daran so unfreundlich, dass ich mit solchem Unrat beworfen werden darf?
als arrogant und überheblich...
ich es als dummdreist empfinde...
obwohl nichts verstanden,...
Das geht dich einen Scheiß an, war und ist nicht Thema!

Benutzeravatar
grubenlicht
Beiträge: 419
Registriert: 10.06.2021 22:35:56

Re: grub.cfg vor überschreiben schützen

Beitrag von grubenlicht » 03.06.2023 12:35:04

ein toller Faden (1+)
Statt mal zu klären, warum es dieses Durcheinander gibt – z.B. mit einer RESULTS.txt aus dem bootinfoscript – , ts,ts.
Und meine Meinung zur Fragestellung: grub.cfg "festnageln" -> vollkommener Unsinn, wenn, dann eben ein stand-alone grub.

Benutzeravatar
GregorS
Beiträge: 2596
Registriert: 05.06.2008 09:36:37
Wohnort: Freiburg
Kontaktdaten:

Re: grub.cfg vor überschreiben schützen

Beitrag von GregorS » 03.06.2023 12:39:17

cosinus hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 12:22:36
GregorS hat geschrieben: ↑ zum Beitrag ↑
03.06.2023 11:06:25
Ich frage Dich noch einmal: Welchen Punkt welcher Netiquette meinst Du?
Gegenfrage: ...
Du kannst also noch nicht einmal auf eine konkrete Frage konkret antworten. Alles klar.
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])

Antworten