ubuntuusers.de

black_tencate schrieb:

Hej kb,

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

Im verlinkten Artikel chroot/Live-CD steht:

Um die Internetverbindung sicherzustellen, werden u.U. die DNS-Server-Angaben benötigt. Diese kopiert man mit:

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

Also „sicherzustellen“ und nicht „einzurichten”. So ergibt die Anweisung für mich zwar einen Sinn, der jedoch bei Ubuntu-Desktop-Systemen nicht erfüllt ist. Bei Ubuntu-Desktop-Systemen stehen die zu befragenden DNS-Server nämlich nicht in der Datei etc/resolv.conf, sondern hier steht nur der dynamisch erzeugte Verweis auf einen lokalen DNS-Cache (der dann seine Forwarder aus anderen Quellen (z.B. dbus) kennt). Wenn ein Live-Medium selbst eine Internet-Verbindung herstellen konnte, dann ist der o.g. mount-Befehl unnötig oder möglicherweise schädlich. Wenn noch keine Internet-Verbindung besteht, richtet der mount-Befehl auch keine ein.

Hej zusammen,

kB schrieb:

... Im verlinkten Artikel chroot/Live-CD steht:

Um die Internetverbindung sicherzustellen, werden u.U. die DNS-Server-Angaben benötigt. Diese kopiert man mit:

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

Also „sicherzustellen“ und nicht „einzurichten”.

ja, Du hast vollkommen recht, ich weiß nicht mehr, warum bei einem dieser Experimente ich im chroot keine Netzverbindung hatte, und auf die Idee mit dieser zusätzlichen Zeile verfallen bin (vielleicht war der Server gerade down?)

• Zeile kommt raus, nicht erforderlich.

bowman schrieb:

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

komisch, in einer aktuellen EFI-Installation (mit Xerus) sieht das so aus:

mackie@T520-XX-efi:~$ ls /boot
abi[...]
efi                           System.map-4.15.0-29-generic
grub                          System.map-4.15.0-42-generic
initrd[...]
mackie@T520-XX-efi:~$ sudo ls /boot/efi
EFI
mackie@T520-XX-efi:~$ sudo ls /boot/efi/EFI
ubuntu
mackie@T520-XX-efi:~$ sudo ls /boot/efi/EFI/ubuntu
fw  fwupx64.efi  grub.cfg  grubx64.efi	mmx64.efi  shimx64.efi
mackie@T520-XX-efi:~$ 

mackie@T520-XX-efi:~$ sudo mount /dev/sda1 /mnt
mackie@T520-XX-efi:~$ sudo ls /mnt
EFI
mackie@T520-XX-efi:~$ sudo ls /mnt/EFI
ubuntu
mackie@T520-XX-efi:~$ sudo ls /mnt/EFI/ubuntu
fw  fwupx64.efi  grub.cfg  grubx64.efi	mmx64.efi  shimx64.efi
mackie@T520-XX-efi:~$ 

mackie@T520-XX-efi:~$ cat /etc/fstab
# /etc/fstab: static file...
[...]
UUID=D473-ADB0  /boot/efi       vfat    umask=0077      0       1
mackie@T520-XX-efi:~$ 

Habe jetzt noch mal einen Versuch (grub bios->efi) gemacht, ohne eine /boot/efi anzulegen, einfach die esp nach /boot gemounted. Das funktioniert nicht, grub-install meldet Fehler.

(Ich wollte eigentlich das - bis auf EFI "leere" Verzeichnis /boot/efi auslassen und direkt ein /boot/EFI/ubuntu... als Ergebnis haben, aber, was nicht ist, das ist eben nicht)

Gruß black tencate

Hej,

habe bei einem erneuten Durchlauf vorher nicht einen vorhandenen "ubuntu" Eintrag im NVRAM gelöscht, mit dem Ergebnis, daß kein neuer Eintrag eingerichtet werden konnte. (Was habe ich mir da bloß an die Backe genäht? 😈 )

