/mnt/boot/efi existiert nicht

talosako · September 25, 2022, 6:33am

Hallo Leute,

ich bin ein totaler Noob und versuche wieder in EOS reinzukommen. Leider kann ich seit dem letzten Update vor einem Monat nicht mehr in mein System rein.

Ich versuche alles durchzugehen, was in der Meldung im Forum steht (Grub 2:2.06.r322.gd9b4638c5-1) und hier (Arch-chroot for EFI/UEFI systems) steht. sudo fdisk -l ergibt folgendes:

/dev/nvme0n1p1  1050624  17065983  16015360   7.6G Linux swap
/dev/nvme0n1p2 17065984 976773134 959707151 457.6G Linux filesystem
/dev/nvme0n1p3     2048   1050623   1048576   512M BIOS boot

Bei nvme0n1p3 steht einfach nur “BIOS boot”, nicht EFI oder so. Jetzt stecke ich bei dem Abschnitt im Artikel mit sudo mount /dev/sdXn /mnt/boot/efi fest, weil der Terminal mir sagt, dass /mnt/boot/efi nicht existiert. Jetzt bin ich irgendwie aufgeschmissen, weil ich leider keine Ahnung habe wie es weiter geht… Also ich nutze BTRFS und der Abschnitt mit BTFRS im Artikel hilft mir da auch nicht weiter, weil wie gesagt kein /boot/efi bei mir existiert.

Secure boot and fast boot sind in den BIOS Einstellungen deaktiviert.

joekamprad · September 25, 2022, 9:37am

for die UEFI boot partition müsste da eigentlich statt “Bios boot” “EFI System” stehen.
Das sieht eher danach aus das du nicht im UEFI Ḿodus gestartet hast oder die Installation eben wirklich nicht im UEFI Modus gemacht wurde.

Das kannst du testen indem du efibootmgr im terminal eingibst.

Die volle Ausgabe von fdisk -l und lsblk -f würde auch mehr sagen… z.B. ob die Platte gpt oder Dos formatiert wurde.

Um zu checken wie es mit BTRFS und den Subvolumen aussieht:

sudo mount /dev/nvme0n1p2 /mnt
sudo btrfs subvolume list -p /mnt

und die Ausgabe davon posten.

dann wieder aushängen:
sudo umount /mnt

Wenn du subvolumen hast wie der Insztaller es automatisch erstellt:
Um das RFS einzubinden:
sudo mount -o subvol=@ /dev/nvme0n1p2 /mnt
Und dann kannst tu checken was in der fstab steht:
cat /mnt/etc/fstab
(poste das hier ebenfalls)
Damit wäre dann 100% sicher ob du UEFI oder MBR installiert hast.

Wenn in der fstab der Mountpoint /boot/efi zu finden ist müsstest du den jetzt auch mounten können:
sudo mount /dev/nvme0n1p3 /mnt/boot/efi

und dann solte auch das chrooten funktionieren:

sudo arch-chroot /mnt
grub-install

ringo · September 25, 2022, 11:31am

sie habben csm oder legacy enabled in die bios ?

talosako · September 25, 2022, 11:55am

EDIT: Lösung von joekamprad zusammengefasst (danke an ihn, übrigens!), wenn sudo mount /dec/sdXn /mnt/boot/efi nicht funktioniert, obwohl trotzdem EFI vorhanden ist und (wie bei mir) BTFRS benutzt wird:

sudo mount -o subvol=@ /dev/sdXn /mnt
cat /mnt/etc/fstab //Vergewissern, dass Boot EFI angezeigt wird!
sudo mount /dev/sdXn /mnt/boot/efi

sudo arch-chroot /mnt
grub-install

Notiz: sdXn = deine eigene Partition z.B. “/dev/sda1”.

Okay, ich gehe das mal detailiert hier durch Und das wird lang…

sudo fdisk -l ergibt:

Summary

Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 980 500GB                   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 16384 bytes / 131072 bytes
Disklabel type: gpt
Disk identifier: 681F0FFC-CD0C-2248-969F-699D6B07B6EC

Device            Start       End   Sectors   Size Type
/dev/nvme0n1p1  1050624  17065983  16015360   7.6G Linux swap
/dev/nvme0n1p2 17065984 976773134 959707151 457.6G Linux filesystem
/dev/nvme0n1p3     2048   1050623   1048576   512M BIOS boot

Partition table entries are not in disk order.


Disk /dev/sda: 28.65 GiB, 30765219840 bytes, 60088320 sectors
Disk model:  SanDisk 3.2Gen1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1e784590

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *         64 3583359 3583296  1.7G  0 Empty
/dev/sda2       3583360 3796351  212992  104M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 1.61 GiB, 1724010496 bytes, 3367208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

lsblk -f:

Summary

NAME    FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0   squash 4.0                                                       0   100% /run/archiso/airootfs
sda     iso966 Jolie EOS_202209
                              2022-09-10-10-51-40-00                              
├─sda1  iso966 Jolie EOS_202209
│                             2022-09-10-10-51-40-00                     0   100% /run/archiso/bootmnt
└─sda2  vfat   FAT16 ARCHISO_EFI
                              C8C0-D262                                           
nvme0n1                                                                           
├─nvme0n1p1
│       swap   1              4537b564-1b41-480d-bb48-3f5a579efc6d                
├─nvme0n1p2
│       btrfs                 8d06096e-46ce-4371-8371-bc31df2d4c3f                
└─nvme0n1p3
        vfat   FAT32 NO_LABEL 183B-758A

EFI Boot Manager/ efibootmgr ergibt folgendes:

Summary

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0001,0002,0003
Boot0001* UEFI OS	HD(3,GPT,8a5bd1de-cd8a-e248-a810-e1b0373ee7dc,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* UEFI:  USB	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(6,0)/CDROM(1,0x36ad80,0x34298)0000424f
Boot0003* UEFI:  USB, Partition 2	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(6,0)/HD(2,MBR,0x1e784590,0x36ad80,0x34000)0000424f
[liveuser@eos-2022.09.10 ~]$

Also scheint doch EFI doch da zu sein.

sudo btrfs subvolume list -p /mnt ergibt folgendes:

Summary

ID 256 gen 23773 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-07-10_20-01-53/@
ID 257 gen 36152 parent 5 top level 5 path @home
ID 258 gen 36152 parent 5 top level 5 path @cache
ID 259 gen 36153 parent 5 top level 5 path @log
ID 260 gen 26 parent 256 top level 256 path timeshift-btrfs/snapshots/2022-07-10_20-01-53/@/var/lib/portables
ID 261 gen 27 parent 256 top level 256 path timeshift-btrfs/snapshots/2022-07-10_20-01-53/@/var/lib/machines
ID 263 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-05-27_02-12-37/@
ID 264 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-05-27_11-47-11/@
ID 265 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-05-27_12-17-29/@
ID 266 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-05-27_17-59-50/@
ID 268 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-07-10_20-12-20/@
ID 276 gen 36154 parent 5 top level 5 path @
ID 277 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-07-13_23-20-35/@
ID 278 gen 26138 parent 5 top level 5 path timeshift-btrfs/snapshots/2022-07-16_16-48-18/@

sudo cat /mnt/etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=183B-758A                            /boot/efi      vfat    defaults,noatime 0 2
UUID=4537b564-1b41-480d-bb48-3f5a579efc6d swap           swap    defaults   0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /home          btrfs   subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd 0 0
[liveuser@eos-2022.09.10 ~]$

Sieht so aus, dass unter doch EFI ist, also habe ich, während subvol=@ /dev/nvme0n1p2 /mnt mountet ist, sudo mount /dev/nvme0n1p3 /mnt/boot/efi ausgeführt, dann in arch-chroot rein, >:

sudo pacman -Syu
sudo grub-install
exit
sudo umount /mnt/boot/efi
sudo umount /mnt
sudo reboot now

Jetzt kommt das komische: unter F11 in meinem Boot-Menü stehen zwei Boot-Optionen für Linux. Die oberste mit “UEFI OS: Samsung NVME [etc]” wirft beim Starten die Fehlermeldung in Grub:

Welcome to GRUB!
error: symbol `grub_debug_malloc' not found.
grub rescue>

Mit der anderen Boot-Option im Boot-Menü “endevouros” unter dem anderen kann ich EOS starten und konnte rein. Ich muss in meinen BIOS-Einstellungen nochmal die Reihenfolge ändern. Normalerweise funktionieren beide Boot-Optionen, aber jetzt geht nur die zweite. Ist schon okay.

Ich habe nochmal efibootmgr ausgeführt bei mir in EOS:

Summary

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0001,0000,0004,0002,0003
Boot0000* endeavouros	HD(3,GPT,8a5bd1de-cd8a-e248-a810-e1b0373ee7dc,0x800,0x100000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Boot0001* UEFI OS	HD(3,GPT,8a5bd1de-cd8a-e248-a810-e1b0373ee7dc,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* UEFI:  USB	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(6,0)/CDROM(1,0x36ad80,0x34298)0000424f
Boot0003* UEFI:  USB, Partition 2	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(6,0)/HD(2,MBR,0x1e784590,0x36ad80,0x34000)0000424f
Boot0004* Windows Boot Manager	HD(1,GPT,f65b3e69-ba07-4140-9fb6-87a8c7ff14a8,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)0000424f

Sieht so als würde in UEFI OS woanders versucht zu booten?!? Bin mir nicht sicher.

talosako · September 25, 2022, 12:00pm

Optane Memory, RST, Secure Boot, Fast Boot, CSM / Legacy / MBR und RAID sind alle deaktiviert.

joekamprad · September 25, 2022, 12:58pm

UEFI OS

ist ja ein automatisch generierter Eintrag von der firmware selbst, sogenannter Geräte Eintrag… warum der nicht bootbar ist … ich bin etwas überfragt… warum der erstellte (grub) Eintrag

Boot0000* endeavouros	*** \EFI\ENDEAVOUROS\GRUBX64.EFI

zeigt und der Geräte Eintrag:

Boot0001* UEFI OS *** \EFI\BOOT\BOOTX64.EFI

~~müsste eher:~~
~~/EFI/BOOT/grubx64.efi~~
~~lauten…~~

nichts desto trotz…
du kannst die Bootreinfolge mit ‘efibootmgr’ ändern:
sudo efibootmgr -o 0000,0001,0004,0002,0003
so wird der endeavouros Eintrag gebootet…

talosako · September 25, 2022, 4:47pm

Ich habe schon in meinen BIOS Einstellungen die Boot-Prioritäten geändert, so dass endeavouros zuerst gestartet wird. Wüsstest du vielleicht warum /EFI/BOOT/grubx64.efi nicht bei UEFI OS steht? Und wie man das vielleicht beheben könnte?

joekamprad · September 25, 2022, 6:51pm

Ist bei mir auch nicht anders.
Den Booteintrag kannst du ja nicht ändern da er automatisch angelegt wird.

Ist aber auf meiner Recherche Liste .

daniel · September 25, 2022, 9:56pm

Nach meinem Wissensstand ist BOOTX64.EFI durch die UEFI Spezifikationen festgelegt.

joekamprad · September 25, 2022, 9:59pm

genau das aber warum legt grub dann /EFI/BOOT/grubx64.efi an … auf meiner systemd-boot installation ist es der Fall:
2022-09-25_23-58

Und es sollte in jedem Falle bootx64.efi sein das ist ja ein fallback boot Eintrag…

und bei weiterem Nachschauen habe ich das auch bei anderen Installationen mit GRUB

Was ich nicht weiss ist wie die Datei angelegt wird… beim normalen grub-install nicht und auch nicht mit grub-mkconig

daniel · September 25, 2022, 10:13pm

grub-install mit der --removable option soll anscheinend bootx64.efi anstelle eines nvram Eintrags erzeugen. Habe das aber selber noch nicht getestet.

joekamprad · September 25, 2022, 10:21pm

EFI/BOOT/bootarch.efi—This name is the official EFI fallback filename. It’s most commonly used on bootable removable disks, but it can be used on hard disks. It’s typically used only if no NVRAM entry points to a valid boot loader. Note that arch is an architecture code, such as x64 for x86-64/AMD64 or ia32 for x86/IA32. Thus, the most common fallback filename is bootx64.efi

EFI/BOOT/bootarch.efi - Dieser Name ist der offizielle Fallback-Dateiname von EFI. Er wird am häufigsten auf bootfähigen Wechseldatenträgern verwendet, kann aber auch auf Festplatten verwendet werden. Sie wird normalerweise nur verwendet, wenn kein NVRAM-Eintrag auf einen gültigen Bootloader verweist. Beachten Sie, dass arch ein Architekturcode ist, wie x64 für x86-64/AMD64 oder ia32 für x86/IA32. Der häufigste Fallback-Dateiname ist daher bootx64.efi

soo ist das wohl:
wenn kein NVRAM-Eintrag auf einen gültigen Bootloader verweist.
Das ist im installer als option eingerichtet…

grub-install: Info: copying /boot/grub/x86_64-efi/core.efi’ → /boot/efi/EFI/BOOT/BOOTX64.EFI'.
Das sehe ich wenn ich grub-install verbose ausführe -v

Sehr gut jetzt bin ich wieder voll im Bild
Danke @daniel !!

joekamprad · September 25, 2022, 10:30pm

Also kannst du versuchen den Eintrag neu zu schreiben indem du sudo grub-install --removable ausführst…
Es kann sein das

BOOTX64.EFI

genauso wie die anderen grub dateien nicht funktioniert wegen das grub updates…

talosako · September 26, 2022, 2:47pm

Hab das mal eben ausgeführt. efibootmgr:

Summary

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0002,0001
Boot0000* endeavouros	HD(3,GPT,8a5bd1de-cd8a-e248-a810-e1b0373ee7dc,0x800,0x100000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Boot0001* UEFI OS	HD(3,GPT,8a5bd1de-cd8a-e248-a810-e1b0373ee7dc,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* Windows Boot Manager	HD(1,GPT,f65b3e69-ba07-4140-9fb6-87a8c7ff14a8,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000100000010000000040000007fff0400

Hab noch mal mit fdisk -l nachgeschaut:

Summary

Festplatte /dev/nvme0n1: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 980 500GB                   
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 16384 Bytes / 131072 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 681F0FFC-CD0C-2248-969F-699D6B07B6EC

Gerät            Anfang      Ende  Sektoren  Größe Typ
/dev/nvme0n1p1  1050624  17065983  16015360   7,6G Linux Swap
/dev/nvme0n1p2 17065984 976773134 959707151 457,6G Linux-Dateisystem
/dev/nvme0n1p3     2048   1050623   1048576   512M BIOS boot

Ich sehe hier keinen Unterschied mit den vorherigen Outputs mit fdisk -l und efibootmgr. Die Boot-Partition UEFI OS geht wieder. Ich verstehe nicht ganz, was hier abgeht.

joekamprad · September 26, 2022, 3:01pm

Ja sollte alles genauso aussehen wie zuvor… nur das das image neu erstellt wurde… aber eben mit dem selben namen…

Der Installer (Calamares) kopiert das image unter /boot/efi/EFI/BOOT/BOOTX64.EFI ist alsoi eine kopie von /boot/grub/x86_64-efi/core.efi mit anderem Namen und Ort damit die Firmware es benutzen kann…

system · September 28, 2022, 3:01pm

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.