reboot modifiziert /boot/grub/grub.cfg ?!

[Ulli Horlacher]

Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!

***@mux22:~# cat /etc/default/grub.d/99_mux.cfg
GRUB_DISTRIBUTOR="`lsb_release -ds` Xfce /sw"

***@mux22:~# grep ^menuentry /boot/grub/grub.cfg
menuentry 'Linux Mint 22.1 Xfce /sw GNU/Linux' --class linux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-13168cc9-1fde-4d4a-8af1-fc91da4f12db' {


(Erste Ungereimtheit: wo kommt der Zusatz "GNU/Linux" her?)


***@mux22:~# ll /boot/grub/grub.cfg
-rw-r--r-- root root 9,622 2025-02-21 09:48:06 /boot/grub/grub.cfg

***@mux22:~# reboot
(...)
***@mux22:~# grep ^menuentry /boot/grub/grub.cfg
menuentry 'Linux Mint 22.1 Xfce' --class linux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-13168cc9-1fde-4d4a-8af1-fc91da4f12db' {

***@mux22:~# ll /boot/grub/grub.cfg
-rw-r--r-- root root 9,538 2025-02-21 09:51:38 /boot/grub/grub.cfg


Im grub boot menu sehe ich dann auch "Linux Mint 22.1 Xfce" und nicht
"Linux Mint 22.1 Xfce /sw GNU/Linux" wie zuvor.

==> reboot schreibt ein neues /boot/grub/grub.cfg! WTF?!

Fuehre ich einen harten reset statt software-reboot aus, bleibt meine
GRUB_DISTRIBUTOR config erhalten, ebenso bei:

***@mux22:~# chattr +i /boot/grub/grub.cfg
***@mux22:~# reboot
(...)
***@mux22:~# grep ^menuentry /boot/grub/grub.cfg
menuentry 'Linux Mint 22.1 Xfce /sw GNU/Linux' --class linux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-13168cc9-1fde-4d4a-8af1-fc91da4f12db' {


Also fuehrt reboot noch irgendwelche Skripte aus!
Ist das eine neue systemd Bosheit?

[Marc Haber]

Post by Ulli Horlacher
Ist das eine neue systemd Bosheit?

systemd hat seinen eigenen Bootmanager, systemd-boot. Dann gäbe es auf
Deinem System keinen grub mehr.

[Tim Ritberg]

Post by Marc Haber

Post by Ulli Horlacher
Ist das eine neue systemd Bosheit?

systemd hat seinen eigenen Bootmanager, systemd-boot. Dann gäbe es auf
Deinem System keinen grub mehr.

muahaha, ist denn heute schon Freitag??? :-D

Tim

[Peter J. Holzer]

Post by Tim Ritberg
muahaha, ist denn heute schon Freitag??? :-D

Ja. ;-)

hp

[Arno Welzel]

Post by Tim Ritberg

Post by Marc Haber

Post by Ulli Horlacher
Ist das eine neue systemd Bosheit?

systemd hat seinen eigenen Bootmanager, systemd-boot. Dann gäbe es auf
Deinem System keinen grub mehr.

muahaha, ist denn heute schon Freitag??? :-D

Ja, heute ist Freitag ;-)

<https://wiki.archlinux.de/title/Systemd-boot>

[Tim Ritberg]

Post by Arno Welzel

Post by Tim Ritberg

Post by Marc Haber

Post by Ulli Horlacher
Ist das eine neue systemd Bosheit?

systemd hat seinen eigenen Bootmanager, systemd-boot. Dann gäbe es auf
Deinem System keinen grub mehr.

muahaha, ist denn heute schon Freitag??? :-D

Ja, heute ist Freitag ;-)
<https://wiki.archlinux.de/title/Systemd-boot>

Ich weiss, daher:
Fuck the system! :-D

Tim

[Ulli Horlacher]

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!
GRUB_DISTRIBUTOR="`lsb_release -ds` Xfce /sw"
menuentry 'Linux Mint 22.1 Xfce /sw GNU/Linux' --class linux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-13168cc9-1fde-4d4a-8af1-fc91da4f12db' {
(Erste Ungereimtheit: wo kommt der Zusatz "GNU/Linux" her?)

Ok, das hab ich gefunden in /etc/grub.d/10_linux

case ${GRUB_DISTRIBUTOR} in
Ubuntu|Kubuntu)
OS="${GRUB_DISTRIBUTOR}"
;;
*)
OS="${GRUB_DISTRIBUTOR} GNU/Linux"
;;
esac