root@ubuntu:/#     apt-get install  grub-common grub-efi-amd64 os-prober
Paketlisten werden...
[...]
Creating config file /etc/default/grub with new version
Installing for x86_64-efi platform.
efibootmgr: Skipping unreadable variable "Boot001A": Input/output error
efibootmgr: Skipping unreadable variable "Boot001A": Input/output error
efibootmgr: Could not set variable Boot001A: Input/output error
efibootmgr: Could not prepare boot variable: Input/output error
installation beendet. Keine Fehler aufgetreten.
os-prober (1.70ubuntu3.3) wird eingerichtet ...
Trigger für systemd (229-4ubuntu21.4) werden verarbeitet ...
Running in chroot, ignoring request.
Trigger für ureadahead (0.100.0-19) werden verarbeitet ...
root@ubuntu:/# grub-install
Installing for x86_64-efi platform.
efibootmgr: Skipping unreadable variable "Boot001A": Input/output error
efibootmgr: Skipping unreadable variable "Boot001A": Input/output error
efibootmgr: Could not set variable Boot001A: Input/output error
efibootmgr: Could not prepare boot variable: Input/output error
installation beendet. Keine Fehler aufgetreten.
root@ubuntu:/# update-grub
Grub-Konfigurationsdatei wird generiert …
Warnung: Werte ungleich 0 für »GRUB_TIMEOUT« werden, falls »GRUB_HIDDEN_TIMEOUT« aktiviert ist, nicht mehr unterstützt.
Linux-Abbild gefunden: /boot/vmlinuz-4.15.0-29-generic
initrd-Abbild gefunden: /boot/initrd.img-4.15.0-29-generic
Windows Boot Manager auf /dev/sdb2@/EFI/Microsoft/Boot/bootmgfw.efi gefunden
erledigt
root@ubuntu:/# 

