staging.inyokaproject.org

kB schrieb:

Ich schlage daher vor, nach Bearbeitung meines letzten Punktes den Aufbau und die Struktur des Artikels als abgeschlossen zu erklären, damit wir uns dann hier in der Diskussion nur noch um einzelne Inhalte kümmern müssen.

👍 1+

kB schrieb:

• Lediglich die Ausführungen zu UEFI und "Secure Boot" unter GRUB_DISTRIBUTOR erscheinen mir deplatziert. Ich vermute, diese sollen an eine andere Stelle im Artikel.

Nein, die sind im Moment da schon richtig platziert. Es könnte eventuell an dieser Stelle kürzer dargestellt werden, wenn wir Artikel zu Secure Boot hätten. Die habe wir aber (noch) nicht. Solange das so ist, wüsste ich keine geeignetere Stelle.

Nicht an dieser Stelle müsste stehen, eigentlich auch nicht kurz, konzeptionell, wie man ein Secure Boot System mit eigenen Keys einrichtet. Aber wie gesagt, zu Secure Boot haben wir nichts und einen sachlich guten Artikel dazu schreibt man auch nicht eben mal so.

Aber dass GRUB_DISTRIBUTOR zu unterschiedlichen Ergebnissen führt, je nachdem, welche Boot-Methode man nutzt, das steht an dieser Stelle schon richtig. Und die Unterscheidung ob UEFI mit oder UEFI ohne Secure Boot spielt dabei auch eine wichtige Rolle.

LG, Newubunti

Newubunti schrieb:

Aber dass GRUB_DISTRIBUTOR zu unterschiedlichen Ergebnissen führt, je nachdem, welche Boot-Methode man nutzt, das steht an dieser Stelle schon richtig. Und die Unterscheidung ob UEFI mit oder UEFI ohne Secure Boot spielt dabei auch eine wichtige Rolle.

In dem Zusammenhang fällt mit folgende Bemerkung noch ins Auge:

(dieser Befehl führt standardmäßig bei allen Ubuntu-Derivaten zu dem Wert Ubuntu)

Ich glaube mich ziemlich sicher daran erinnern zu können, dass zumindest unter Kubuntu dann da der Wert auch "Kubuntu" ist, und evtl. unter UEFI der NVRAM-Eintrag und / oder der Ordner in der EFI-Partition dann "Kubuntu" lautet. (Bitte nicht schlagen, wenn ich mich irre. 😉 )

Newubunti schrieb:

[…] dass GRUB_DISTRIBUTOR zu unterschiedlichen Ergebnissen führt, je nachdem, welche Boot-Methode man nutzt

Der Standardwert für GRUB_DISTRIBUTOR ist einfach der Wert von DISTRIB_ID aus der Datei /etc/lsb-release. Und das soll von der Boot-Methode abhängen? Das glaube ich nicht.

kB schrieb:

Newubunti schrieb:

[…] dass GRUB_DISTRIBUTOR zu unterschiedlichen Ergebnissen führt, je nachdem, welche Boot-Methode man nutzt

Der Standardwert für GRUB_DISTRIBUTOR ist einfach der Wert von DISTRIB_ID aus der Datei /etc/lsb-release. Und das soll von der Boot-Methode abhängen? Das glaube ich nicht.

Ob so rum weiß ich nicht, aber wenn da z.B. "Mein_Supersystem" eingetragen wird, führt das unter UEFI dazu, dass nach grub-install in der EFI-Partition der Ordner "Mein_Supersystem" auftaucht genauso wie im UEFI-Boot-Menü selbig bezeichneter Menü-Eintrag, jeweils zusätzlich zum vorhandenen "Ubuntu"-Ordner / -Eintrag. Dass der dann aber nur ohne Secure-Boot tatsächlich funktioniert, steht auf einem anderen Blatt.

kB schrieb:

Newubunti schrieb:

[…] dass GRUB_DISTRIBUTOR zu unterschiedlichen Ergebnissen führt, je nachdem, welche Boot-Methode man nutzt

Der Standardwert für GRUB_DISTRIBUTOR ist einfach der Wert von DISTRIB_ID aus der Datei /etc/lsb-release. Und das soll von der Boot-Methode abhängen? Das glaube ich nicht.

Nein, da hast Du Recht! Bei Verwendung des Standardwertes gibt es keine Probleme, aber in dem Moment, wo ich den anpassen möchte schon. Ah, ok das geht aus dem Text nicht eindeutig hervor. Das ist wieder so ein Ding, dass für mich selbst klar wie Kloßbrühe ist - tatsächlich aber nicht eindeutig im Text steht, zumindest nicht im Abschnitt "UEFI ohne Secure Boot".

LG, Newubunti

UlfZibis schrieb:

