staging.inyokaproject.org

UlfZibis schrieb:

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.

Die Begründung mit dem "zu lang" teile ich nicht, ansonsten hast Du nicht Unrecht, was die Ausführlichkeit der Darstellung hier im Vergleich zu den Möglichkeiten im Artikel EFI Nachbearbeitung anbelangt.

Ich würde aber gerne solche Platzierungs-technischen Fragen erst mal noch zurückstellen und mich erst mal noch auf die Beseitigung inhaltlicher Mängel konzentrieren, sofern noch welche ausgemacht werden sollten.

LG, Newubunti

UlfZibis schrieb:

Hab's ausprobiert und verstehe nicht, was Du mir damit demonstrieren willst.

Ich bin ja nicht kB, aber ich schreibe mal, was ich aus dem Ganzen entnehme:
der 1. Befehl:

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

legt die Datei TESTDATEI mit Eigentümer root und Gruppe root im Home von ubuntu-22-04 an .

ubuntu-22-04@ubuntu2204-VirtualBox:~$ ls -la| grep TEST
-rw-r--r--  1 root         root       0 Apr  8 10:38 TESTDATEI
ubuntu-22-04@ubuntu2204-VirtualBox:~$ 

Ein Befehl, wie der folgende:

ubuntu-22-04@ubuntu2204-VirtualBox:~$ cd ; rm TESTDATEI21;  touch $_ ;  pwd ; ls -al TESTDA*
rm: das Entfernen von 'TESTDATEI21' ist nicht möglich: Datei oder Verzeichnis nicht gefunden # kann ja nicht gelöscht werden, wird ja erst noch angelegt. Aber der Name wird in $_ übernommen
/home/ubuntu-22-04
-rw-r--r-- 1 root         root   0 Apr  8 10:38 TESTDATEI
-rw-r--r-- 1 ubuntu-22-04 vboxsf 0 Apr  8 11:41 TESTDATEI21
ubuntu-22-04@ubuntu2204-VirtualBox:~$ sudo rm TESTDATEI21

legt die Datei TESTDATEI21 mit Eigentümer ubuntu-22-04 und Gruppe vboxsf im Home von ubuntu-22-04 an.
ls -al TESTDA* zeigt genau das nochmal genau an.

Das sagt mir:
sudo -H behandelt bzw benutzt die Rechte als root und eine solche Datei ist im Home so etwas wie ein Fremdkörper und kann auch mit mit sudo rm TESTDATEI gelöscht werden.

Das mit diesen rechten muss an halt beachten bzw wissen.

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

legt die Datei im Home vom root an.

root@ubuntu2204-VirtualBox:~# ls -la| grep TEST
-rw-r--r--  1 root root    0 Apr  8 10:39 TESTDATEI
root@ubuntu2204-VirtualBox:~#

Kontrolle:

root@ubuntu2204-VirtualBox:~# pwd
/root
root@ubuntu2204-VirtualBox:~# 

Bei sudo -i ist man in einem andren Verzeichnis, aber hier werden die Rechte beibehalten. Oder im Home von root ist der Eigentümer root und die Gruppe root.

Hier wird nichts ver... .

Berlin_1946 schrieb:

Ich bin ja nicht kB, aber ich schreibe mal, was ich aus dem Ganzen entnehme:

Vielen lieben Dank für die Fleißarbeit. Wäre aber nicht nötig gewesen, denn das hatte ich schon so verstanden. Es hat meine Hirnwindungen aber angeregt, noch mal eine extra Runde zu drehen. Ergebnis:

kB wollte demonstrieren, dass die Option -H bei Kommandozeilen-Programmen nicht zwingend das tut, was man erwartet.
Dabei ging es nicht darum, dass mit sudo -H touch dann eine Datei mit root-Besitz angelegt wird, sondern darum, dass diese nicht im root-HOME, also /root abgelegt wird, weil Kommandozeilen-Programme sich im allgemeinen nicht um $HOME scheren. Zusätzlich (ich verstand erst nicht, dass das hier wohl zusätzlich zur im Raum stehenden Frage gemeint war) demonstrierte er noch, dass noch nicht mal sudo -i touch das tut, was mich tatsächlich wundert (und jetzt frage ich mich deshalb, was denn der Unterschied zw. -H und -i ist, außer dass man mit letzterem eine root-Shell öffnen kann, wenn kein weiterer Befehl folgt).

