ubuntuusers.de

Hi black_tencate,

hatte ich schon versucht, aber ohne Effekt...

Die grub.cfg aus der "/boot"-Partition in die esp-Partition zu kopieren macht nicht viel Sinn oder? Funktioniert im Zweifelsfall auch nur bis zum nächsten Kernel, weil jedes update-grub alles zerschießt oder?

Oder könnte ich GRUB beibringen, dann direkt in die esp zu schreiben?

Hej san04,

san04 schrieb:

Das System lief jetzt im EFI-Modus, aber das UEFI-BIOS kriegt es nicht gestartet.

an genau der Stelle solltest Du ja noch mal ein sudo grub-install machen
(siehe
black_tencate schrieb:

... Im laufenden System die neu ESP nach /boot/efi mounten und dann ein sudo grub-install. Danach den Inhalt von /boot/efi überprüfen, ebenso wie die Einträge im NVRAM.

Das ist zwar im Prinzip™ dasselbe wie schon oben mit dem chroot…aber man weiß ja nie!

)

Ein etwaiges Hineinkopieren in die <ESP>/grub.cfg kannst Du ja mal versuchen, ich würde dort die Symlinks aufrufen, also …set root…, linux /vmlinuz… und initrd /initrd.img, aber, beim nächsten Einlaufen neuer grub-Dateien mit einem einhergehenden grub-install spätestens wird das wieder überschrieben.

Ich kann hier in der VM nicht nachstellen, was es mit der "device-Verschiebung" durch den Kartenleser auf sich hat, und leider fällt mir jetzt auch nichts mehr so richtig ein.

Gruß black tencate

HI black_tencate,

an genau der Stelle solltest Du ja noch mal ein sudo grub-install machen

hab ich, hab ich: Siehe → dieser Post:

user@user-OptiPlex-7010:~$ sudo -i
[sudo] Passwort für user: 
root@user-OptiPlex-7010:~# ls -aR /boot/efi/
/boot/efi/:
.  ..
root@user-OptiPlex-7010:~# grub-install
x86_64-efi wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
root@user-OptiPlex-7010:~# ls -aR /boot/efi/
/boot/efi/:
.  ..  EFI

/boot/efi/EFI:
.  ..  BOOT  ubuntu

/boot/efi/EFI/BOOT:
.  ..  BOOTX64.EFI

/boot/efi/EFI/ubuntu:
.  ..  grub.cfg  grubx64.efi
root@user-OptiPlex-7010:~# 

# less /boot/efi/EFI/ubuntu/grub.cfg 
search.fs_uuid c6a09940-8791-4e76-9256-14918ab02d49 root hd0,msdos3 
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0000,0003
Boot0000* ubuntu	HD(1,MBR,0x930af656,0x800,0x19000)/File(\EFI\ubuntu\grubx64.efi)
Boot0003* UEFI: SanDisk USB Ultra 1100	PciRoot(0x0)/Pci(0x1a,0x0)/USB(1,0)/USB(4,0)/HD(1,MBR,0x2cf4ba3a,0x506fcc,0x1f40)AMBO

Das war alles aus dem EFI-gebooteten System, aber leider mit dem gleichen Ergebnis wie aus der chroot-Umgebung...

Ich kann hier in der VM nicht nachstellen, was es mit der "device-Verschiebung" durch den Kartenleser auf sich hat, und leider fällt mir jetzt auch nichts mehr so richtig ein.

Den Kartenleser hab ich jetzt abgezogen und probiere nochmal ein bisschen mit dem Hineinkopieren rum. Eigentlich sollte ja wie gesagt echt nicht mehr viel fehlen... Aber sonst läuft es in diesem Fall wohl tatsächlich auf eine Neuinstallation hinaus.

Ein großes Dankeschön trotzdem schon einmal für den Input, die vielen Tipps und deine Zeit!!!

Grüße

san04

Der Kartenleser ist abgesteckt und folgendes funktioniert händisch aus dem GRUB-Menü reproduzierbar, um das System im EFI-Modus zu starten:

grub> set root=(hd1,msdos3) 
grub> linux /vmlinuz root=/dev/mapper/ubuntu--vg-root
grub> initrd /initrd.img
grub> boot

Ein update-grub schreibt nur die /boot/grub/grub.cfg.

Ein grub-install schreibt die /boot/efi/EFI/ubuntu/grub.cfg neu:

# cat /boot/efi/EFI/ubuntu/grub.cfg 
search.fs_uuid c6a09940-8791-4e76-9256-14918ab02d49 root hd0,msdos3 
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

Manuelles Anpassen auf hd1 hat keinen Effekt (laut Grub-Manual wird der Teil eh nur verwendet, falls die UUID doppelt vergeben ist).

Die UUID ist diejenige von /boot:

$ lsblk -lf | grep /boot
sda1              vfat                                   9546-986F                                44,3M    10% /boot/efi
sda3              ext2                                   c6a09940-8791-4e76-9256-14918ab02d49    137,9M    58% /boot

Im neu installierten System bin ich auf GPT und ext4 umgestiegen, ansonsten sieht alles identisch aus. Aber es scheint an dieser "simplen" Weiterleitung von der EFI grub.cfg auf die boot grub.cfg zu haken...

Was hier in den Tiefen von GRUB schief läuft, wird für mich wohl leider ein Rätsel bleiben ☹

Hallo san04,

Dann mal bitte die beiden .cfg Dateien vergleichen, insbesondere der Teil mit den UUIDs.

Gruss Lidux

Hi Lidux,

die beiden grub.cfgs in esp und /boot/grub zu vergleichen ist nicht zielführend, da sie völlig unterschiedliche Aufgaben haben/erfüllen.

Die nicht funktionierende Installation mit der funktionierenden ist wie oben beschrieben identisch (die UUIDs sind natürlich unterschiedlich, aber jeweils die der boot-Partition, passt also...)

Grüße

san04

Moin,

nicht alle Rechner unterstützen EFI-Boot mit MSDOS-Partitionstabelle. Die muss zuerst mal in GPT konvertiert werden:

1
2
3

sudo gdisk /dev/sda
w
y

Das konvertiert die Partitionstabelle in GPT, natürlich ohne die Daten zu löschen (die Meldung ist etwas irreführend, weil mit "Partitionen werden überschrieben" lediglich die Werte in der Partitionstabelle gemeint sind und nicht die Partitionen an sich).

Gruß Thomas

Hi TK87,

danke für den Hinweis, werd ich demnächst mal probieren.

Ich wusste nicht, dass die Konvertierung so einfach und ohne Datenverlust durchführbar ist.

Viele Grüße

Jup, geht ziemlich einfach.

Noch als kleine Ergänzung: Es kann sein, das gdisk meldet die Partitionstabelle wäre um 33 Blöcke zu groß (bei GPT werden, anders als bei MSDOS, auch am Ende des Datenträgers geschrieben Daten geschrieben).

In dem Fall musst du einfach vor der Konvertierung mit einem Partitionierungswerkzeug deiner Wahl die letzte Partition um 33 Blöcke ( 33 x 512 = 16896 Bytes ) verkleinern.

Hej TK87,

TK87 schrieb:

...Die muss zuerst mal in GPT konvertiert werden:

1 2 3

sudo gdisk /dev/sda w y

so aber ganz bestimmt nicht.

• sudo gdisk /dev/sda

  • ruft das Menü auf

• w

  • schreibt die Einstellungen auf die disk (ändert aber nichts,da zuvor keine vorgenommen wurden!)

• y

  • bestätigt eine Abfrage (da war aber nichts abzufragen!)

Schau halt mal in man gdisk, da findet man

• im ersten Menü (nichts zum Konvertieren, aber) u.a.

  • r Enter the recovery & transformation menu

  • x Enter the experts' menu

im 2.Menü (r) dann

• g Convert GPT into MBR and exit

