ubuntuusers.de

Hej,

der Nikolaus war da.

Gruß black tencate

Hey Nikolaus

du warst ja schon sehr fleißig.

Dann gehen wir es mal an.

Gruß bowman

Edit:

Habe Senf dazu geben und bissle korrigiert.

Bemerkungen zu:

? GUI zum Bearbeiten der /etc/fstab? kein gksu in 18.04 (Feature! kein Bug)

? wie muss Eintrag in der /etc/fstab lauten? Verschieden Einträge möglich? Wann welche oder gehen beide?

? Abfrage auch des Inhalts der /boot/efi? nicht nur NVRAM auslesen.

Hej bowman,

bowman schrieb:

... ? GUI zum Bearbeiten der /etc/fstab? kein gksu in 18.04 (Feature! kein Bug)

Hmm, ich zieh' schon mal den Kopf ein

• nach Verlassen von chroot ist man ja wieder im LiveSystem, da könnte einem Das Verbiegen der Rechte auch egal sein (frech sudo gedit...), aber es gibt ja noch

  • Programm admin://<URL> (doof mit der doppelten pw-Abfrage)

  • sudo -H

  • pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY PROGRAMMNAME (was man -ich bin zu blöd dazu - sich ja als script mit $VARIABLE bereitstellen kann.

(mit Root-Rechten arbeiten)

? wie muss Eintrag in der /etc/fstab lauten? Verschieden Einträge möglich? Wann welche oder gehen beide?

ich wünschte mir dazu die Antwort eines fstab-Fachmanns

? Abfrage auch des Inhalts der /boot/efi? nicht nur NVRAM auslesen.

guter Hinweis

Gruß black tencate

Hej bowman,

nach einer "normalen" EFI Installation habe ich auch hier

# /boot/efi was on /dev/sdb2 during installation
UUID=5A8E-000B  /boot/efi       vfat    umask=0077      0       1

mal sehen, ob dazu noch jemand was zu sagen hat?

Gruß black tencate

Hallo ihr beiden!

Ich hab' etwas Schwierigkeiten mit ....

Nachbemerkung

Ein wie oben beschriebener Wechsel ist zwingend erforderlich, falls kein anderer Bootloader bereits vorhanden ist. Ein EFI-Windows bootmgr - erweitert mit EasyBCD - ist nicht in der Lage, ein "BIOS"-Linux zu starten, ein EFI-Linux aber sehr wohl.

Mit dem Windows Boot Manager kann man ja zunächst mal Linux starten, über das Menü "ein Gerät verwenden" oder so ähnlich. Des weiteren kann man in Windows mit dem Tool "EasyUEFI" (nicht zu verwechseln mit EasyBCD) die Einträge im NVRAM bearbeiten, ähnlich wie efibootmgr, nur grafisch. Ist also ein Eintrag vorhanden, sollte er hier eigentlich erkannt werden. Mit EasyBCD würd ich gar nichts machen an einer EFI-Konfiguration.

L.G.

Ich habe noch mal gewütet.

Habe die Abfrage der Ordner und Dateien in der esp eingefügt, mit Hinweis auf efibootmgr.

Hinsichtlich der Einbindung der esp in der fstab habe ich im Netz verschiedene Schreibweisen gefunden

UUID=5A8E-000B /boot/efi   vfat   defaults   0    0
UUID=5A8E-000B /boot/efi   vfat   defaults   0    1
UUID=5A8E-000B /boot/efi   vfat   defaults   0    2
UUID=5A8E-000B  /boot/efi  vfat   umask=0077  0    0
UUID=5A8E-000B  /boot/efi  vfat   umask=0077  0    1 
UUID=5A8E-000B  /boot/efi  vfat   umask=0077  0    2 
u.a

teilweise noch mit anderen, zusätzlichen Optionen, wie noatime,discard und anderen, je nach Distrie.

Bei meinem Xubuntu ist ebenfalls der markierte Eintrag zu finden.

Sollen wir dann den vorgeben und evtl. darauf hinweisen, dass es noch andere Möglichkeiten gibt?

Der Hinweis von Ali-As ist mir auch schon aufgefallen. EasyBCD kann meines Wissens kein UEFI und ich habe die Textpassage mal in EasyUEFI umgeändert.

Auf alle Fälle ist das ein super Entwurf von dir black_tencate und die Feinarbeit kriegen wir auch noch hin. 👍

Edit. Was ein Mist. Jetzt hab ich vergessen die Änderungen im Artikel zu speichern und darf alles noch mal machen. Aber heute nicht mehr.

Hej,

habe jetzt mal div. Bemerkungen von Euch eingearbeitet, selber einen Absatz ins Vorwort vorgezogen, Bionic getestet. Kann man alles sehen im "Verlauf → Vergleich".

anbei auch noch ein Terminalverlauf (aktuell mit 18.04)

Gruß black tencate

PS.: bin erst So. wieder bereit.

Hej,

hatte wohl das update-grub vergessen, nachzulesen in terminal-18.04-grub-bios-efi.txt

*grrrr*

Läuft.

Gruß black tencate

Aha, du hast gestern Nacht gleichzeitig mit mir am Artikel gearbeitet.

Da war dann von mir alles futsch, alte Nachteule. 😈

Ich hab die Passage zur Abfrage der Boot-Dateien in der /boot/efi/ubuntu überarbeitet und einen Hinweis auf die shimx64.efi eingefügt.

Fand ich wichtig, weil das OS nicht booten kann, wenn nicht über diese Datei gegangen wird, wenn sie vorhanden ist. Egal ob secure boot aktiv ist oder nicht.

Ich finde, das sieht schon ganz gut aus.

Schön, dass du einen Rechner mit viel Platz hast und das alles ausprobieren kannst, ob es auch funktioniert.

War ja nur so eine Idee von mir. Du hast es getestet. 👍

Nochmal Danke.

hatte wohl das update-grub vergessen, nachzulesen in terminal-18.04-grub-bios-efi.txt

*grrrr*

Noch ein Fallstrick. Die Liste wird immer länger. 😀

Vielleicht sollten wir einen Hinweis einfügen, dass diese Aktion Schritt für Schritt geplant und dann Punkt für Punkt abgearbeitet werden muss.

So kleine Flüchtigkeiten crashen die ganze Aktion.

Hej bowman,

der Hinweis zum exakten planen und abarbeiten ist gut, evt. auch die weitere Stolperfalle.

Ich hätte noch einen Punkt unter Nacharbeiten

• Entfernen der alten grub Dateien in /boot

und der mountpoint sollte /boot/EFI heißen; sonst hat 's den quasi 2x, 1x groß und 1x klein.

Zu Secureboot kann ich nichts testen (und sagen), habe ich nicht auf dem T520. Bin allerdings erst Sonntag wieder am Rechner, am Smartphone ist das eine Qual.

Gruß black tencate

4. im gewechselten System wird eine Internetvebindung zwecks Installation von grub-efi benötigt.

Ja, aber:

Einzurichten mit:

sudo mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf

überrascht mich. Dies erscheint mir weder notwendig noch hinreichend noch sinnvoll zu sein. Das Live-System kann selbst eine Netzmerkverbindung aufbauen. Wichtig wegen chroot erscheint mir, dass dies statisch erfolgt und nicht irgendwelche Dateien voraussetzt, die Zustandsdaten speichern. D.h. nicht den NetworkManager benutzen und auch nicht systemd-networkd, sondern das gute alte ifup mit einer kurzen Datei /etc/network/interfaces:

# /etc/network/interfaces im neuen root /
iface dhcp inet dhcp

Die neue Netzwerkverbindung aktiviert man nach Abbau aller automatisch eingerichteten Netzwerke per

sudo ifup SCHNITTSTELLE=dhcp 

wobei man natürlich für SCHNITTSTELLE den richtigen Namen derselben einsetzen muss.

Hej kb,

und warum steht das dann genauso in den verlinkten chroot Artikeln?

Da ich der absolute Netzwerklaie bin - ich habe vielleicht vor 20 Jahren mal irgendwie ein Modem an die Telefonleitung geklemmt, heute ärgere ich mich maßlos, wenn ich zu Testzwecken ein W7 installiere, daß ohne entsprechende Treiber, die man ja nicht, partout nicht ans Netz bekommt. Schon nicht schlecht so ein LiveSystem von Ubuntu -, kämme ich ja dann noch eher auf die Idee, im noch laufenden "BIOS" System die grub Dateien zu tauschen, dann brauche ich im chroot kein Netz.

Gruß black tencate

black_tencate schrieb:

der Hinweis zum exakten planen und abarbeiten ist gut,

Habe ich mal eingearbeite, ganz am Anfang.

evt. auch die weitere Stolperfalle.

Ich hätte noch einen Punkt unter Nacharbeiten

• Entfernen der alten grub Dateien in /boot

Rein schreiben, du bist der Praktiker und hast es getestet.

und der mountpoint sollte /boot/EFI heißen; sonst hat 's den quasi 2x, 1x groß und 1x klein.

Wo? Weis jetzt nicht, was du meinst.

Zu Secureboot kann ich nichts testen (und sagen), habe ich nicht auf dem T520.

Ich schon. Bei meinem Rechner ist das Secureboot deaktiviert - war auchbei der Installation so. Hab aber einen signierten Kernel bekommen und boote aus der shimx64.efi. Hab auch mal in einem Thread mitgearbeitet, wo das dann Thema wurde. Secureboot deaktiviert und mit dem Eintrag, der auf die grub64.efi verweist, konnte nicht gebootet werden. Deshalb hab ich es ja rein geschrieben. 😉

Gruß bowman

Hej bowman,

bowman schrieb:

...

evt. auch die weitere Stolperfalle.

Ich hätte noch einen Punkt unter Nacharbeiten

• Entfernen der alten grub Dateien in /boot

Rein schreiben, du bist der Praktiker und hast es getestet.

(bin noch nicht soweit), bin erstmal gestolpert darüber, daß ubiquity bei einer efi-Installation von sich aus keine esp anlegt 😮 (suche gerade nach der geeigneten Wikiseite dafür (9032041, das ist aber hier nicht von Belang)

Zum Entfernen der alten grub Dateien wird man ja während der Deinstallation aufgefordert, nur ist "JA" nicht aktiv, das muß man umstellen, um aber dann doch nicht entfernt werden:

• Auszug aus dem neuen Anhang (in der 1. Hinweisbox)

  root@ubuntu:/#     apt-get purge grub-common grub-pc os-prober
  Paketlisten werden gelesen... Fertig
  Abhängigkeitsbaum wird aufgebaut.       
  Statusinformationen werden eingelesen.... Fertig
  Die folgenden Pakete werden ENTFERNT:
    grub-common* grub-gfxpayload-lists* grub-pc* grub-pc-bin* grub2-common* os-prober*
  0 aktualisiert, 0 neu installiert, 6 zu entfernen und 195 nicht aktualisiert.
  Nach dieser Operation werden 16,8 MB Plattenplatz freigegeben.
  Möchten Sie fortfahren? [J/n] j
  (Lese Datenbank ... 179451 Dateien und Verzeichnisse sind derzeit installiert.)
  Entfernen von os-prober (1.70ubuntu3.3) ...
  Entfernen von grub-pc (2.02~beta2-36ubuntu3.18) ...
  Löschen der Konfigurationsdateien von grub-pc (2.02~beta2-36ubuntu3.18) ...
  Entfernen von grub-gfxpayload-lists (0.7) ...
  Entfernen von grub-pc-bin (2.02~beta2-36ubuntu3.18) ...
  Entfernen von grub2-common (2.02~beta2-36ubuntu3.18) ...
  Entfernen von grub-common (2.02~beta2-36ubuntu3.18) ...
  Running in chroot, ignoring request.
  Running in chroot, ignoring request.
  Running in chroot, ignoring request.
  Running in chroot, ignoring request.
  Running in chroot, ignoring request.
  Löschen der Konfigurationsdateien von grub-common (2.02~beta2-36ubuntu3.18) ...
  Running in chroot, ignoring request.
  Running in chroot, ignoring request.
  Trigger für man-db (2.7.5-1) werden verarbeitet ...
  Trigger für install-info (6.1.0.dfsg.1-5) werden verarbeitet ... 

  und

• mackie@T520-XX-bios:~$ sudo ls /boot/grub
  fonts  grub.cfg  grubenv  i386-pc  locale  unicode.pf2	x86_64-efi
  mackie@T520-XX-bios:~$

ist aber eher irrelevant, ob die "alten" grub-Dateien vorhanden sind oder nicht.

und der mountpoint sollte /boot/EFI heißen; sonst hat 's den quasi 2x, 1x groß und 1x klein.

Wo? Weis jetzt nicht, was du meinst.

das kann man wohl gar nicht ändern, ubiquity legt (z.B. in einer efi-Modus Installation) ein /boot/efi an, in welches dann die esp mit ihrem /EFI/... eingebunden wird. Hatte mal testweise in einer Umstellung ein Verzeichnis /boot/EFI angelegt, mit dem Ergebnis, daß grub-install einen Fehler meldet (etwas wie "kann target ...x86_64-efi nicht finden" (oder so, hab 's nicht dokumentiert, da Abbruch erforderlich war). Ob es dann etwas bringt, das explizit anzugeben mit --target=<Pfad>x86_64..., keine Ahnung (und keine Lust, das auszuprobieren, muß ich halt mit 2x efi leben → /boot/efi/EFI/... na und!)

@kB, kommt da noch etwas bezüglich i-net innerhalb chroot?

Ich wäre dann soweit fertig, ggf. noch weitere Verschönerungen lassen sich ja auch anbringen, wenn der Artikel aus der Baustelle ins Wiki verschoben ist

Gruß black tencate

Hallo black_tenkate

Ich habe meine EFI-Installation damals - wie immer - per manuelle Partitionierung gemacht und dabei alle Partitionen zugewiesen.

Bei mir ist damit in der esp die Verzeichnisstruktur /boot/EFI/ubuntu enstanden.

Ich habe in der esp aber vorher kein Verzeichnis erstellt, sondern eine leere esp in FAT32 zur Verfügung gestellt, in das der Bootloader dann geschrieben wurde. Dabei muss dann wohl das Verzeichnis auch mit erstellt worden sein.

EDIT: Das war allerdings ein Xubuntu 16.04.1, das ich im Juli durch einen Upgrade auf 18.04.1 gelupft habe.

Die EFI-Installation wurde damals also mit 16.04 gemacht. Kann das jetzt ein Bug in Ubuquity von 18.xx sein?