[Megoldottam] Üres EFI könyvtár

Ubuntu Linux

Kérlek segítsetek jobban megértenem az efi boot működését. EFI boot GPT partíciós win10 mellé tettem KDE Neon-t (Ubuntu LTS). A biosban is látható a Neon bejegyzése, de csupán a Grub rescue konzol jelenik meg. Most bebootoltam a live telepítőröl. Gondolom, ha chroot-tal bejelentkezek és futtatok egy update-grub parancsot megoldódik a helyzet. De én még nem megoldani szeretném, hanem jobban megismerni a rendszerem működését. Ebben kérem a segítségeteket.

1. A /boot/efi könyvtár üres. Nem kellene itt lennie az efi fájlnak?

2. Hogyan is néz ki jelenleg a helyzet?

sudo parted -l
Model: Kingston DataTraveler 2.0 (scsi)
Disk /dev/sda: 7747MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  7747MB  7746MB  primary  fat32        boot, lba


Model: CL1-3D256-Q11 NVMe SSSTC 256GB (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  305MB  304MB   fat32        EFI system partition          boot, esp
 2      305MB   439MB  134MB                Microsoft reserved partition  msftres
 3      439MB   168GB  167GB                Basic data partition          msftdata
 6      168GB   254GB  85.9GB  ext4
 4      254GB   255GB  1038MB  ntfs                                       hidden, diag
 5      255GB   256GB  1474MB  ntfs                                       hidden, diag

Csatoljuk fel a telepített neon-t, hiszen live rendszeren vagyunk.

neon@neon:/mnt$ sudo mount /dev/nvme0n1p6 /mnt/

És most nézzük meg az fstab állományunkat.

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=d80fa530-aad8-4c6b-8049-3ac51d37a840 /              ext4    defaults,noatime 0 1
#UUID=ACA0-4E87  /boot/efi       vfat    defaults      0       1
#UUID=ACA0-4E87  /boot/efi       vfat    defaults      0       1
UUID=ACA0-4E87  /boot/efi       vfat    defaults      0       1

Igen, keresne valamit. De /boot/efi könyvtáram üres. Kell itt lenni valaminek? Másik béna kérdésem: honnan tudja a grub, hogy mit és honnan töltsön be?

Köszönöm a válaszokat!

  • 742 megtekintés

( zslaszlo v | 2022. 02. 27., v – 14:59 )

Szerkesztve: 2022. 02. 27., v – 15:18

Azt elfelejtettem írni, hogy miután chroot-oltam a /mnt könyvtárat listáztam a /boot/grub könyvtárat is. Ott ezt találtam:

root@neon:/boot/grub# ls
fonts  gfxblacklist.txt  grub.cfg  grubenv  themes  unicode.pf2  x86_64-efi

Tehát ott van az efi file. Miért nem jön be egyáltalán a grub?

Szerk.

De a már chroot-olt környezetben nem tudom telepíteni a grubot.

root@neon:/# grub-install /dev/nvme0n6
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

Ez miért van?

Az update grub kimenete:

root@neon:/# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99_breeze-grub.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/breeze/theme.txt
Found linux image: /boot/vmlinuz-5.13.0-28-generic
Found initrd image: /boot/initrd.img-5.13.0-28-generic
Adding boot menu entry for UEFI Firmware Settings
done

Nem értem.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

/boot/grub-ba nem jó tenni. UEFI bootnál a GRUB a fájlokat a /boot/EFI/grub-ba akarja tenni.

Az EFI működése elég egyszerű. Korábban az OS-ek, bootmanagerek az MBR-be, a 0. szektorba írták a rendszerindító kódot, de ez azért volt probléma, mert egymás alatt átirkálták azt. Az EFI bootnál ezek a kódok .EFI fájlok formájában vannak találalva (ezek lényegében windowsos exe formátumúak), tipikusan az EFI mappába, itt ezek a fájlok megférnek más-más néven, kulturáltan. Ez az EFI mappát Linux alatt a /boot/-ba szokás csatolni, így lesz belőle a /boot/EFI. Na már most a GRUB ide akarja magát betenni, de ez az --efi-directory=/blabla kapcsolóval felülbírálható.

Ennek ellenére ennyi az esetek többségében nem elég, mert hiába van ott az .EFI fájl a megfelelő mappában, nem biztosan, hogy bootolni fog, ahhoz az is kell, hogy az UEFI firmware-ben egy bootbejegyzés mutasson is erre az .EFI fájlra, ezt az efibootmgr nevű toollal tudod ellenőrizni. Elvileg lehet bármilyen mappában az .EFI fájl, csak akkor a bootbejegyzésnek erre kell mutasson. Mégis lehetőelg az EFI mappába szokták tenni, mert úgy néhány UEFI megtalálja bootbejegyzés nélkül is és el tudja indítani, ezért ez a szabvány megoldás.

Az EFI bootnak egyébként az is szépsége, hogy nem kell hozzá külön bootmanager, mert már önmagában is bootmanageri funkciókat lát el az UEFI firmware (amit egyesek UEFI BIOS-nak is neveznek). Ez azért jó, mert a GRUB-ot is nélkülözhetővé lehet tenni teljesen, lehet bootolni systemd boottal, ami sokkal egyszerűbb, de akár úgy is, hogy az UEFI közvetlenül a Linux kernelt bootoltatja (EFI stub boot), igaz ez utóbbi nem minden alaplapon/gépen működik, csak azokon, amiknek teljesen szabványos az UEFI implementációja, nincs benne semmi gyártói csúnyaság, Windowshoz drótozás, egyéb féreg húzás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

/boot/grub-ba nem jó tenni. UEFI bootnál a GRUB a fájlokat a /boot/EFI/grub-ba akarja tenni.

Nem én tettem oda, a telepítő alapértelmezése volt ez.

Ezek szerint elegendő, ha ha áthelyezem/átmásolom a mappát a /boot/EFI/grub könyvtárba? Milyen jogosultságokkal másoljam?

Az efibootmgr parancs kimenete:

neon@neon:~$ efibootmgr 
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0007,0005,0006,0003,0001,0000,0002,0004
Boot0000* ONBOARD NIC (IPV4)
Boot0001* UEFI RST CL1-3D256-Q11 NVMe SSSTC 256GB N2CC9DH0019G07PP 
Boot0002* ONBOARD NIC (IPV6)
Boot0003* UEFI HTTPs Boot
Boot0004* UEFI Kingston DataTraveler 2.0 60A44C413942FEB1398D245E
Boot0005* neon
Boot0006* Windows Boot Manager
Boot0007* ubuntu

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Az EFI partíció egy FAT32 partíció lényegében, rajta FAT32 fájlrendszerrel (elméletileg lehet FAT16, és FAT12 is, a szabvány megengedi, de nem szokták így alkalmazni). Azon nincsenek unix/ACL jogosultságok, minden mindenkinek írható, olvasható, futtatható. Az más kérdés, hogy a Linux kernel az EFI partíciót root joggal szokta felcsatolni, tehát simán su, sudo vagy hasonlóval csináld a másolást.

Igazából másolni se szükséges. Kézzel tudsz létrehozni az Arch Wiki alapján az efibootmgr parancs felparaméterezésével olyan új UEFI bootbejegyzést, ami a /boot/grub/grubx64.efi-re mutat a megfelelő UUID-jű disk megfelelő UUID-jű partíciójára. Ez viszont kockázatos, mert az efibootmgr egy nem felhasználóbarát tool (akár csak a dd, rm, chmod, chown, hdparm, stb.), ha véletlenül nem jó kapcsolót adsz meg benne, beszánthatod az összes bootbejegyzést, amivel rosszabb esetben az egész UEFI-t téglásíthatod (ha nem lehet benne az UEFI BIOS-ban a bootbejegyzéseket újra default-ra tenni). A kézzel átmásolásnak nincs kockázata.

Utánaolvasva már ebben sem vagyok biztos, mert az is lehetséges, hogy nálad már eleve a /boot/EFI/grubx64.efi-re mutat a bootbejegyzés (ezt a efibootmgr -v paranccsal tudod ellenőrizni), ami viszont a GRUB beállításait default /boot/grub mappában keresi. Ez megmagyarázná, hogy miért indul el nálad a GRUB, de csak vészkonzollal, mert a megfelelő .EFI fájl nélkül igazából nem tudnál eljutni eddig sem. Tehát könnyen meglehet, hogy ez nálad nem is UEFI boot probléma, hanem a GRUB telepítése hiányos, vagy a GRUB konfigurációja nem lett megcsinálva rendesen a GRUB telepítése előtt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Polesz v | 2022. 02. 27., v – 15:30 )