• f Load MBR and build fresh GPT from it

• t Transform BSD partitions into GPT partitions

also hätte Dein Typ lauten müssen

sudo gdisk /dev/sdx # "x" für das richtige device
r
f # (mit y abschließen)
w # (mit y abschließen)

Hinweis: Die Warnung Warning! This will destroy the currently defined partitions! Proceed? (Y/N):kann man der Mutige) getrost vergessen.

Noch eins, das hier
san04 schrieb:

Das System lief jetzt im EFI-Modus, aber das UEFI-BIOS kriegt es nicht gestartet. Ich lande bei dem gleichen Screen: No bootable devices found.

hast Du gelesen?

@san04, ich glaube nicht, daß dich das weiter bringt (ist aber nur ein Gefühl).

Gruß black tencate

Moin black_tencate,

black_tencate schrieb:

• w

  • schreibt die Einstellungen auf die disk (ändert aber nichts,da zuvor keine vorgenommen wurden!)

das stimmt so eben nicht. gdisk schreibt bei w immer die GPT-Partitionstabelle neu; und sofern vorher eine MSDOS-Partitionstabelle vorhanden war, überschreibt er diese eben mit GPT.

Schaffe dir einfach mal ein Image mit MSDOS Partitionstabelle und probiere es ruhig selber aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# Pfad zum neuen Festplatten-Image
IMG=$HOME/test.img

# Größe des neuen Festplatten-Image in GiB
SIZE=5

# Image erstellen
dd if=/dev/zero bs=1M count=$(($SIZE * 1024)) status=progress >> $IMG

# MSDOS-Partitionstabelle erstellen
# Partition 1 mit 2GiB Größe erstellen
# Partition 2 mit Restgröße-33Blöcke erstellen
# >> Rechnung für P2: ($SIZE -2GiB von 1.Partition) * 2^30(= 1GiB in Bytes)  / 512B Blockgröße - 2048 Blöcke (Anfang) - 33 Blöcke (Ende)
sfdisk $IMG << EoF
,+2G
,$(( ($SIZE-2) * 2**30 / 512 - 2048 - 33 ))
EoF

# Image als Loop-Device einrichten
LOOP=$(sudo losetup -Pf --show $IMG)
echo -e "Image eingerichtet als \e[1;33m'$LOOP'\e[0;0m "

# Partitionen formatieren
sudo mkfs.fat -F32 ${LOOP}p1       # P1 in fat32
sudo mkfs.ext4     ${LOOP}p2       # P2 in ext4

# Partitionen Bezeichnen
sudo fatlabel ${LOOP}p1 "TEST_P1"
sudo e2label ${LOOP}p2 "TEST_P2"

# Einbindepunkte erstellen
sudo mkdir -p /media/test_p{1,2}

# Partitionen einbinden
sudo mount ${LOOP}p1 /media/test_p1
sudo mount ${LOOP}p2 /media/test_p2

danach kannst du auf den Testpartitionen ein paar Dateien anlegen, diese anschließend aushängen und mit

1
2
3

gdisk $LOOP
w
y

in GPT konvertieren. Wie du nun feststellen wirst, hast du nun eine GPT-Partitionstabelle.

Noch eins, das hier
san04 schrieb:

Das System lief jetzt im EFI-Modus, aber das UEFI-BIOS kriegt es nicht gestartet. Ich lande bei dem gleichen Screen: No bootable devices found.

hast Du gelesen?

Ja habe ich. Wie ich sagte, ich habe schon einige Rechner (meistens sogar Dualboot mit Windows) von Legacy auf EFI umgestellt. Ohne Festplattenkonvertierung auf GPT hat dies fast nie funktioniert.

Gruß Thomas

Hej TK87,

TK87 schrieb:

... das stimmt so eben nicht. gdisk schreibt bei w immer die GPT-Partitionstabelle neu; und sofern vorher eine MSDOS-Partitionstabelle vorhanden war, überschreibt er diese eben mit GPT.

ok (*^^*), nehme alles zurück, mea culpa!