[Marc Haber]

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!
GRUB_DISTRIBUTOR="`lsb_release -ds` Xfce /sw"
menuentry 'Linux Mint 22.1 Xfce /sw GNU/Linux' --class linux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-13168cc9-1fde-4d4a-8af1-fc91da4f12db' {
(Erste Ungereimtheit: wo kommt der Zusatz "GNU/Linux" her?)

Ok, das hab ich gefunden in /etc/grub.d/10_linux
case ${GRUB_DISTRIBUTOR} in
Ubuntu|Kubuntu)
OS="${GRUB_DISTRIBUTOR}"
;;
*)
OS="${GRUB_DISTRIBUTOR} GNU/Linux"
;;
esac

Also ist der grub in Mint schlecht angepasst. Gemessen an der
Lieblogigkeit, die ich bisher von Mint gesehen habe, wundert mich das
nicht.

/boot/grub/grub.cfg enthält Informationen über den nächsten Boot, also
könnte man das schreiben um z.B. einen Fallback-Eintrag zu aktivieren
falls der Boot schief läuft. Das ist auch kein Problem weil man als
Endbenutzer eher nicht in dieser Datei herumfuhrwerkt, sie ist quasi
Objektcode.

Grüße
Marc

[Ulli Horlacher]

Post by Marc Haber

Post by Ulli Horlacher
Ok, das hab ich gefunden in /etc/grub.d/10_linux
case ${GRUB_DISTRIBUTOR} in
Ubuntu|Kubuntu)
OS="${GRUB_DISTRIBUTOR}"
;;
*)
OS="${GRUB_DISTRIBUTOR} GNU/Linux"
;;
esac

Also ist der grub in Mint schlecht angepasst. Gemessen an der
Lieblogigkeit, die ich bisher von Mint gesehen habe, wundert mich das
nicht.

Bisher hatte ich keinerlei Probleme mit Mint.
Das obige erklaert nur den Zusatz "GNU/Linux", nicht aber wo und warum
/boot/grub/grub.cfg beim reboot(!) komplett neu geschrieben wird und warum
da ein ganz anderer Menue-Eintrag gemacht wird.

Post by Marc Haber
/boot/grub/grub.cfg enthält Informationen über den nächsten Boot, also
könnte man das schreiben um z.B. einen Fallback-Eintrag zu aktivieren
falls der Boot schief läuft.

Das steht auch drin.

[Marc Haber]

Post by Ulli Horlacher

Post by Marc Haber

Post by Ulli Horlacher
Ok, das hab ich gefunden in /etc/grub.d/10_linux
case ${GRUB_DISTRIBUTOR} in
Ubuntu|Kubuntu)
OS="${GRUB_DISTRIBUTOR}"
;;
*)
OS="${GRUB_DISTRIBUTOR} GNU/Linux"
;;
esac

Also ist der grub in Mint schlecht angepasst. Gemessen an der
Lieblogigkeit, die ich bisher von Mint gesehen habe, wundert mich das
nicht.

Bisher hatte ich keinerlei Probleme mit Mint.

Das habe ich auch nicht behauptet. Ich habe nur eine gewisse fehlende
Liebe zu Details beobachtet, sowohl aus meinen eigenen Erfahrungen mit
Mint als auch auf Deinen.

Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Post by Ulli Horlacher
Das obige erklaert nur den Zusatz "GNU/Linux", nicht aber wo und warum
/boot/grub/grub.cfg beim reboot(!) komplett neu geschrieben wird und warum
da ein ganz anderer Menue-Eintrag gemacht wird.

Vermutlich aus dem unteren Grund.

Post by Ulli Horlacher

Post by Marc Haber
/boot/grub/grub.cfg enthält Informationen über den nächsten Boot, also
könnte man das schreiben um z.B. einen Fallback-Eintrag zu aktivieren
falls der Boot schief läuft.

Das steht auch drin.

Kein Widerspruch.

Die grub.cfg wird immer komplett neu geschrieben. Es wird nicht darin
herumgepatcht. So sind die Skripts rund um grub halt gemacht. grub.cfg
ist Objektcode. Ich gucke da auch immer nur rein wenn irgendwas schief
geht.

Grüße
Marc

[Ulli Horlacher]

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Ich will der snap-Seuche entkommen.