Fazit:

1. Kommandozeilen-Programme ignorieren -H in der Regel (weil sie sich nicht an $HOME orientieren) – Ausnahme z.B. gpg. Sie machen mit -H aber nichts kaputt – siehe hier – wie ich kB erst verstanden hatte.

2. Bei GUI-Programmen bewirkt sudo -H meistens das, was man erwartet, nämlich dass sie keine Dateien mit Root-Rechten im Home-Verzeichnis des Benutzers überschreiben oder erstellen. Kollisionen mit dem Speichermanagment der GUI sind damit aber leider nicht sicher ausgeschlossen.

Was haltet Ihr denn von folgendem Alternativvorschlag (lässt sich sicher noch mit Farben, Zeichengrößen, prozentualen Spaltenbreiten etc. verschönern)? Beim Durchscrollen findet man die einzelnen Variablen einigermaßen schnell und übersichtlich, anders als bei den jetzigen 26 Einzelabschnitten, und die Detailbereiche kann man schön strukturieren. Ich würde aber vorschlagen, die Detailbereiche noch irgendwie knapper zu fassen.

Es entstehen so sogar Anker und Einträge im Inhaltsverzeichnis, auf die man dann ggf. in Forumsbeiträgen auch drauf verlinken kann.
.

UlfZibis schrieb:

Was haltet Ihr denn von folgendem Alternativvorschlag...

Setze das bitte mal mit allen 26 Variablen um, denn anhand so eines kurzen Mockups ist das nicht wirklich vergleichbar!

Was ich aber schon jetzt bei einer langen einzelnen Tabelle ungünstig finde ist - das betrifft nicht nur Dein Mockup-, dass Du nach bereits wenigen Variablen die Spaltenüberschriften nicht mehr im Blick hast. Bist Du bei Variabel Nr. 20, dann darfst Du erst mal ewig zurück scrollen, um nachzuschauen, wie noch mal Spalte XY überschrieben war.

Bei anderen Artikeln im Wiki, die solche Befehlsoptionen erklären, werden dann teilweise Einzeltabellen verwendet, also auf den Artikel hier übertragen würde das bedeuten, dass jede Variable Ihre eigene Tabelle bekommt.

IMO zeigt sich an Deinem Mockup aber, dass das Problem hier im Wiki-Design nicht an der Frage Tabelle oder nicht liegt, sondern dass alles ziemlich dicht aneinander geklatscht ist.

Der Abstand vor Überschriften ist IMO zu gering. Und die ganzen Boxen nehmen zu viel Raum ein bzw. sind zu dominant. IMO stimmt da auch das Schriftgrößenverhältnis nicht. Wenn eine Box schon durch Farbe und Rahmen hervorgehoben ist, dann muss z.B. "Hinweis", "Achtung" usw. nicht diese große nutzlos Raum einnehmende Schriftgröße haben.

Die vierte Überschriftebene ist standardmäßig praktisch eigentlich nicht benutzbar.

Letztlich ist das hier aber alles OT und müsste zu Inyoka diskutiert werden.

Und erfahrungsgemäß haben zu der Frage Design 10 Leute mindestens 11 Meinungen.

LG, Newubunti

UlfZibis schrieb:

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.

Das klingt für mich so wie nach einem unerwünschten und überraschenden Nebeneffekt in einer Komponente von GRUB als Folge unsauberen Designs. Da wir damit aber leben müssen, wäre in solchen Fällen im Wiki ein formatierter Warnhinweis angemessen.

UlfZibis schrieb:

Was haltet Ihr denn von folgendem Alternativvorschlag […]