(das hätten die "Jungs" ja auch mal so in die man schreiben können; habe zwar schon häufige gdisk angewendet und auch "w", aber zuvor halt immer Änderungen vorgenommen, bzw es ging um 's Anlegen eines "hybrid MBR", da hat man ja bereits GPT)

...(meistens sogar Dualboot mit Windows) von Legacy auf EFI umgestellt. Ohne Festplattenkonvertierung auf GPT...

in Verbindung mit Windows ist das klar, da geht das auch nicht ohne GPT im EFI Modus

Gruß black tencate

TK87 schrieb:

nicht alle Rechner unterstützen EFI-Boot mit MSDOS-Partitionstabelle.

Das war wohl der kleine aber entscheidende Hinweis!

Die muss zuerst mal in GPT konvertiert werden:

1 2 3

sudo gdisk /dev/sda w y

Das konvertiert die Partitionstabelle in GPT, natürlich ohne die Daten zu löschen (die Meldung ist etwas irreführend, weil mit "Partitionen werden überschrieben" lediglich die Werte in der Partitionstabelle gemeint sind und nicht die Partitionen an sich).

Mir war nicht klar, dass die Konvertierung so simpel ist. Dem bin ich gefolgt und habe danach die Bootreihenfolge zunächst auf 0009 angepasst. Ein sudo grub-install hat dann aber auch den 0000-er Eintrag korrekt überschrieben:

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0009,000A,000B,000C,000D,000E
Boot0000* ubuntu	HD(1,GPT,343a88d1-ee5a-4f69-8b1c-5802ecca0e16,0x800,0x19000)/File(\EFI\ubuntu\grubx64.efi)
Boot0002* UbuntuEnc	HD(1,MBR,0x930af656,0x800,0x19000)/File(\EFI\UbuntuEnc\grubx64.efi)
Boot0003* Diskette Drive	BBS(Floppy,Diskette Drive,0x0)AMBO
Boot0004* Samsung SSD 850 EVO 500GB	BBS(HD,P0: Samsung SSD 850 EVO 500GB,0x0)AMBO
Boot0005* USB Storage Device	BBS(USB,VendorCoProductCode,0x0)AMBO
Boot0006* CD/DVD/CD-RW Drive	BBS(CDROM,P2: HL-DT-ST DVD+/-RW GHB0N   ,0x0)AMBO
Boot0007  Onboard NIC	BBS(Network,IBA GE Slot 00C8 v1550,0x0)AMBO
Boot0008* ADATA SSD SP900 256GB-DL2	BBS(HD,P1: ADATA SSD SP900 256GB-DL2,0x0)AMBO
Boot0009* UEFI: Hard Drive 	PciRoot(0x0)/Pci(0x1f,0x2)/EDD10(0x2a010480)/HD(1,GPT,343a88d1-ee5a-4f69-8b1c-5802ecca0e16,0x800,0x19000)AMBO
Boot000A* Diskette Drive	BBS(Floppy,Diskette Drive,0x0)AMBO
Boot000B* Samsung SSD 850 EVO 500GB	BBS(HD,P0: Samsung SSD 850 EVO 500GB,0x0)AMBO
Boot000C* USB Storage Device	BBS(USB,Generic-Compact Flash 1.00,0x0)AMBO
Boot000D* CD/DVD/CD-RW Drive	BBS(CDROM,P2: HL-DT-ST DVD+/-RW GHB0N   ,0x0)AMBO
Boot000E  Onboard NIC	BBS(Network,IBA GE Slot 00C8 v1550,0x0)AMBO
Boot000F  Onboard NIC	BBS(Network,IBA GE Slot 00C8 v1550,0x0)AMBO

So schauts nun aus, wen es interessiert:

$ sudo fdisk -l 
Festplatte /dev/sda: 465,78 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 850 
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: E6AA5DC1-10FE-4243-A99A-29A612648794

Gerät       Anfang      Ende  Sektoren  Größe Typ
/dev/sda1     2048    104447    102400    50M EFI-System
/dev/sda3   206848    999423    792576   387M Linux-Dateisystem
/dev/sda5  1001472 976771071 975769600 465,3G Linux-Dateisystem

$ sudo parted -l
Modell: ATA Samsung SSD 850 (scsi)
Festplatte  /dev/sda:  500GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name                  Flags
 1      1049kB  53,5MB  52,4MB  fat32        EFI system partition  boot, esp
 3      106MB   512MB   406MB   ext2         Linux filesystem
 5      513MB   500GB   500GB                Linux filesystem

$ sudo ls -aR /boot/efi/
/boot/efi/:
.  ..  apt  EFI

/boot/efi/apt:
.  ..

/boot/efi/EFI:
.  ..  BOOT  ubuntu  UbuntuEnc

/boot/efi/EFI/BOOT:
.  ..  BOOTX64.EFI

/boot/efi/EFI/ubuntu:
.  ..  grub.cfg  grubx64.efi

/boot/efi/EFI/UbuntuEnc: # Könnte ich bei Zeiten nochmal rauswerfen...
.  ..  grub.cfg  grubx64.efi

$ sudo cat /boot/efi/EFI/ubuntu/grub.cfg
search.fs_uuid c6a09940-8791-4e76-9256-14918ab02d49 root hd0,gpt3 
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

$ lsblk -lf
NAME       FSTYPE    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                              
sda1       vfat            9546-986F                                44,3M    10% /boot/efi
sda3       ext2            c6a09940-8791-4e76-9256-14918ab02d49    137,9M    58% /boot
sda5       crypto_LU       2da9c4d7-7431-4e06-9f78-a1b74123ed7b                  
sr0                                                                              
sda5_crypt LVM2_memb       LAlh2P-KMJl-SF1O-Jah5-9U3f-0NWY-52UxZM                
ubuntu--vg-root
           ext4            02eafaf7-8667-451a-8175-2a274690cdad     60,6G    81% /
ubuntu--vg-swap_1
           swap            a71fc2be-35ca-495d-ab7c-95474eb41e33 

Vielen Dank nochmal an alle für die tolle Unterstützung. Ich kann hier guten Gewissens auf gelöst setzen ☺ Inzwischen läuft zwar mein 21.10 ganz solide, aber ich hab trotzdem wieder einiges gelernt.

Apropros: Kann mir abschließend noch jemand diese Zeile erklären?

Boot0000* ubuntu	HD(1,GPT,343a88d1-ee5a-4f69-8b1c-5802ecca0e16,0x800,0x19000)/File(\EFI\ubuntu\grubx64.efi)

Falls es auch in diesem Fall ein Festplattenbezeichner ist kann ich ihn nirgends so finden und auch eine UUID scheint es nicht zu sein?

Freut mich, dass alles geklappt hat.

san04 schrieb:

Apropros: Kann mir abschließend noch jemand diese Zeile erklären?

Boot0000* ubuntu	HD(1,GPT,343a88d1-ee5a-4f69-8b1c-5802ecca0e16,0x800,0x19000)/File(\EFI\ubuntu\grubx64.efi)

Falls es auch in diesem Fall ein Festplattenbezeichner ist kann ich ihn nirgends so finden und auch eine UUID scheint es nicht zu sein?

Das sollte die PARTUUID der Efi-partition sein, siehe entweder

1

lsblk /dev/sda1 -lbo NAME,LABEL,UUID,PARTUUID

oder alternativ

1

sudo blkid /dev/sda1

Ich kann hier guten Gewissens auf gelöst setzen ☺

Bitte nicht vergessen.

Gruß Thomas

TK87 schrieb:

... Das sollte die PARTUUID der Efi-partition sein, siehe entweder

nöö, das ist die UUID des NVRAM Eintrags, eine vfat UUID sieht so aus (z.B.) "98BA-9F0C", die zugehörige PARTUUID (z.B. so) "62fd3609-01"

Gruß black tencate