Post by Marc Haber

Post by Ulli Horlacher
Das obige erklaert nur den Zusatz "GNU/Linux", nicht aber wo und warum
/boot/grub/grub.cfg beim reboot(!) komplett neu geschrieben wird und warum
da ein ganz anderer Menue-Eintrag gemacht wird.

Vermutlich aus dem unteren Grund.
Die grub.cfg wird immer komplett neu geschrieben. Es wird nicht darin
herumgepatcht. So sind die Skripts rund um grub halt gemacht. grub.cfg
ist Objektcode. Ich gucke da auch immer nur rein wenn irgendwas schief
geht.

Die Frage warum grub.cfg von reboot(!) neu geschrieben wird und warum es
dazu nicht update-grub aufruft. Letzteres erzeugt ein grub.cfg nach den
von mir vorgegeben config.
Das grub.cfg von reboot sieht anders aus.
Siehe mein Original-Posting.

[Tim Ritberg]

Post by Ulli Horlacher
Die Frage warum grub.cfg von reboot(!) neu geschrieben wird und warum es
dazu nicht update-grub aufruft. Letzteres erzeugt ein grub.cfg nach den
von mir vorgegeben config.
Das grub.cfg von reboot sieht anders aus.
Siehe mein Original-Posting.

Tja, da musst du systemd fragen.
Ein Devuan packt grub.cfg nicht an ;-)

Ansonsten wahrscheinlich wegen solcher Sachen:
system/multi-user.target.wants/grub-common.service:ExecStart=grub-editenv
/boot/grub/grubenv unset recordfail


Tim

[Marc Haber]

Post by Tim Ritberg

Post by Ulli Horlacher
Die Frage warum grub.cfg von reboot(!) neu geschrieben wird und warum es
dazu nicht update-grub aufruft. Letzteres erzeugt ein grub.cfg nach den
von mir vorgegeben config.
Das grub.cfg von reboot sieht anders aus.
Siehe mein Original-Posting.

Tja, da musst du systemd fragen.

Was hat Mint für eine Verbindung zwischen systemd und grub eingebaut?

Post by Tim Ritberg
Ein Devuan packt grub.cfg nicht an ;-)

Ein Debian auch nicht.

Post by Tim Ritberg
system/multi-user.target.wants/grub-common.service:ExecStart=grub-editenv
/boot/grub/grubenv unset recordfail

Es ist ja sicher systemds Schuld, wenn grub-common einen Service
hinterlegt. Und postfix' Schuld dass Du Spam bekommst.

[Tim Ritberg]

Post by Marc Haber

Post by Tim Ritberg

Post by Ulli Horlacher
Die Frage warum grub.cfg von reboot(!) neu geschrieben wird und warum es
dazu nicht update-grub aufruft. Letzteres erzeugt ein grub.cfg nach den
von mir vorgegeben config.
Das grub.cfg von reboot sieht anders aus.
Siehe mein Original-Posting.

Tja, da musst du systemd fragen.

Was hat Mint für eine Verbindung zwischen systemd und grub eingebaut?

Eher Ubuntu!

Post by Marc Haber

Post by Tim Ritberg
system/multi-user.target.wants/grub-common.service:ExecStart=grub-editenv
/boot/grub/grubenv unset recordfail

Es ist ja sicher systemds Schuld, wenn grub-common einen Service
hinterlegt. Und postfix' Schuld dass Du Spam bekommst.

Und was treibt dieser systemd-Service da mit grub-editenv?

Tim

[Marc Haber]

Post by Tim Ritberg
Und was treibt dieser systemd-Service da mit grub-editenv?

Das musst Du denjenigen fragen der ihn geschrieben hat.

[Paul Muster]

Post by Marc Haber

Post by Tim Ritberg
Und was treibt dieser systemd-Service da mit grub-editenv?

Das musst Du denjenigen fragen der ihn geschrieben hat.

Muss man das, ist systemd mittlerweile so ver-dongle-t? Kann man es
nicht selbst in den Skripten nachlesen?


mfG Paul

[Peter J. Holzer]

Post by Paul Muster

Post by Marc Haber

Post by Tim Ritberg
Und was treibt dieser systemd-Service da mit grub-editenv?

Das musst Du denjenigen fragen der ihn geschrieben hat.

Muss man das, ist systemd mittlerweile so ver-dongle-t? Kann man es
nicht selbst in den Skripten nachlesen?