Als Wiki-Betreuer halte ich davon gar nichts, weil solche Strukturen zumal bei einem langen Artikel die Pflege des Artikels verunöglichen.

Es gibt im Wiki Abschnitte mit Überschriften, diese bilden eine Gliederung und es gibt Tabellen und Bilder (hier weniger wichtig). Bitte das nicht mischen, obwohl es technisch möglich wäre.

Übrigens wird ein nicht zu pflegender Artikel auch nicht aus der Baustelle entlassen.

Und dieser Thread dient übrigens zur inhaltlichen Diskussion eines Artikels und nicht dem Meinungsaustausch zur möglichen, unmöglichen oder unerträglich empfundenen Gestaltung. In der Regel sollte der Artikelautor die Hoheit über die Art der Gestaltung haben, und eine lange Liste von einzelnen Abschnitten ist im Wiki genauso zulässig wie eine Tabelle. Sachlicher Inhalt vor Optik.

Newubunti schrieb:

Was ich aber schon jetzt bei einer langen einzelnen Tabelle ungünstig finde ist - das betrifft nicht nur Dein Mockup-, dass Du nach bereits wenigen Variablen die Spaltenüberschriften nicht mehr im Blick hast. Bist Du bei Variabel Nr. 20, dann darfst Du erst mal ewig zurück scrollen, um nachzuschauen, wie noch mal Spalte XY überschrieben war.

Das ist tatsächlich ein Nachteil. Ich denke allerdings, wenn man sich intensiver mit den GRUB-Variablen und damit auch mit der Tabelle beschäftigt, hat man das auch schnell im Kopf, was welche Spalte bedeutet. Der Einsteiger wird sich ja eher mehr mit den oberen Variablen beschäftigen, und da ist man ja noch nicht weit weg von der Kopfzeile. Jedenfalls finde ich, dass die eingekasteten und groß hervorgehobenen Variablen eine übersichtlichere Orientierung ermöglichen, als 26 gleichförmige Überschriften untereinander, die im Gesamtbild ziemlich untergehen.

Genauso finde ich aber auch den Vorschlag von black_tencate gut.

Newubunti schrieb:

[…] Die vierte Überschriftebene ist standardmäßig praktisch eigentlich nicht benutzbar.

Ja, das ist ein bekannter Fehler. Uns fehlen aber zur zeit die Möglichkeiten, das durch tiefen Eingriff in die Basissoftware zu beseitigen.

Deshalb nach Möglichkeit sich bitte einfach auf drei Gliederungsstufen beschränken.

kB schrieb:

Das klingt für mich so wie nach einem unerwünschten und überraschenden Nebeneffekt in einer Komponente von GRUB als Folge unsauberen Designs. Da wir damit aber leben müssen, wäre in solchen Fällen im Wiki ein formatierter Warnhinweis angemessen.

Ja so sehe ich das auch. Die Ausnutzung dieses "Nebeneffekts" wird aber hier dringlich empfohlen, weil es offensichtlich kaum andere Lösungen für das Problem gibt. Ungünstigerweise wird erst an anderer Stelle auf die damit verbundenen Gefahren hingewiesen, und es wird auch nicht dorthin verlinkt, nur zurück..

Newubunti schrieb:

Die vierte Überschriftebene ist standardmäßig praktisch eigentlich nicht benutzbar.

Ich habe in dem Beispiel nur Ebene 1 und 2 benutzt, die 3. ist also noch frei nutzbar.

UlfZibis schrieb:

kB schrieb:

Das klingt für mich so wie nach einem unerwünschten und überraschenden Nebeneffekt in einer Komponente von GRUB als Folge unsauberen Designs. Da wir damit aber leben müssen, wäre in solchen Fällen im Wiki ein formatierter Warnhinweis angemessen.

Ja so sehe ich das auch.

Wo liegt denn hier Eurer Meinung nach der Fehler von "Grub"? Und sind hier die Ubuntu-Maintainer, Debian-Maintainer oder Upstream-Grub gemeint?

