staging.inyokaproject.org

Kann man den Grub Customizer mittlerweile eigentlich mit gutem Gewissen verlinken (und somit ein Stück weit empfehlen)?

Hallo und Danke. Klasse Artikel zur GRUB2-Konfiguration. Ich rege an, bereits in der Einleitung einen Hinweis auf das notwendige Update der Grub-Konfiguration einzubringen.

... "Manuelle Anpassungen werden an der Datei /etc/default/grub (grundlegende Einstellungen) und über die Skripte im Verzeichnis /etc/grub.d (individuelle Menüeinträge, optische Anpassungen etc.) vorgenommen."...

Ergänzungsvorschlag: Anschließend muss die Grubkonfiguration aktualisiert(interner Link zu Grub-Konfiguration updaten) werden.

Hintergrund: Ungeduldige (wie ich) lesen wo die Konfigurationsdatei und der entsprechende Parameter liegt, ändern es, booten neu und wundern sich.

Grüße AdamL

AdamL schrieb:

Hintergrund: Ungeduldige (wie ich) lesen wo die Konfigurationsdatei und der entsprechende Parameter liegt, ändern es, booten neu und wundern sich.

Das darfst Du Dir in diesem Wiki getrost abgewöhnen. Hier ist das Wissen meist derart kompakt formuliert, dass man die Seiten gründlich studieren sollte, um nichts zu übersehen.

Ich kann Deinen Wunsch nachvollziehen, weil ich auch zum schnell Überfliegen neige - und damit an anderer Stelle meist erfolgreich bin. Aber nachdem ich hier etliche Male regelmäßig wichtige Informationen überlesen (bzw. eben nicht gelesen) habe, bin ich auch dazu übergegangen, die Seiten immer gründlich zu studieren.

MannMitHut schrieb:

Kann man den Grub Customizer mittlerweile eigentlich mit gutem Gewissen verlinken (und somit ein Stück weit empfehlen)?

Mal abgesehen davon, dass der im Support immer wieder übel aufstößt:

https://bugs.launchpad.net/grub-customizer/+bugs?orderby=status&start=0

Der gehört imho aber auch nicht in einen Artikel der die Hintergründe erklärt.

tomtomtom schrieb:

Der (Grub Customizer) gehört imho aber auch nicht in einen Artikel der die Hintergründe erklärt.

So wie ich nie zur Nutzung des automatischen Installers raten würde, weil dann kein Einfluss auf die Partitionierung besteht, halte ich es auch für besser, statt des Einsatzes des Grub-Customizers eher die Steuerung über die Konfiguration zu empfehlen.

GRUB_DISABLE_SUBMENU=n

danach habe ich wochenlang gesucht. DANKE!!! http://askubuntu.com/a/439156/371780

ich habe viel gesucht nach list previous kernel versions in grub show them in separate list gerade auf linux mint stören die kernel-upgrades-einträge wenn man einen oder mehrere entry hat dann weiß man dass das nur ärger gibt mit grub_default 1,2,3,...

Unter Kernel Variablen taucht GRUB_CMDLINE_LINUX_EXTRA auf. Diese gibt es hier aber nicht: https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html#Simple-configuration

Die Behauptung, dass GRUB_SAVEDEFAULT= nur die Menüs berücksichtigt, die durch 10_linux erzeugt werden, halte ich für falsch. Bei mir z.B. funktioniert es auch mit dem "Windows"-Menüeintrag, der mit 30_os-prober erzeugt wird. Außerdem würde ich /etc/grub.d/10_linux schreiben, bevor der Unbedarfte ewig rätseln muss, was 10_linux bedeuten könnte,

Hallo,

im Abschnitt Die Datei /etc/default/grub sind zusätzlich zum verlinkten Artikel sudo-Artikel noch mehrere Beispiele für die Nutzung von gksudo und kdesudo und die Erklärung, dass diese ggfs. nachinstalliert werden müssen, aufgeführt.

Da dort weitergehende Erklärungen zu den unterschiedlichen Versionen wohl nicht zielführend sind, würde ich vorschlagen, den ganzen Absatz auf

"Diese Datei ist in einem Editor mit Rootrechten zu bearbeiten."

zu kürzen, wobei ich den Link auf sudo durch einen auf mit Root-Rechten arbeiten ändern würde.

Meinungen, Ideen, Vorschläge?

tomtomtom schrieb:

Meinungen, Ideen, Vorschläge?

eigentlich müsste man trennen - bis 16.04 und ab 18.04.

Oder aber, da die Lösung mittels nano auf allen Systemen von 14.04 bis 18.04 und allen Oberflächen gleich funktioniert, den gesamten Artikel entsprechend umschreiben und nur die Links anpassen.

Naja, wir haben einen Artikel zu Editoren, in dem erklärt ist, wie man sich dafür Rootrechte holt, und zur Arbeit mit Rootrechten.

Am besten wartbar wäre wohl einfach darauf zu verlinken, ansonsten muss das alles redundant gewartet werden.

tomtomtom schrieb:

"Diese Datei ist in einem Editor mit Rootrechten zu bearbeiten."

zu kürzen, wobei ich den Link auf sudo durch einen auf mit Root-Rechten arbeiten ändern würde.

Mir gefällt Dein Vorschlag sehr gut. Die verschiedenen Varianten ufern sonst aus. Im obigen Artikel sind schon 5 Methoden erwähnt, und es fehlt sogar eine, die ich am meisten mag: Mittels Nemo den gewünschen Ordner "Als Systemverwalter öffnen" und dann kann man beliebige Dateien durch Doppelklick bearbeiten. Zur Vorsicht zeigt sich Nemo dann mit rotem Warnbalken, besser geht't nicht.

Evtl. noch mit Root-Rechten arbeiten im Wissensblock ergänzen.

Hallo,

Meinungen, Ideen, Vorschläge?

Bitte so wie vorgeschlagen umsetzen.

Gruß, noisefloor

noisefloor schrieb:

Bitte so wie vorgeschlagen umsetzen.

Erledigt.

Wenn Grub durch ein Passwort geschützt ist, müssten dann nicht alle Dateien, die den Schlüssel enthalten, ausschließlich für Root lesbar sein? Und zwar auch dann, wenn der Schlüssel nicht im Klartext vorliegt?

Denn manche Nutzer werden ihr Root-/Sudo-Passwort an dieser Stelle recyclen, und dann bekommen alle Dateien mit dem Schlüssel, also in der Regel /etc/grub.d/40_custom und /boot/grub/grub.cfg, den gleichen Stellenwert wie /etc/shadow. Falsche Nutzerrechte auf /etc/shadow aber gelten gemeinhin als eklatanter sicherheitsrelevanter Konfigurationsfehler.

Nur nebenbei bemerkt habe ich kein einziges Linux-Wiki gefunden, das auf dieses Problem hinweist. Aber irgendwo müssen wir ja anfangen 😉