Natürlich kann man das.

Der Satz

Post by Paul Muster

Post by Marc Haber
Das musst Du denjenigen fragen der ihn geschrieben hat.

bedeutet selten, dass man denjenigen fragen muss.

Er bedeutet, dass derjenige dafür verantwortlich ist, und nicht wer auch
immer vom "Du" beschuldigt wird.

Oder ganz im Klartext:

Dafür ist nicht Systemd oder die Autoren von Systemd verantwortlich,
sondern die Person, die dieses spezifische Service geschrieben hat.

hp

[Ralph Aichinger]

Post by Ulli Horlacher

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Ich will der snap-Seuche entkommen.

Das Original ist und bleibt Debian ;)

Nein, ernsthaft: Man muß bei Debian nicht alles mögen, aber nichts geht
über die Transparenz und Nachvollziehbarkeit von Debian. Dafür bin ich
gerne mal ein paar Monate hinten, oder verwende wenn es tagesaktuell
sein soll "unstable", aber allein das Glücksgefühl, wenn ich im Debian
BTS Bugs ohne Marketinggeschwurbel, aus Geschäftsinteressen getriebenem
wegschieben oder Verschleierungsinteresse nachlesen kann, das macht es
mir wert.

Oder wenn ich im Archiv von debian-devel nachlesen kann, wie bestimmte
Entscheidungen getroffen oder diskutiert worden sind.

/ralph

[Tim Ritberg]

Post by Ralph Aichinger

Post by Ulli Horlacher

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Ich will der snap-Seuche entkommen.

Das Original ist und bleibt Debian ;)
Nein, ernsthaft: Man muß bei Debian nicht alles mögen, aber nichts geht
über die Transparenz und Nachvollziehbarkeit von Debian. Dafür bin ich
gerne mal ein paar Monate hinten, oder verwende wenn es tagesaktuell
sein soll "unstable", aber allein das Glücksgefühl, wenn ich im Debian
BTS Bugs ohne Marketinggeschwurbel, aus Geschäftsinteressen getriebenem
wegschieben oder Verschleierungsinteresse nachlesen kann, das macht es
mir wert.

Ich habe weiterhin Xubuntu auf dem Desktop und Ubuntu auf den meisten
Servern. Snap habe ich einfach herunterschmissen.

Auf einigen kleinen VMs habe ich Devuan.

Tim

[Ralph Aichinger]

Post by Tim Ritberg
Ich habe weiterhin Xubuntu auf dem Desktop und Ubuntu auf den meisten
Servern. Snap habe ich einfach herunterschmissen.

Ich finde Ubuntu keineswegs schlecht. Ich hab in meinem letzten Job
fast ausschließlich Ubuntu gehabt, und wegen der Einheitlichkeit dann
die verbliebenen 2 Debian-Systeme auf Ubuntu umgestellt. Aber:
Für mich geht nichts über die Klarheit von Debian, immer zu wissen
was wie warum gemacht wird.

Post by Tim Ritberg
Auf einigen kleinen VMs habe ich Devuan.

Wie bei Xubuntu oder Mint habe ich da für mich persönlich -- und
für andere mag die Bilanz da anders aussehen -- Angst, dass wegen einer
relativ kleinen Änderung man nie genau weiß ob, wenn was bricht,
das ursächlich wegen dieser kleinen Änderungen (andere Oberfläche,
anderes Init-System) ist, oder wegen zufälliger anderer Abweichungen,
die letztendlich aus dem Nischenstatus dieser Distributionen
(zu wenige Leute testen, zu wenige Leute dokumentieren, zu wenige
Leute maintainen) resultieren.

Gerade wenn das Programm oder System mit dem man selbst Probleme
hat (z.B. Ethernet-Bonding, die ARM-Architektur oder die Python-Library
für irgendein Protokoll) nicht besonders verbreitet ist. Denn dann
weiß man nicht: Geht das schon in Vanilla Debian nicht, oder bricht
spezifisch was bei Xubuntu.

/ralph

[Tim Ritberg]

Post by Ralph Aichinger
Wie bei Xubuntu oder Mint habe ich da für mich persönlich -- und
für andere mag die Bilanz da anders aussehen -- Angst, dass wegen einer
relativ kleinen Änderung man nie genau weiß ob, wenn was bricht,
das ursächlich wegen dieser kleinen Änderungen (andere Oberfläche,
anderes Init-System) ist, oder wegen zufälliger anderer Abweichungen,
die letztendlich aus dem Nischenstatus dieser Distributionen
(zu wenige Leute testen, zu wenige Leute dokumentieren, zu wenige
Leute maintainen) resultieren.

