[geloest] Grub "erweiterte Einstellungen" abgewöhnen

[dirk11]

Da ich das ja schon auf vier Rechnern erfolgreich gemacht habe: ja, ich habe das in der /etc/default/grub gemacht und ja, ich habe zusätzlich auch die Zeile in dem anderen file eingekürzt. Nutzlos.
Der einzige Unterschied zu "meinen" Rechnern ist, dass auf dem betroffenen Rechner Multiarch installiert ist - das habe ich nicht, weil ich es nicht brauche. Sollte aber egal sein.

[rendegast]

EDIT,
folgender Beitrag kam wegen Nichtbeachtens von bei mir lokal gepatchten
10_linux
20_linux_xen
zustande.
Dadurch findet (bei mir) die in default/grub... gesetzte SUPPORTED_INITS Beachtung.
Das ist in der initialen Paket-Version so NICHT vorgesehen!
----------------------------------------------------------------------------------------------------------

ja, ich habe das in der /etc/default/grub gemacht

und ja, ich habe zusätzlich auch die Zeile in dem anderen file eingekürzt.

Nutzlos.

Ich sag mal, das paßt so nicht zusammen.


/usr/sbin/update-grub
/usr/sbin/update-grub2
...
/etc/grub.d/00_header
/etc/grub.d/05_debian_theme
/etc/grub.d/10_linux
/etc/grub.d/20_linux_xen
/etc/grub.d/30_os-prober
/etc/grub.d/30_uefi-firmware
/etc/grub.d/40_custom
/etc/grub.d/41_custom
...
/usr/lib/grub/grub-mkconfig_lib
...
/usr/sbin/grub-mkconfig

Hast Du an obigen Dateien andere Änderungen durchgeführt?

Hast Du nach den Vorgaben 'update-grub' gemacht?