Ich habe doch beschrieben, wie es richtig geht:

• Secure Boot deaktiviert: Man deinstalliert die beiden Pakete shim-signed und grub-efi-amd64.signed. Wo soll da das überraschende Problem liegen?

• Secure Boot aktiviert: Bei individuellen Anpassungen an EFI-Apps sind diese eben selbst zu signieren. Was ist daran überraschend?

Wenn man beschreibt, wie es richtig funktioniert, dann soll man vor anderem Vorgehen noch warnen? Vor was soll ich denn genau warnen?

Hier im Artikel geht es um die Erklärung der Variablen GRUB_DISTRIBUTOR. Ich habe doch ausführlich beschrieben, wie die sich oder besser die darauf aufbauende Funktionalität je nach Szenario verhält.

Wie man ein Multibootsystem richtig installiert, ist dann noch mal eine andere Frage - die aber IMO weniger hier zu platzieren ist, sondern in Artikeln, die das Thema Multiboot behandeln.

Wer sucht denn bevor er ein Multibootsystem einrichten will, ausgerechnet bei der Erklärung zur Variablen GRUB_DISTRIBUTOR nach der richtigen Vorgehensweise oder Warnungen diesbezüglich?

LG, Newubunti

Newubunti schrieb:

UlfZibis schrieb:

kB schrieb:

Das klingt für mich so wie nach einem unerwünschten und überraschenden Nebeneffekt in einer Komponente von GRUB als Folge unsauberen Designs. Da wir damit aber leben müssen, wäre in solchen Fällen im Wiki ein formatierter Warnhinweis angemessen.

Ja so sehe ich das auch.

Wo liegt denn hier Eurer Meinung nach der Fehler von "Grub"?

Ich wittere hier einen Design-Fehler, weil die eine Konfigurationsvariable GRUB_DISTRIBUTOR für mindestens zwei Zwecke verwendet wird, die nichts miteinander zu tun haben:

1. Formulierung der Menüpunkte

2. Benennung des Ablageortes für das Programm GRUB auf der EFI

Der erste Zweck wird erwartet, der zweite kommt für den naiven Leser überraschend, muss aber bei der Wahl des Wertes für den ersten, eigentlichen Zweck berücksichtigt werden.

Und sind hier die Ubuntu-Maintainer, Debian-Maintainer oder Upstream-Grub gemeint?

Im Rahmen dieses Artikels bzw. einer praktischen Anleitung zur Konfiguration von GRUB ist das unerheblich.

Ich habe doch beschrieben, wie es richtig geht: […] Vor was soll ich denn genau warnen?

Das ist inhaltlich schon in Ordnung. Es geht mir nur um die Formatierung als Warnbox. Wenn das Verhalten dieser Variablen bereits an anderer Stelle diskutiert wird, reicht ggf. auch ein Hinweis auf dieses Verhalten mit Verweis, z.B.

kB schrieb:

Ich habe doch beschrieben, wie es richtig geht: […] Vor was soll ich denn genau warnen?

Das ist inhaltlich schon in Ordnung. Es geht mir nur um die Formatierung als Warnbox. Wenn das Verhalten dieser Variablen bereits an anderer Stelle diskutiert wird, reicht ggf. auch ein Hinweis auf dieses Verhalten mit Verweis, z.B.

Achtung!

Der Wert der Variablen GRUB_DISTRIBUTOR modifiziert auch das Verhalten bei UEFI-Boot und "Secure Boot", siehe …

Schlug ich ja bereits vor:

UlfZibis schrieb:

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“)

Hej,

daß man mit GRUB_DISTRIBUTOR Menüpunkte (grub Menü) umformulieren kann, gelingt mir hier nicht! (Im UEFI Menü zwar schon, aber wenn schon grub, dann brauche ich das UEFI Menü nicht, oder umgekehrt: Wozu ein grub Menü, wenn ich das per UEFI erledige?)

Gruß black tencate