Auf dieser Kiste hier habe ich das Xubuntu 5 Jahre laufen, das Userhome
ist mit 10 Jahren noch älter und kommt von der Xubuntu-Kiste davor.
Beide liefen recht problemlos und mit der non-LTS-Version.

Mint aber ich vor 10 Jahren meinen Eltern auf die neue Kiste gepackt,
nach Windows XP.
Am Anfang sah Mint wirklich crappy aus, ist ja auch nur an Ubuntu dran
geflanscht. Sieht man auch schön bei Upgrades, wenn es den Beweis in
/etc/issue vernichtet, dass es ein Ubuntu ist ;-)
Aber ansonsten läuft das Mint gut.

Post by Ralph Aichinger
Gerade wenn das Programm oder System mit dem man selbst Probleme
hat (z.B. Ethernet-Bonding, die ARM-Architektur oder die Python-Library
für irgendein Protokoll) nicht besonders verbreitet ist. Denn dann
weiß man nicht: Geht das schon in Vanilla Debian nicht, oder bricht
spezifisch was bei Xubuntu.Xubuntu ist auch nur ein Ubuntu. Das xfce spielt doch keine Rolle bei

Lowlevel-Systemzeugs.

Tim

[Ralph Aichinger]

Post by Tim Ritberg

Post by Ralph Aichinger
weiß man nicht: Geht das schon in Vanilla Debian nicht, oder bricht
spezifisch was bei Xubuntu.Xubuntu ist auch nur ein Ubuntu. Das xfce spielt doch keine Rolle bei

Lowlevel-Systemzeugs.

Das fällt mir hier nicht zum ersten mal auf: Manchmal scheint
bei deinem Quoting was nicht hinzuhauen, dass mein Newsreader
Teile die eigentlich von dir stammen als gequotet kennzeichnet.

Zur Sache: Ist Xubuntu wirklich "nur Ubuntu"? Oder gibt es nicht doch
kleine Fehler, Seiteneffekte oder Artefakte von zu wenig Tests, die
bewirken dass sich Xubuntu manchmal anders verhält?

/ralph

[Tim Ritberg]

Post by Ralph Aichinger

Post by Tim Ritberg

Post by Ralph Aichinger
weiß man nicht: Geht das schon in Vanilla Debian nicht, oder bricht
spezifisch was bei Xubuntu.Xubuntu ist auch nur ein Ubuntu. Das xfce spielt doch keine Rolle bei

Lowlevel-Systemzeugs.

Das fällt mir hier nicht zum ersten mal auf: Manchmal scheint
bei deinem Quoting was nicht hinzuhauen, dass mein Newsreader
Teile die eigentlich von dir stammen als gequotet kennzeichnet.

Sorry, zeigt mir TB beim Erstellen nicht an.

Post by Ralph Aichinger
Zur Sache: Ist Xubuntu wirklich "nur Ubuntu"? Oder gibt es nicht doch
kleine Fehler, Seiteneffekte oder Artefakte von zu wenig Tests, die
bewirken dass sich Xubuntu manchmal anders verhält?
/ralph

Xubuntu ist Ubuntu + apt install xfce4
Ich könnte auch auf KDE wechseln.

Tim

[Claus Reibenstein]

Post by Ralph Aichinger

Post by Ulli Horlacher

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Ich will der snap-Seuche entkommen.

Das Original ist und bleibt Debian ;)

Ich mag snap auch nicht und nehme deshalb Debian.

Gruß
Claus

[Sieghard Schicktanz]

Hallo Marc,

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

...

Post by Marc Haber
Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Du empfiehlst also Ubuntu? (Trotz dessen, daß auch Du Dich schon recht
ablehnend dagegen geäußert hast.)

...

Post by Marc Haber

Post by Ulli Horlacher

Post by Marc Haber
/boot/grub/grub.cfg enthält Informationen über den nächsten Boot, also

Die "grub.cfg" _definiert_ das Verhalten des Systemlade-Systems namens
"grub" für die Funktion des Ladevorgangs des Zielsystems, _statisch_.
Für kurzzeitige Anpassungen gibt es Hilfsmechanismen wie z.B. die Datei
"grubenv".
...