Akkor mountold a /boot/efi könyvtáradat is a megfelelő helyre.

sudo mount UUID=ACA0-4E87 /mnt/boot/efi

( Polesz v | 2022. 02. 27., v – 15:32 )

Egyébként a chroot környezetet az alábbiak szerint érdemes felépíteni:

mount /dev/sda1 /mnt
mount /proc -o bind /mnt/proc
mount /dev -o bind /mnt/dev
mount /sys -o bind /mnt/sys

És még ha van több könyvtár mint a külön EFI is akkor azt is. Utána mehet a chroot /mnt

( zslaszlo v | 2022. 02. 28., h – 15:27 )

Szerkesztve: 2022. 02. 28., h – 15:40

Boot Repair link: http://sprunge.us/nC4GKh

Upsz. Nem léptem ki a chroot környezetből, sorry.

Ez a chroot nélkül futtatott ajánlott boot repair link: http://sprunge.us/pJ476p

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( zslaszlo v | 2022. 03. 11., p – 08:08 )

Nem adtam fel a dolgot. Gyanús az egész. A grub rescue a boot parancs végén elszáll kernel pánikkal, mert "Cannot open root device" próbáltam UUID, partíciószám alapján, de sehogyan sem tudja megtalálni.

Jó akkor újratelepítem. Hiba:

Create a new partition (80,00 GiB, ext4) on ‘/dev/nvme0n1’


Job: Create new partition on device ‘/dev/nvme0n1’


Command: sfdisk --force --append /dev/nvme0n1


Command: sfdisk --list --output Device,UUID /dev/nvme0n1


Job: Set the label on partition ‘/dev/nvme0n1p6’ to "root"


Command: sfdisk --part-label /dev/nvme0n1 6 root


Job: Create file system ‘ext4’ on partition ‘/dev/nvme0n1p6’


Command: mkfs.ext4 -qF /dev/nvme0n1p6


Command: sfdisk --part-type /dev/nvme0n1 6 0FC63DAF-8483-4772-8E79-3D69D8477DE4


Job: Set the file system label on partition ‘/dev/nvme0n1p6’ to ""


Command: e2label /dev/nvme0n1p6 


Job: Check file system on partition ‘/dev/nvme0n1p6’


Command: e2fsck -f -y -v /dev/nvme0n1p6

És kilép a telepítő. Gyanús, hogy a windows, vagy a bios csinál valamit, valamilyen "védelmet" ami miatt nem lehet új oprendszert telepíteni.

Valaki tudna segíteni konkrét bios beállításokban?

Most már csakazértis telepíteni szeretnék másik oprendszert.

Köszönöm!

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Erre gondoltam én is először, de aztán arra jutottam, hogy nem hozom szóba, mert biztosan megnézte ezt már, plusz secure boot esetén azért az EFI partíció nem lenne elérhetetlen, inkább csak simán a bootolás nem menne róla. De ki tudja, ha még nem nézte, akkor egy próbát megér. Főleg, hogy ha a Windowsban a secure boothoz egész lemezen bitlocker titkosítás is hozzá van kötve.

Plusz segíthetne az is, ha pontosan tudnánk milyen gép. Egyes laptopgyártók az UEFI bootot fixen hozzádrótozzák a \EFI\Microsoft\Boot\bootmgfw.efi útvonalhoz, és ugyan ez körbehekkelhető, de szopatós lehet, ha valaki nem tudja, hogy ezzel van dolga. Nem hinném, hogy ez esetben erről van szó, mert akkor a GRUB vészkonzol szintjén se indulna el.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A secure boot természetesen ki volt kapcsolva. :) Nem ma kezdtem a linuxos pályafutásom. :))) A kernel pánik után kezdtem el gondolkodni, hogy valamilyen modult nem tölt be? Kutakodtam a BIOS-ban és megtaláltam! Be volt kapcsolva a RAID mód. Ha jól emlékszem a grub ezt nem támogatja.

Tehát kikapcsoltam a RAID-módot, sima ahci sata módra. Ezután persze a windows sem bootolt, tehát lett egy teljes rendszervisszaállításom. (Nem baj, nem volt rajta semmi)

Ezután gond nélkül települt a KDE Neon, van grub, indul mindkét oprendszer.

Öröm, boldogság.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Ez is furcsa, mert attól, hogy be van kapcsolva, még mennie kéne a bootnak, főleg Linuxnál. Még akkor is, ha nincs RAID tömb létrehozva, csak a vezérlő van RAID módban. Eleve nem értem, hogy ki tette abba, mert egyik BIOS-ban sem szokott default lenni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igazából fogalmam sincs. Így kaptam, ez volt a default. Igen, így volt, ahogy írtad. Nem volt raid tömb, csak a vezérlő volt raid módban. Nem is értem mire kell egy laptopba raid.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Ja, ez meg a másik. Minek kell akármibe is RAID, főleg ha nem szerver. Ma már szoftveresen kiváltják úgyis redundáns tárolási módszerek, LVM, btrfs, ZFS is tud hasonló funkciókat. Különösen egy laptopba holt értelmetlenség. Én egyébként azért szoktam azzal kezdeni, hogy ha mások által használt gép kerül a kezembe, amit használok majd, akkor BIOS-t default-ra visszateszem, aztán átnézek benne minden beállítást, OS-t újratelepítek, teljesen új partíciós táblát, partíciókat kezdve, mindent frissen, tiszta lappal, se RAID, se secure boot, se windowsos-bitlockeres barmolás, se semmi. Ezzel elég sok fejfájás elkerülhető élből, pont az ilyen hülye BIOS beállítások, nem megfelelő partícióhatárok, driverbaromkodás, telepített kémszoftverek és malware-ek, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Factory reset nem volt. BIOS update után is átállítja a barma. Most már ezt is megtanultam...

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( Dwokfur v | 2022. 03. 12., szo – 08:57 )

Bookmark

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."