In der default/grub resp. default/grub.d/*.cfg ein 'exit'/'break' vor den Optionen?

Arbeitest Du vielleicht bei den Änderungen in einem ssh-xterm auf einem anderen Rechner?
Oder beobachtest die grub.cfg einer anderen linux-Installation?


Ist die Installation fehlerhaft?

Code: Alles auswählen

dpkg -l | egrep -v "^ii"
dpkg -l | grep grub

Setzt vielleicht ein backup/recovery die grub.cfg zurück?
Liegt ein cow-Mount oder ähnliches (tmpfs) auf /boot/?

[dirk11]

Ich sag mal, das paßt so nicht zusammen.

Da bin ich ganz deiner Meinung, aber es ist so.

Hast Du an obigen Dateien andere Änderungen durchgeführt?

Nein. Seitdem es nicht mehr der grub 0.99 ist, ändere ich grundsätzlich nichts mehr an irgendwelchen Grub-Dateien außer der in default, weil die Änderungen bei jedem update überschrieben werden und das einfach unendlich nervt.

Hast Du nach den Vorgaben 'update-grub' gemacht?

Kommt drauf an, was sind denn "die Vorgaben"? Ich habe als root update-grub ausgeführt. Falls du darauf hinaus willst, dass man auch update-grub2 machen soll: das ist mWn nicht mehr nötig.

In der default/grub resp. default/grub.d/*.cfg ein 'exit'/'break' vor den Optionen?

Ich reinmachen oder Frage ob das drin ist? Fallst letzteres: nein, steht da nicht drin, es sei denn, das ist irgendwo als default drin. In /etc/default/grub hatte ich auf der Installation ursprünglich schon Änderungen vorgenommen (weiter vorne in der Datei, Auflösung und Timeout), die werden weiterhin übernommen.

Arbeitest Du vielleicht bei den Änderungen in einem ssh-xterm auf einem anderen Rechner?

Sowohl als auch. Ich habe auf meinen eigenen Rechner tatsächlich die kompletten updgrades auf Jessie im screen per ssh gemacht, funktionierte wunderbar. Meinen Server administriere ich ausschließlich so.

Oder beobachtest die grub.cfg einer anderen linux-Installation?

Nein, das kann ich ausschließen.

Ist die Installation fehlerhaft?

Das kann ich die Tage prüfen. Es gab beim upgrade auf Jessie die Merkwürdigkeit, dass "/" nach einem ersten reboot nur ro gemountet wurde. Hat ein wenig gedauert, bis ich das gefunden habe: 1. hat der Besitzer ein paarmal hart ausgeschaltet, das XFS hatte Fehler (aber sehr wenige) und 2. hat sich aus einem mir nicht nachvollziehbaren Grund die UUID der Partition "/" geändert, seit dem upgrade hängt noch ein kleines "c" hinten dran. Warum auch immer das passiert ist. Ist zwar von mir aufgesetzt, aber eben nicht mein Rechner und wird eigentlich auch nicht mehr von mir gewartet.

Setzt vielleicht ein backup/recovery die grub.cfg zurück?

Woher soll das kommen? So etwas ist nicht installiert.

Liegt ein cow-Mount oder ähnliches (tmpfs) auf /boot/?

Kühe? Was ist das?

[dirk11]

Moin!

Heute morgen habe ich mal einen Monitor an meinen Homeserver angeschlossen: auch der (Debian als einziges System) hat immer noch (oder wieder) den zweiten Boot-Eintrag "(sysvinit") in der obersten Menü-Ebene, direkt unter dem originalen (und einzigen) Eintrag zum Start von Debian. Ich habe keinen blassen Schimmer, was da vor sich geht. Trotz exakt identischer Vorgehensweise sieht es momentan so aus:

- mein Desktop: kein unerwünschter Menüeintrag
- mein Laptop1: kein unerwünschter Menüeintrag
- mein Laptop2: kein unerwünschter Menüeintrag
- mein Homeserver: unerwünschter Menüeintrag
- Fremd-Laptop: unerwünschter Menüeintrag

Wie gesagt, Vorgehensweise ist überall identisch, System ist auch auf allen Rechnern (vor allem meine drei User-Rechner) ziemlich gleich, da sind nur Sachen zusätzlich installiert, welche den Desktop betreffen - sowas wie vlc braucht man halt nicht auf nem Server...
Die Files /etc/default/grub und das Verzeichnis /etc/grub.d bzw. dessen Inhalt sind auf allen Rechnern identisch.

Bin da irgendwie ratlos momentan.

D.
P.S.: und nein, ich sehe nix, was über /boot gemountet ist, /boot ist "normal" sichtbar wie jede andere Partition auch, wenn ich sie mit "mount" aufliste.

[rendegast]

Aua, Aua,
ich arbeite hier mit gepatchten
10_linux
20_linux_xen
in denen nach dem Setzen des SUPPORTED_INITS am Skriptanfang
später nochmals die default/grub + default/grub.d/*.cfg geparst werden,
und dadurch kann ich sie auch in der default/-Konfig leer setzen.
Bitte um Verzeihung.

JTH lag vollkommen richtig.
Ein Fix wäre das Verschieben der Option aus den beiden Skripten in die Initialisierungs-Version der /etc/default/grub,
verbunden mit dem Hinzufügen zu den Exports der grub-mkconfig
(oder einer nochmaligen Parse-Anweisung der default/-Konfig in den Skripten).

Der walkaround ist das Auskommentieren oder Leer-Setzen von SUPPORTED_INITS in den beiden Skripten, ala JTH.
Hast Du das gemacht, so DÜRFEN die "init"-menuentry nicht mehr auftauchen.
-> die beiden 10_linux und 20_linux_xen mal nach nopaste hochladen.

[dirk11]

Hi!

Geht momentan nicht. Aber ich denke, ich werde nochmal das mit dem Eintrag in 10_linux editieren/beobachten. 20_linux_xen wird wohl nicht notwendigerweise bearbeitet werden müssen, so wie ich das verstehe, ist das für andere als den benutzten Kernel.

[KBDCALLS]

Oder gleich die Originalscripte nehmen. Außerdem mit update-grub -o Test.cfg in eine Datei schreiben und sich den Output ansehen.

[dirk11]

Oder gleich die Originalscripte nehmen.

Den Satz verstehe ich jetzt nicht. Die 10_ habe ich nur in bezug auf die eine betroffene Zeile angefasst, die 20_ gar nicht. Und die /etc/default/grub hat ihre Einstellungen funktionsfähig seit Anbeginn von Wheezy, einzig die zwei hier im thread genannten Zeilen sind hinzugekommen.

[KBDCALLS]

Der Grub von Debian ist doch ziemlich heftig gepacht. Unter anderem die beiden Scripte 10_linux und 20_linux_xen. Und ich meinte die Originalversionen aus den Grubsourcen verwenden, anstatt daran rumzueditieren.