Post by Marc Haber
Die grub.cfg wird immer komplett neu geschrieben. Es wird nicht darin

Das ist eine eigenwillige Verfahrensweise eines spezifischn Systems und so
nicht in der Konstruktion von "grub" vorgesehen.

Post by Marc Haber
herumgepatcht. So sind die Skripts rund um grub halt gemacht. grub.cfg
ist Objektcode. Ich gucke da auch immer nur rein wenn irgendwas schief

Nein, die Skripts rund um grub sind _nicht_ so gemacht, daß die "grub.cfg"
ständig neu geschrieben werden soll. "grub.cfg" ist _kein_ "Objektcode",
sondern ein _Script_ für den grub-internen Befehlsinterpreter.
Allenfalls kannst Du noch der Ansicht sein, _jedes_ Script eines
Befehlsinterpreters, also z.B. auch der bash, wäre Objektcode, und müßte
dzf. nach (!) jeder Verwendung neu geschrieben werden.
Ich meine, wenn ein System sowas macht, dann lag hier jemand reichlich
schief.

[Marc Haber]

Post by Sieghard Schicktanz

Post by Marc Haber

Post by Ulli Horlacher
Bisher hatte ich keinerlei Probleme mit Mint.

...

Post by Marc Haber
Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Du empfiehlst also Ubuntu?

Ubuntu ist nicht das Original. Für manche Anwendungen ist es trotzdem
keine verkehrte Entscheidung.

Post by Sieghard Schicktanz
Die "grub.cfg" _definiert_ das Verhalten des Systemlade-Systems namens
"grub" für die Funktion des Ladevorgangs des Zielsystems, _statisch_.
Für kurzzeitige Anpassungen gibt es Hilfsmechanismen wie z.B. die Datei
"grubenv".

Nicht notwendigerweise.

Post by Sieghard Schicktanz

Post by Marc Haber
Die grub.cfg wird immer komplett neu geschrieben. Es wird nicht darin

Das ist eine eigenwillige Verfahrensweise eines spezifischn Systems und so
nicht in der Konstruktion von "grub" vorgesehen.

Aber natürlich ist es das.

Post by Sieghard Schicktanz

Post by Marc Haber
herumgepatcht. So sind die Skripts rund um grub halt gemacht. grub.cfg
ist Objektcode. Ich gucke da auch immer nur rein wenn irgendwas schief

Nein, die Skripts rund um grub sind _nicht_ so gemacht, daß die "grub.cfg"
ständig neu geschrieben werden soll. "grub.cfg" ist _kein_ "Objektcode",
sondern ein _Script_ für den grub-internen Befehlsinterpreter.
Allenfalls kannst Du noch der Ansicht sein, _jedes_ Script eines
Befehlsinterpreters, also z.B. auch der bash, wäre Objektcode, und müßte
dzf. nach (!) jeder Verwendung neu geschrieben werden.
Ich meine, wenn ein System sowas macht, dann lag hier jemand reichlich
schief.

Ich sehe das anders.

[Sieghard Schicktanz]

Hallo Marc,

Post by Marc Haber

Post by Sieghard Schicktanz

Post by Marc Haber
Das Original zu nehmen ist Dir vermutlich zu einfach, nehme ich an?

Du empfiehlst also Ubuntu?

Ubuntu ist nicht das Original. Für manche Anwendungen ist es trotzdem
keine verkehrte Entscheidung.

Im Kontext von "Mint" ist AFAIK & AFAIR das Original Ubuntu. Das stammt
wiederum von Debian ab.

Post by Marc Haber

Post by Sieghard Schicktanz
Die "grub.cfg" _definiert_ das Verhalten des Systemlade-Systems namens
"grub" für die Funktion des Ladevorgangs des Zielsystems, _statisch_.
Für kurzzeitige Anpassungen gibt es Hilfsmechanismen wie z.B. die Datei
"grubenv".

Nicht notwendigerweise.

Sicher, man kann alles verdrehen.

Post by Marc Haber

Post by Sieghard Schicktanz

Post by Marc Haber
Die grub.cfg wird immer komplett neu geschrieben. Es wird nicht darin

Das ist eine eigenwillige Verfahrensweise eines spezifischn Systems und
so nicht in der Konstruktion von "grub" vorgesehen.

Aber natürlich ist es das.