Ob so rum weiß ich nicht, aber wenn da z.B. "Mein_Supersystem" eingetragen wird, führt das unter UEFI dazu, dass nach grub-install in der EFI-Partition der Ordner "Mein_Supersystem" auftaucht genauso wie im UEFI-Boot-Menü selbig bezeichneter Menü-Eintrag, jeweils zusätzlich zum vorhandenen "Ubuntu"-Ordner / -Eintrag. Dass der dann aber nur ohne Secure-Boot tatsächlich funktioniert, steht auf einem anderen Blatt.

Das richtige Testprotokoll zum Überprüfen der Variablen ist wie folgt (Bitte nur nachmachen, wenn in einer Test-VM oder wenn in der Lage ein nicht startendes System zu reparieren bzw. über die GRUB-Shell zum Start zu bringen!):

• Auf einem Ubuntu-Standard-System, das im UEFI-Modus läuft - ob mit oder ohne Secure Boot ist egal - die Variable GRUB_DISTRIBUTOR individuell anpassen - z.B. GRUB_DISTRIBUTOR=Jammy

• sudo grub-install 

• Mit efibootmgr -v prüfen, dass der Jammy-Eintrag im NVRAM ist und auch als Standard-Starteintrag Festgelegt wurde

• sudo mv /boot/efi/EFI/ubuntu{,.bu} 

• System neustarten

LG, Newubunti

Ich habe unter GRUB_DISTRIBUTOR nun noch eine Erklärung vor den Abschnitten zu UEFI-(Secure-Boot) hinzugefügt, die eindeutig erklärt, dass die folgenden Anpassungen nur im Fall einer individuellen Einstellung zu treffen sind.

LG, Newubunti

Newubunti schrieb:

• sudo mv /boot/efi/EFI/ubuntu{,.bu} 

Was soll denn dieser Befehl – ohne Zielpfad – bewirken?

Die hier verwendete apt-Option --allow-remove-essential schützt für das System als essentiell wichtig gekennzeichnete Pakete und sollte daher nur mit Beacht verwendet werden!

Müsste es da nicht heißen:

Die hier verwendete apz-Option --allow-remove-essential erlaubt für das System als essentiell wichtig gekennzeichnete Pakete zu entfernen und sollte daher nur mit Bedacht verwendet werden!

black_tencate schrieb:

Zur Syntax Deiner Tabelle:
Statt:

<|3>[:baustelle/grub_2/konfiguration/#GRUB-DEFAULT:`GRUB_DEFAULT=`]

geht auch:

<|3>[#GRUB-DEFAULT `GRUB_DEFAULT=`]

Und das ist dann auch allgemeingültig für Baustelle, Vorschau und endgültigen Artikel.

UlfZibis schrieb:

Müsste es da nicht heißen:

Die hier verwendete apz-Option --allow-remove-essential erlaubt für das System als essentiell wichtig gekennzeichnete Pakete zu entfernen und sollte daher nur mit Bedacht verwendet werden!

Ja, stimmt. Habe es korrigiert. Danke!

Was soll denn dieser Befehl – ohne Zielpfad – bewirken?

Kurzform von

sudo mv /boot/efi/EFI/ubuntu /boot/efi/EFI/ubuntu.bu 

So etwas darf man aber auch gerne mal mit einer Testdatei selber ausprobieren, wenn man misstrauisch ist.

Ergebnis der Durchführung des gesamten Protokolls sollte sein, dass Du beim Neustart in der GRUB-Shell ohne GRUB-Menü landest. Den Grund dafür findest Du in der Erklärung im Abschnitt GRUB 2/Konfiguration (Abschnitt „Einschraenkungen-bei-Verwendung-von-Secure-Boot“). Der GRUB-Ablauf ist unter Ubuntu standardmäßig im UEFI-Modus so - und zwar egal ob Secure Boot aktiv ist oder nicht:

• NVRAM-Eintrag zeigt in unserem Beispiel GRUB_DSITRIBUTOR=Jammy auf \EFI\jammy\shimx64.efi und lädt die angegebene EFI-App (shimx64.efi) beim Systemstart entsprechend

• shimx64.efi lädt grubx64.efi aus dem gleichen Verzeichnis - also \EFI\jammy\grubx64.efi

• grubx64.efi ist dabei standardmäßig die von Canonical signierte Variante, bereitgestellt über das Paket grub-efi-amd64-signed und zeigt für weitere nachzuladende Dateien stets auf den Pfad \EFI\ubuntu

• Da wir bei meinem Testprotokoll das Verzeichnis umbenennen, um zu überprüfen, ob GRUB_DISTRIBUTOR=Jammy vollständig umgesetzt ist, scheitert der Neustart des Systems an dieser Stelle.

Gehe dann im Vergleich nach Baustelle/GRUB 2/Konfiguration (Abschnitt „Besonderheiten-bei-UEFI-Boot-Modus“) vor und wiederhole den Test. Ergebnis wird sein, dass der Neustart trotz Umbenennung des Verzeichnisses \EFI\ubuntu gelingen wird.

Den Grund findest Du in beiden Fällen, wenn Du sudo grub-install -v ausführst, was zu einer sehr langen Ausgabe führt. Irgendwo in der Mitte dieser Ausgabe wirst Du einen Eintrag finden, in dem die /boot/grub/x86_64-efi/grub.efi nach den Vorgaben Deiner Konfiguration gebaut wird. Dieses /boot/grub/x86_64-efi/grub.efi enthält in unserem Beispiel den Pfad auf \EFI\jammy bzw. technisch ganz korrekt enthält sie glaube ich gar keinen Pfad, sondern verwendet den, in dem sich auch die gerade ausgeführte grubx64.efi befindet.

Am Ende der grub-install -v-Ausgabe siehst Du dann je nachdem, ob die Pakete grub-efi-amd64-signed und shim-signed installiert sind, unterschiedliches Verhalten:

• grub-efi-amd64-signed ist installiert (standard): Die eigentlich in der Mitte des Prozesses mit den richtigen Vorgaben (Pfad: \EFI\jammy) gebaute /boot/grub/x86_64-efi/grub.efi bleibt unbenutzt und es werden insbesondere /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed (wir erinnern uns, die zeigt auf \EFI\ubuntu) und /usr/lib/shim/shimx64.efi.signed nach \EFI\jammy kopiert.

• grub-efi-amd64-signed ist NICHT installiert (muss man immer erst herbeiführen): Es wird die in der Mitte des Prozesses gebaute /boot/grub/x86_64-efi/grub.efi nach \EFI\jammy kopiert und man erhält damit eine vollständige Umsetzung der mittels der Variabelen GRUB_DISTRIBUTOR bereitgestellten Funktionalität. D.h. das System startet auch ohne das Vorhandensein der Verzeichnisses \EFI\ubuntu und wir haben damit ein wirklich autarkes individuelles Verzeichnis \EFI\jammy.

Das Entfernen von grub-efi-amd64-signed und shim-signed funktioniert natürlich nur bei UEFI-Modus ohne Secure Boot - es sei denn man etabliert eine eigene Secure-Boot-Inrastruktur. Aber das steht auch im Artikel.

LG, Newubunti

Newubunti schrieb:

Was soll denn dieser Befehl – ohne Zielpfad – bewirken?

Kurzform von

sudo mv /boot/efi/EFI/ubuntu /boot/efi/EFI/ubuntu.bu 

Hat nicht erst gestern jemand geschrieben, das dieser Artikel für Einsteiger gedacht ist? Ich finde da solche Tricks unangebracht.

So etwas darf man aber auch gerne mal mit einer Testdatei selber ausprobieren, wenn man misstrauisch ist.

1. Wenn ich dem ersten Anschein nach denke, das der Befehl NIX macht, wie sollte ich dann auf die Idee kommen, ihn auszuprobieren.

2. Wenn ich nicht weiß, was der Befehl machen soll, weiß ich auch nicht, wo ich das Resultat suchen soll.

3. Völlig irritiert war ich von der bisher mir unbekannten Endung ".bu", sodass ich echt dachte, das hat der so nicht gemeint, da muss mindestens ein Typo drin sein.

Genau da zeigt sich die Problematik, wenn man sowas im Terminal probiert. Man weiß gar nicht, wo man das Ergebnis des "Probierens" suchen soll, übersieht es vielleicht und kommt zu dem Schluss, das der ausgeführte Befehl vielleicht auch nichts gemacht hat, oder man findet eine Änderung, und übersieht weitere an anderer Stelle. Im grafischen Dateimanager hingegen sehe ich das Resultat meiner Handlungen sofort, und deshalb ist das für mich "sicheres Arbeiten", auch wenn ich dafür den DM unter Root-Rechten brauche.

Ergebnis der Durchführung des gesamten Protokolls sollte sein, dass Du beim Neustart in der GRUB-Shell ohne GRUB-Menü landest. Den Grund dafür findest Du in der Erklärung im Abschnitt GRUB 2/Konfiguration (Abschnitt „Einschraenkungen-bei-Verwendung-von-Secure-Boot“). Der GRUB-Ablauf ist unter Ubuntu standardmäßig im UEFI-Modus so - und zwar egal ob Secure Boot aktiv ist oder nicht: [.....]

Ja danke für die Fleißarbeit. bestätigt genau das, was ich schrieb.
Allerdings wurde das (in leicht abgewandelter Form) hier schon im Wiki verewigt: EFI Nachbearbeitung (Abschnitt „Systeme-mit-secure-boot“) (ja das musste ich ein bisschen suchen, da es in den allgemeinen Artikeln bzgl. Dual-/Multi-Boot nicht verlinkt ist. Scheinbar gar nicht verlinkt ist der Artikel Mehrbootsystem mit 2x Ubuntu, wo zu dem Thema auch noch viel (und mit Bildern) drin steht, also ziemlich verstreut diese Thematik.)

UlfZibis schrieb:

Hat nicht erst gestern jemand geschrieben, das dieser Artikel für Einsteiger gedacht ist? Ich finde da solche Tricks unangebracht.

Ja, habe ich! Aber dieser Anspruch ist auf den Artikel beschränkt. Oder wo habe ich behauptet, dass die Diskussion um diesen Artikel diesem Anspruch auch gerecht werden muss?

Ja danke für die Fleißarbeit. bestätigt genau das, was ich schrieb.

Eben nicht genau, weil - egal ob Secure Boot aktiv oder nicht - im UEFI-Modus bei einem Standard-Ubuntu stets die signierte grubx64.efi verwendet wird. Diese Problematik war glaube ich zu 16.04-Zeiten, eventuell auch noch zu 18.04-Zeiten auf Systeme mit aktiviertem Secure Boot beschränkt. Mittlerweile installiert Ubuntu aber einfach die Secure-Boot-Variante auf einem UEFI-System, was auch kein Problem ist, solange man an GRUB_DISTRIBUTOR nichts ändert.

Allerdings wurde das (in leicht abgewandelter Form) hier schon im Wiki verewigt: EFI Nachbearbeitung (Abschnitt „Systeme-mit-secure-boot“)

Ich habe nicht behauptet, dass jedwede Erklärung der Überarbeitung Neuigkeiten enthält, allerdings ist der Teil mit der Deinstallation der Pakete grub-efi-amd64-signed und shim-signed "neu".

Im übrigen ist auch noch mal die Frage - und bei einem Wiki immer diskussionswürdig -und trächtig - in wie weit ich etwas an Ort und Stelle erkläre oder in wie weit ich den Leser von Link zu Link jage.

LG, Newubunti

Newubunti schrieb:

Ja, habe ich! Aber dieser Anspruch ist auf den Artikel beschränkt. Oder wo habe ich behauptet, dass die Diskussion um diesen Artikel diesem Anspruch auch gerecht werden muss?

Hoppla, ja da war ich auf dem falschen Dampfer. Nehme den Rüffel gerne entgegen.

Im übrigen ist auch noch mal die Frage - und bei einem Wiki immer diskussionswürdig -und trächtig - in wie weit ich etwas an Ort und Stelle erkläre oder in wie weit ich den Leser von Link zu Link jage.

Da dieser Artikel aber nun schon sehr lang ist, wäre ich dann hier doch eher dafür, auf den schon vorhandenen Artikel zu verweisen, und da den Aspekt mit der De-Installation der signierten Pakete nachbessern. Da ist man dann auch schon gleich an der richtigen Stelle, wenn es um weitere Frage rund um UEFI geht.
Hier würde also bei GRUB_DISTRIBUTOR der Hinweis reichen, dass dessen Veränderung Auswirkungen auf die UEFI-Funktionalität hat.
Bzw. hier hin: Mehrbootsystem mit 2x Ubuntu (Abschnitt „Zweites-Ubuntu-im-System“)

kB schrieb:

Probiere es aus, bereits bei Kommandozeilenprogrammen erzeugt sudo -H Probleme. Bei GUI-Programmen steigert sich das, weil nicht nur harmlose Testdateien, sondern auch für den Desktop essentielle Dateien verhunzt werden können:

cd ; rm TESTDATEI ; sudo -H touch $_ ; pwd ; ls -al TESTDATEI 

sudo -H ist böse, dagegen:

cd ; rm TESTDATEI ; sudo -i touch $_ ; pwd ; ls -al TESTDATEI 

Aber auch sudo -i löst nicht alle anderen denkbaren schädlichen Effekte auf anderen Ebenen.

Hab's ausprobiert und verstehe nicht, was Du mir damit demonstrieren willst. touch hat doch gar keinen Bezug auf $HOME und damit ist sudo -H touch dasselbe wie sudo touch. sudo an sich ist doch dann die Ursache, warum die TESTDATEI mit Besitzer root angelegt wird.

Es gibt allerdings Fälle, wo Kommandozeilen-Programme Bezug auf $HOME nehmen, und genau dann muss ein solches auch unter sudo -H benutzt werden.

Interessant ist aber, dass das Kommando echo sich weder von -H noch von -i beeindrucken lässt. Probier mal:

sudo echo $HOME
sudo -H echo $HOME
sudo -i echo $HOME
sudo -i
echo $HOME
exit