ubuntu@ubuntu:~$ sudo efibootmgr -v
BootCurrent: 000C
Timeout: 0 seconds
BootOrder: 000C,0009...
[...]
Boot0019* Windows Boot Manager	HD(2,GPT,3fb51ad4-965d-40be-81ed-5b9a5aedad82,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...r................
ubuntu@ubuntu:~$ 


ubuntu@ubuntu:~$ sudo ls -aR /mnt
/mnt:
.  ..  EFI  grub

/mnt/EFI:
.  ..  Boot  Microsoft	ubuntu

/mnt/EFI/Boot:
.  ..  bootx64.efi

[...]

/mnt/EFI/ubuntu:
.  ..  grubx64.efi

/mnt/grub:
.  ..  unicode.pf2
ubuntu@ubuntu:~$ 

Gruß black tencate

Habe jetzt noch mal einen Versuch (grub bios->efi) gemacht, ohne eine /boot/efi anzulegen, einfach die esp nach /boot gemounted.

nach /boot ? 😲

Das wäre dann die /boot-Partition, oder wie? Das das nicht geht, sollte klar sein, denn der NVRAM greift nur auf die EFI-System-Partition zu. Die /boot wäre ja dann die Boot-Partition von Ubuntu, dann ist aber keine esp vorhanden, mit der das UEFI kommunizieren kann um der Grub2 zu starten. Oder verstehe ich da was falsch?

Hej bowman,

bowman schrieb:

...Das das nicht geht, sollte klar sein, denn der NVRAM greift nur auf die EFI-System-Partition zu.

nein, das ist mir nicht so klar. Wohin die esp gemountet wird, sollte imo egal sein, ob nun nach /boot/efi oder eben nur nach /boot. aber das System sagt mir das dann schon, daß es so eben nicht funktioniert, wie schön 😈

Und je öfter ich fummele, je mehr entdecke ich. (z.B. ein sudoedit /mnt/etc/fstab noch im chroot ist das wohl falsch 1. sudo, 2, /mnt; rufe ich aber im chroot nur edit /etc/fstab auf, geht gar nichts, Oh Linux!

Gruß black tencate

Deshalb mache ich das immer mit Nano aus der chroot, da weis ich, dass es funktioniert. Grafische Editoren funktionieren mit dem Live-System nicht. Das hab ich schon vor Jahren selbst erfahren.

Dann sollten wir das noch ändern, oder?

Vim oder Nano? Was meinst du, welcher besser zu handhaben ist? Bei Nano ist immer das doppelte Speichern das doofe. Als ich das erste Mal - als Linux-Noob - damit gearbeitet habe, bekam ich fast die Krise. "Warum speichert das nicht, ich will nicht umbenennen." Bis ich es dann endlich gecheckt hatte und noch Strg+O, dann war´s gespeichert.

Prinzipiell kann man das auch im laufenden System im BIOS-Mode machen, bevor die Umstellung auf den EFI-Mode erfolgt.

Geht dann halt nur, wenn bereits eine esp vorhanden ist und man die UUID auslesen kann.

Wird die erst aus dem Live-System angelegt geht´s nicht mehr.

Ich hab das mal so gemacht, als ich mir eine separate /home erstellt habe. Da war dann die fstab schon angepasst, bevor ich aus der Konsole das /home-Verzeichnis auf die neue Partition umgezogen haben. Absolut unschädliche, weil die fstab nur beim Start ausgelesen wird.

hey black_tenkate

ich hab mir jetzt die Dateien bei meinem Xubuntu, das als 16.04 im EFI-Mode installiert wurde und dann per Upgrade auf 18.04.1 kam, angesehen

## Verzeichnis /boot auf der /-Partition
sudo ls -aR /boot
/boot/efi/EFI/BOOT:
.  ..  BOOTX64.EFI  fbx64.efi
/boot/efi/EFI/ubuntu:
.  ..  BOOTX64.CSV  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi
## Auf der esp-Partition
sudo mount /dev/sda1 /mnt
sudo ls -aR /mnt
/mnt/EFI/BOOT:
.  ..  BOOTX64.EFI  fbx64.efi
/mnt/EFI/ubuntu:
.  ..  BOOTX64.CSV  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi

Für mich sieht das so aus, als ob in beiden Verzeichnissen die selben Dateien abgelegt (gespiegelt?) werden. Allerdings sind Verzeichnisse und einzelne Dateien anders als bei deinem direkt installierten 18.04.

Der Unterschied besteht in der Bezeichnung der Pfade. Der NVRAM kommuniziert aber meines Wissens nur mit der esp.

Eintrag im NVRAM → shimx64.efi → grubx64.efi → grub.cfg → kernel-image → System-Start.

Da die Dateien auch in der /boot/efi/EFI abgelegt werden, kann man das System auch unter Umgehung der esp über die /boot/efi/EFI/ubuntu/grub.cfg booten, aber nur mit einem Bootloader wie z.B. einem EFI USB-Stick, der einen entsprechenden Menuentry dafür hat. Das klappt - hab es probiert.

Hej bowman,

bowman schrieb:

Deshalb mache ich das immer mit Nano aus der chroot, da weis ich, dass es funktioniert. Grafische Editoren funktionieren mit dem Live-System nicht. Das hab ich schon vor Jahren selbst erfahren.

Dann sollten wir das noch ändern, oder?

nein, nei, das klappt schon. Und btw.: Das scheint mir sozusagen identisch (nano und sudoedit), der Knackpunkt ist nur, wenn man noch im chroot ist, muß es natürlich /etc/fstab heißen, außerhalb dann aber /mnt/etc/fstab

.dann endlich gecheckt hatte und noch Strg+O, dann war´s gespeichert.

ja, aber dann muß man auch noch die Pfadvorgabe checken (/var/tmp/fstab.xyzrteb 😬 )

Geht dann halt nur, wenn bereits eine esp vorhanden ist und man die UUID auslesen kann.

eine vorhandene esp - so oder so - ist ja Vorausetzung für das Ganze hier!

Wird die erst aus dem Live-System angelegt geht´s nicht mehr.

Ähhh, warum; die wird ja vor dem chroot angelegt, da kann ich doch die UUID auslesen und in die fstab schreiben!

bowman schrieb:

... Für mich sieht das so aus, als ob in beiden Verzeichnissen die selben Dateien abgelegt (gespiegelt?) werden. Allerdings sind Verzeichnisse und einzelne Dateien anders als bei deinem direkt installierten 18.04.

das soll hier keine Rolle spielen, und

...Da die Dateien auch in der /boot/efi/EFI abgelegt werden

nein, nicht abgelegt, das ist nur gemountet (s. fstab)

OT

...kann man das System auch unter Umgehung der esp über die /boot/efi/EFI/ubuntu/grub.cfg booten

Ähhh, da steht die grub.cfg nicht!

meckie@T520-XX-bios:~$ sudo efibootmgr -v
[sudo] Passwort für meckie: 
BootCurrent: 001A
Timeout: 0 seconds
BootOrder: 001A,000C,0009,000A,0019,0008,000B,0006,0007,000D,000E,000F,0010,0011,0012,0013
[...]
Boot001A* ubuntu	HD(2,GPT,3fb51ad4-965d-40be-81ed-5b9a5aedad82,0xfa000,0x32000)/File(\EFI\ubuntu\grubx64.efi)
meckie@T520-XX-bios:~$

sondern hier

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

und die kann man von jedem grub aus laden. Habe gerade mal auf "legaxy only" umgestellt, 'nen passenden Stick gebootet mit grub, von dort das configfile mit

set root=(hd1,1)
configfile /boot/grub/grub.cfg

und schon konnte ich linux/Meckie laden.

meckie@T520-XX-bios:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 
BIOS
meckie@T520-XX-bios:~$ 

der Rechner heißt noch T520-XX-bios, weil er ja als solcher aufgesetzt wurde zwecks grub_Umstellung. (eine ls -aR /boot hänge ich mal in den Anhang, da kannst Du die gemountete esp erkennen, und auch sehen, daß die alten grub i386-pc Dateien auch noch vorhanden sind. Wahrscheinlich könnte ich dieses Linux sogar noch mit dem MBR booten (?))

/OT

Von meiner Seite kommt jetzt nichts (weltbewegendes) mehr, wir können "fertig" melden.

Gruß black tencate

Da liegt ein Mistverständnis vor.

Ich sprach vom Ändern der fstab aus dem im BIOS-Mode laufenden System. Also bevor das Live-System gestartet wird.

...Da die Dateien auch in der /boot/efi/EFI abgelegt werden

nein, nicht abgelegt, das ist nur gemountet (s. fstab)

💡 Ah, die esp wird also im Verzeichnis /boot/efi (auf der /) eingehängt. Dann ist aber auch klar, dass der Pfad zu den ###.efi-Dateien nur /boot/efi/EFI/ubuntu heißen kann, weil zwei Pfade von System und esp so miteinander gekoppelt werden.

Das erklärt dann auch die Schreibweise. Bei .../efi endet der Pfad auf der / und mit EFI/... beginnt der Pfad auf der esp.

Mich hat die Ausgaben von ls -aR /mnt verwirrt. 😕 Wenn ich die Pfade mit ls einzeln abklopfe sieht das ganz anders aus. ☺

Dann ist aber auch klar, warum die esp nicht als /boot eingebunden werden kann. Dann fehlt der Teil-Pfad /boot/efi auf dem die esp gemounted werden muss. Das UEFI startet dann lediglich shimx64.efi bzw. grubx64.efi, die dann die grub.cfg in der /boot/grub/ aufrufen. Jetzt lichtet sich der Nebel. Wäre auch etwas seltsam gewesen ...

Man lernt halt nie aus. Jetzt weis ich auch, dass man aufpassen muss beim Auslesen der Pfade. 😀

Hey black_tenkate

Ich hab noch ein Bisschen gewütet.

Die Nacharbeit etwas strukturiert. Hinweis zum Editieren der fstab mit Editor. Noch eine Stolperfalle eingefügt. Tippfehler korrigiert.

Ich finde den Artikel jetzt schön übersichtlich.

Von mir aus wäre er jetzt auch fertig. 😀

Hallo ihr beiden!

Ein paar kosmetische Vorschläge hätte ich:

Der Zweck des Abschnitts "Zweck" ist mir nicht klar. Der Zweck wurde im Vorwort ab "unter bestimmten Umständen......" hinreichend erklärt. Ich würde darüber "Zweck" titulieren (oder ganz weglassen) und den Satz im derzeitigen Zweck mit "Im folgenden Artikel........" ergänzen.

Da ein kleiner Flüchtigkeitsfehler schon ausreicht um den Erfolg der Umstellung des GRUB 2 komplett zu verhindern

.....ausreicht, um.......

Sollte keine esp Partition im System existieren - z.B. auf der Windows 10 Platte - muss diese zuerst angelegt werden.

Wir gehen von einem W10 im EFI-Modus aus, ergo muss eine ESP vorhanden sein. Andernfalls ist es Legacy.

Dafür wird zunächst im Setup auf EFI-Modus umgestellt

Sollte man das vielleicht noch näher erklären oder verlinken? Auch um z.B. die vermaledeiten both oder first Modi zu vermeiden.

die "/" Partition mounten nach /mnt.

die "/" (= Systempartition) Partition mounten nach /mnt.

grub-efi dateien installieren

grub-efi Dateien installieren

Bei signierten Kerneln, welche auch mit aktiviertem secureboot booten können,......unabhängig davon ob secureboot aktiviert ist oder nicht.

Bei signierten Kerneln, welche auch mit aktiviertem Secureboot booten können,......unabhängig davon ob Secureboot aktiviert ist oder nicht.

Ansonsten: Well done! 👍

L.G.

Hej Ali_As,

Ali_As schrieb:

... Der Zweck des Abschnitts "Zweck" ist mir nicht klar. Der Zweck wurde im Vorwort ab "unter bestimmten Umständen......" hinreichend erklärt. Ich würde darüber "Zweck" titulieren (oder ganz weglassen) und den Satz im derzeitigen Zweck mit "Im folgenden Artikel........" ergänzen.

*grübel*...*denk*...*schulterzuck*...hmmmm

Sollte keine esp Partition im System existieren - z.B. auf der Windows 10 Platte - muss diese zuerst angelegt werden.

Wir gehen von einem W10 im EFI-Modus aus, ergo muss eine ESP vorhanden sein. Andernfalls ist es Legacy.

richtig, aber das Ganze gilt natürlich auch für eine Umstellung eines Ubuntu ohne Beisein eines W10.

Dafür wird zunächst im Setup auf EFI-Modus umgestellt

Sollte man das vielleicht noch näher erklären oder verlinken? Auch um z.B. die vermaledeiten both oder first Modi zu vermeiden.

meinst Du etwa hier und ff? *grrrr* Wer diese Prozedur durchführen möchte (statt einer Neuinstallation), der weiß, was zu tun ist. Und wohin möchtest Du da verlinkt sehen? (etwa so) lol, nein, im Ernst.

die "/" Partition mounten nach /mnt.

die "/" (= Systempartition) Partition mounten nach /mnt.

auch das sollte ohne die Klammer klar sein; wie ja auch an div. Stellen die erforderlichen Befehle - bewußt - nicht in

Befehl

oder

Befehl 

geschrieben sind, um hier nicht den Eindruck eines HowTo/Kochbuch aufkommen zu lassen.

...Bei signierten Kerneln, welche auch mit aktiviertem Secureboot

hmmm, k.a., ob man das groß schreiben soll?

Danke für die Hinweise.

Gruß black tencate

Moin Moin!

*grübel*...*denk*...*schulterzuck*...hmmmm

Ist nur ein Vorschlag! Ich hasse Unterartikel oder Sinneinheiten, die nur aus einem Satz bestehen. In meinem (früheren) Job wär mir so was meist um die Ohren geflogen. Deshalb bin ich da etwas pingelig.

lol, nein, im Ernst.

Das führt ggf. zu weit, ich weiß! Aber ich weiß auch, was die falsche Einstellung für fatale Auswirkungen hat. Und "EFI-Modus" kann alles mögliche sein, eben auch als Teil von both oder first oder sogar Teil von CSM (Asus-Boards). Eine angefügte Klammer mit z.B.(also ggf. kein "both", "first" oder "legacy") würde da schon etwas mehr Klarheit schaffen.

"Secureboot" ist schlicht ein Substantiv oder Nomen, also Großschreibung.

L.G.

Hej Ali_As,

Ali_As schrieb:

...Unterartikel oder Sinneinheiten, die nur aus einem Satz bestehen. [...] meist um die Ohren geflogen

hab mal ein bißchen dran geschraubt.

'OT
Oh, ich hatte mal in E-Physik den Herrn Prof. Lautz, der hatte 2 Bücher in den beiden Semestern, Buch 1 gegliedert bis zum geht-nicht-mehr (1.2.1.1.1; 1.2.1.1.2) und das ganze Buch 2 bestand aus Kapitel 2. 🤓
/OT

lol, nein, im Ernst.

Das führt ggf. zu weit, ich weiß! Aber ich weiß auch, was die falsche Einstellung für fatale Auswirkungen hat. Und "EFI-Modus" kann alles mögliche sein, eben auch als Teil von both oder first oder sogar Teil von CSM (Asus-Boards). Eine angefügte Klammer mit z.B.(also ggf. kein "both", "first" oder "legacy") würde da schon etwas mehr Klarheit schaffen.

also: Ich kann "both" einstellen, falls dann der Boot im legacy (eben wegen 2legacy first") erfolgt sein sollt (was ich ja sofort dank meiner "EierlegendenWollMilchSau" sofort erkenne 😈 ), müßte doch aber die vorgeschriebene Prüfung mit

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 

Klarheit liefern.

Da warte ich ja gespannt auf den ersten Kandidaten, der mir als Ergebnis der Prüfung - bei welchem Modus auch immer außer EFI - ein "BIOS" präsentiert. ( 😀 )

Gruß black tencate

Hej,

habe gerade mal EFI USB-Stick ▶ UEFI-bootfaehiger USB-Stick ohne Hilfsmittel getestet, auf meinem T520 jedenfalls bootet so ein Stick nur, wenn das Setup auf EFI eingestellt ist.

Ganz schön viele Hinweise zum Verwenden des EFI Modus 😈

Gruß black tencate