Aha, deswegen gibt es wohl die Möglichkeit, die "grub.cfg" gleich in den
Lader mit einzubetten, da ist er ja am einfachsten zu ändern...
Nein, die "grub.cfg" ist _kein_ Verbrauchsmaterial. Nicht laut der
Dokumentation des grub.

...

Post by Marc Haber

Post by Sieghard Schicktanz
werden. Ich meine, wenn ein System sowas macht, dann lag hier jemand
reichlich schief.

Ich sehe das anders.

Wenn Du meinst.

[Ulli Horlacher]

Post by Marc Haber

Post by Ulli Horlacher

Post by Ulli Horlacher
(Erste Ungereimtheit: wo kommt der Zusatz "GNU/Linux" her?)

Ok, das hab ich gefunden in /etc/grub.d/10_linux
case ${GRUB_DISTRIBUTOR} in
Ubuntu|Kubuntu)
OS="${GRUB_DISTRIBUTOR}"
;;
*)
OS="${GRUB_DISTRIBUTOR} GNU/Linux"
;;
esac

Also ist der grub in Mint schlecht angepasst.

Nein, das "Mint" kommt von mir (via 99_mux.cfg):

***@juhu:/etc/default/grub.d# fpg GRUB_DISTRIBUTOR *

50_linuxmint.cfg:
GRUB_DISTRIBUTOR="Ubuntu"

99_mux.cfg:
GRUB_DISTRIBUTOR="`lsb_release -ds 2>/dev/null` /sw"


***@juhu:/etc/default/grub.d# lsb_release -ds
Linux Mint 21.3

[Marc Haber]

Post by Ulli Horlacher
GRUB_DISTRIBUTOR="Ubuntu"

Allein das ist doch völlig lieblos.

Grüße
Marc

[Ulli Horlacher]

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.
Wie/wo kann man am einfachsten ein Skript einhaengen das beim shutdown
ausgefuehrt wird analog zu /etc/rc.local beim booten?

[Marcel Mueller]

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.
Wie/wo kann man am einfachsten ein Skript einhaengen das beim shutdown
ausgefuehrt wird analog zu /etc/rc.local beim booten?

Sollte mit einer systemd Unit gehen.
Für Suspend habe ich das jedenfalls schon gemacht.


Marcel

[Ulli Horlacher]

Post by Marcel Mueller

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot /boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.
Wie/wo kann man am einfachsten ein Skript einhaengen das beim shutdown
ausgefuehrt wird analog zu /etc/rc.local beim booten?

Sollte mit einer systemd Unit gehen.
Für Suspend habe ich das jedenfalls schon gemacht.

<didi>
"Ich brauche mehr Details"
</didi>

Wie sieht das aus?

[Marcel Mueller]

Post by Ulli Horlacher

Post by Marcel Mueller

Post by Ulli Horlacher
Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.
Wie/wo kann man am einfachsten ein Skript einhaengen das beim shutdown
ausgefuehrt wird analog zu /etc/rc.local beim booten?

Sollte mit einer systemd Unit gehen.
Für Suspend habe ich das jedenfalls schon gemacht.

<didi>
"Ich brauche mehr Details"
</didi>
Wie sieht das aus?

Uff, ist schon Jahre her. War für ein Notebook, weil es beim Suspend
immer die Thresholds für Akku-schonen und irgendwelche
Energiespareinstellungen vergessen hat. Das läuft immer noch, aber ich
habe es jetzt nicht hier.

Man muss halt eine Unit anlegen (Textdatei in /etc/systemd/system) und
dann die passenden Abhängigkeiten eintragen. Z.B. After=systemd.suspend
Zu den Uint-Dateien gibt es eine ganz gute Anleitung im Netz:
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
Die hat mir immer geholfen.

Wahrscheinlich wäre es auch einfacher gegangen, weil man mit systemctl
edit auch bestehenden Units zusätzliche Befehle verpassen kann
(Exec...Pre/Post=...). Das wusste ich damals aber nicht.


Marcel

[Marco Moock]

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot
/boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.

Warum nimmst du nicht die /etc/default/grub?
update-grub wird dir sonst ständig in die grub.cfg reinfummeln - und
das bei jedem Kernelupdate.

Post by Ulli Horlacher
Wie/wo kann man am einfachsten ein Skript einhaengen das
beim shutdown ausgefuehrt wird analog zu /etc/rc.local beim booten?

Du willst SysVinit auf einem Systemd-System. Wäre es nicht an der Zeit,
auf ein OS ohne systemd umzustellen?

Sonst halt:
https://www.psdn.io/posts/systemd-shutdown-unit/

[Ulli Horlacher]

Post by Marco Moock

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot
/boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.

Warum nimmst du nicht die /etc/default/grub?

Hast du mein Original-Posting nicht gelesen?
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Post by Marco Moock
update-grub wird dir sonst ständig in die grub.cfg reinfummeln - und
das bei jedem Kernelupdate.

Nein. update-grub wertet /etc/default/grub korrekt aus. Das wird auch von
apt aufgerufen beim Kernelupdate. DAS funktioniert genau so wie es sein
soll.

Post by Marco Moock

Post by Ulli Horlacher
Wie/wo kann man am einfachsten ein Skript einhaengen das
beim shutdown ausgefuehrt wird analog zu /etc/rc.local beim booten?

https://www.psdn.io/posts/systemd-shutdown-unit/

Urks, wie ueblich horrend umstaendlich bei systemd.
Ok, ich muss das mal implementieren.

[Marco Moock]

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher

Post by Ulli Horlacher
Bei Mint 22 (basiert auf Ubuntu 24) schreibt reboot
/boot/grub/grub.cfg neu!

Workaround waere /boot/grub/grub.cfg vor dem reboot mit chattr zu schuetzen.

Warum nimmst du nicht die /etc/default/grub?

Hast du mein Original-Posting nicht gelesen?
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf. Das ist nun wirklich Murks,
der im OS und nicht per Workaround gelöst werden muss.

Post by Ulli Horlacher

Post by Marco Moock
update-grub wird dir sonst ständig in die grub.cfg reinfummeln - und
das bei jedem Kernelupdate.

Nein. update-grub wertet /etc/default/grub korrekt aus. Das wird auch
von apt aufgerufen beim Kernelupdate. DAS funktioniert genau so wie
es sein soll.

[Ulli Horlacher]

Post by Marco Moock

Post by Ulli Horlacher
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer deren
speziellen Programme.

[Marco Moock]

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer
deren speziellen Programme.

Ist das auch bei Ubuntu der Fall?

[Ulli Horlacher]

Post by Marco Moock

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer
deren speziellen Programme.

Ist das auch bei Ubuntu der Fall?

Nein.

[Tim Ritberg]

Post by Marco Moock

Post by Ulli Horlacher

Post by Marco Moock
Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer
deren speziellen Programme.

Ist das auch bei Ubuntu der Fall?

Nein.

https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/where.html

Tim

[Marc Haber]

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer deren
speziellen Programme.

Lieblos.

Grüße
Marc

[Tim Ritberg]

Post by Marc Haber

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher
reboot ignoriert dessen Inhalt und schreibt ein anderes grub.cfg

Dann mache bei Mint einen Bugreport auf.

Es gibt leider keine generischen Bugreport-Eingabe bei Mint, nur fuer deren
speziellen Programme.

Lieblos.
Wie ich weiter oben schrieb, ist Mint kaum mehr als ein "Mami guck mal

was ich kann"-Linux.

Tim

[Marco Moock]

Post by Ulli Horlacher
Also fuehrt reboot noch irgendwelche Skripte aus!
Ist das eine neue systemd Bosheit?

Greppe doch mal auf die Verzeichnisse von systemd nach grub. Vielleicht
findet sich da was.

[Ulli Horlacher]

Post by Marco Moock

Post by Ulli Horlacher
Also fuehrt reboot noch irgendwelche Skripte aus!
Ist das eine neue systemd Bosheit?

Greppe doch mal auf die Verzeichnisse von systemd nach grub. Vielleicht
findet sich da was.

Das hab ich vor meinem ersten Posting gemacht und nichts gefunden, was zu
shutdown/reboot passt.

[Marco Moock]

Post by Ulli Horlacher

Post by Marco Moock

Post by Ulli Horlacher
Also fuehrt reboot noch irgendwelche Skripte aus!
Ist das eine neue systemd Bosheit?

Greppe doch mal auf die Verzeichnisse von systemd nach grub.
Vielleicht findet sich da was.

Das hab ich vor meinem ersten Posting gemacht und nichts gefunden,
was zu shutdown/reboot passt.

Gab es denn was? Ggf. wird das über Umwege aufgerufen und funkt dir
hier trotzdem rein.