UEFI secure boot helyreállítása

Linux-kezdő

Picike notebook, volt rajta Linpus linux, tettem rá Fedora 26-ot. Működött is, de zavart az UEFI partíción a Linpus nyoma, így gondoltam, törlöm onnan, aztán majd pendrive-ról bootolva helyreteszem a Fedorát. Jó elképzelés volt, most van egy indíthatatlan gépem. :(

Elkezdtem nézni a netet, csináltam grub és shim reinstallt, de nem segített. Pedig követtem a leírást, bind mount, chroot megvolt. Valószínűleg meg fogom találni a megoldást, de ha valaki hozott már helyre ilyet, s tudja a varázsigét, ne fogja vissza magát.

Az külön hab a tortán, hogy valamiért nem volt névfeloldásom wifin. Az nmcli-vel még csak-csak összeszögeltem, hogy menjen a wifi, de fogalmam sincs, mi lett a dns-sel. Szerintem a routeremen megy a dns szerver, mert egy másik gépen volt névfeloldás ugyanarról a routerről.

Az is jó, hogy most látom, a leírás régi lehetett, shim csomag utoljára Fedora 22-höz van. De jó. Vélhetően Fedora 26 esetén már rég más a megfejtés.

  • 3009 megtekintés

( locsemege v | 2017. 06. 13., k – 02:02 )

Kezdek aggódni. Az efibootmgr parancs használata sem hozott megoldást. :( Illetve a nextboot megadásával működik, de az egyszeri, csak a következő boot-ra vonatkozik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Raynes v | 2017. 06. 13., k – 02:17 )

Az egész problémát nem értem. Hogy jön ide a Secure Boot? Kapcsold ki.

Aztán Fedora alól bootctl --path=/boot install paranccsal másoltasd rá az .EFI fájlokat az /boot/EFI mappába.

Ha ez megvan, akkor kell megfelelően paraméterezve futtatni a efibootmgr-t. Mindjárt két módszer is adódik. Az egyik, hogy közvetlenül regisztrálod be az UEFI bejegyzések közé a Fedorát:
efibootmgr -d /dev/sda -p 1 -c -L "Fedora Linux" -l /vmlinuz-linux -u "root=/dev/sdb2 rw initrd=/initramfs-linux.img"

A másik, hogy az EFI partíción kézzel kreálsz menüt (/boot/loader/loader.conf és a mellé való /boot/loader/entries mappába a kernelparamétereket tartalamzó .conf fájl), és ezt a menüt adod hozzá az EFI bejegyzések közé:
efibootmgr -c -d /dev/sda -p 1 -l /EFI/systemd/systemd-bootx64.efi -L "Linux Boot Manager"

A példáknál feltételeztem, hogy a /boot-od a /dev/sda1-en van. Archon így megy, elvileg Fedorán sem kéne nagyon másnak lennie, ezért szerintem az Arch Wikin írtak használhatók. Mindkét disztró systemd-s és initramfs-t használ alapból.

GRUB-ot nem kell telepíteni, hacsak nem akarsz chain loaderözni. Ez UEFI egymagában is egy bootmanager, nem kell neki egy másik bootmanagert betölteni, se GRUB-ot, se shimet. A GRUB-nak talán még az az előnye, ha gáz van, akkor kézzel engedi bootkor szerkeszteni a kernelparamétereket, az UEFI erre nem ad lehetőséget, ott bootol a kernel úgy, ahogy az UEFI bejegyzésben, vagy a loader.confban be lett állítva.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

(Halk megjegyzés, mivel PC-n sose piszkáltam UEFI-t: de, az UEFI-nél is lehet paramétereket állítani. Legalábbis kb 8-10 éve a HP-UX-os Itaniumokon már lehetett. Meg lehetett mondai, hogy melyik diszkről, melyik partíció melyik fájlját kell betölteni, és milyen paraméterekkel kell indítani. Igaz, az nem PC volt, de elvben ugyanaz a szabványos (U)EFI.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Végül is nem lehetetlen, hogy van olyan lap, amelyik tudja, építettek bele ilyen szerkesztős menüt. Eddig csak laptopokon próbáltam UEFI linuxos bootot, és azoknak nem volt ilyen szerkesztési lehetőség. Plusz még az sem lehetetlen, hogy az általános linuxos loadert meg lehet úgy hívni, hogy engedje szerkeszteni a kernelparamétereket.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Megkövetem magam, tényleg lehetséges EFI bootkor szerkeszteni a kernelparamétereket. Nem az UEFI kínálja ezt a megoldást, hanem az EFI-ről induló BOOTX64.EFI bináris, amelyhez a loader.conf tartozik (systemd EFI boot). Szóval a kernelparaméterek szerkesztéséhez sem kell a GRUB, és ez magával hozza, hogy Fedora alatt shim sem kell hozzá.

A téma pikantériája, hogy pont tegnap szoptam megint EFI boottal. Vettem az x220-ba SSD-t, és arra újrahúztam az Arch Linuxot. Nem klónoztam a HDD-n lévő rendszert, btrfs helyett ext4-gyel telepítettem, meg swap partíció, LVM és LUKS nélkül. Meg is csináltam az első módszerrel, amelyet locsemegének írtam, azaz közvetlenül jegyeztem be az Arch Linuxot az UEFI EFI loaderjébe, efibootmgr-rel (EFISTUB boot). Ez működött is. Vannak viszont hátrányai: ilyenkor nem lehet a kernelparamétereket boot előtt szerkeszteni és így csak akkor indítható valami miatt x220-on, ha F12-vel előhozom a bootmenüt. Hiába volt helyesen beállítva az UEFI-ben (itt most a BIOS megfelelőjéről van szó, UEFI nem egyenlő EFI), hogy az archos EFI-bejegyzéssel induljon, nem azzal indul. Valamit lehet én cseszhettem el, mert indulnia kéne, hiába ürítettem ki a korábbi UEFI-s EFI-bejegyzéseket (hiszen hiába vettem ki a gépből a HDD-t, az EFI bejegyzéseket az UEFI tárolja, nem az EFI partíció). Elkezdtem erőltetni a dolgot, kézzel állítottam be a bootsorrendet efibootmgr -o paranccsal, látszólag jól meg is csinálta. Igen ám, de újraindításnál pofára estem. Sem a rendszer nem indult, eltűnt a bootmenü, és elő lehetett hozni F12-re, de üres volt, nem lehetett benne semmit indítani. UEFI menübe belépve a bootsorrendet sem lehetett állatani, mivel kiürült az efibootmgr-es akcióm miatt. Emiatt még pendrive-ról sem tudtam bebootolni az Arch telepítőjét, hogy azzal hozzam helyre a gikszert. Nem kell mondanom, hogy majdnem befostam, ott álltam egy bármiféle bootolásra alkalmatlan géppel. Próbáltam először az UEFI menüben mindent visszaállítani defaultra, de közölte a rendszer, hogy a bootsorrend nem fog visszaállni. Itt kezdtem még komolyabban kétségbe esni. Végül véletlenül vettem észre, hogy az UEFI bootsorrendes menüjében ott van a Reset to defaults és az visszaállította a bootolási opciókat. Így már F12-vel előhozva az UEFI boot menüt indult az Arch.

Ekkor a másik módszerhez nyúltam, az EFI partíción lévő loader.conf-os megoldáshoz (systemd EFI boot). Ilyenkor szerkeszteni is lehet a kernelparamétereket boot előtt, meg ez a megoldás automatán indítható. Fel is paramétereztem a loader.confból hivatkozott arch.confban, meg lett adva neki a root /dev/sda2-nek, meg az initrd helye /initramfs-linux.img-ként. Igen ám, de így nem volt jó, dobogatta bootkor az unable mount root file system-es kernel panicot. A megoldás végül az lett, hogy dev-es név helyett PARTUUID-t kellett használni, és az initrd-t kernelparaméterként is meg kellett adni. Szerintem azért, mert az arch.conf-os bejegyzésben PER initramfs-linux.img-t írtam (ezt rendeli az Arch Wiki, Gentoo Wiki, meg a többi linuxos oldal is), míg kernelparaméterként /-jel nékül volt. Összesen 5 órát szoptam vele, mire automatán bootolt az Arch.

Gondoltam leírom, jó apropó a topikhoz, és talán valaki hasznát veszi később. Futni fogok még vele egy plusz kört, hogy az első módszerrel is automatán induljon, mivel nincs szükségem a kernelparaméterek szerkesztésére.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Na hallod, most egy cseppet megijesztettél, tudniillik tervezem, hogy SSD-t rakok a gépbe HDD helyett, s nem szeretném, ha magába zárkózna. Annyi a különbség, hogy én továbbra is Grubbal szeretnék majd boot-olni, az oprendszer érdemi részét pedig rsync -avHASX paraméterezéssel file-osan másolni. Hogy a fenébe fogom boot-olhatóvá tenni, arról fogalmam sincs, s tartok is tőle, különösen a leírásod és a saját ezirányú élményeim miatt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mi van ha csinálsz ugye egy vadzsi új telepítést, majd live rencer alatt létrehozod a /boot/efi/EFI/BOOT/BOOTX64.EFI symlinket ami a fedora grubx64-re mutat, ill linux/bootx64 symlinket szintén ugyan arra mutatva. Ezeket a rendszer frissítés nem bántja, ott lesznek, és valszeg minden yovábbi nélkül indul a géped grub2-efi-vel
?

Ahogy jelezték fentebb, az EFI filerendszer fat, bár itt jegyzem meg, agyon kellene csapni azt, aki nem naplózó fs-t rak a gép indulásához elengedhetetlenül fontos file-ok alá. Nem tudom, ebben talán az MS vagy az Intel keze lehetett.

A félelmem inkább az, hogy ez a mocsok számon tart minden hardware-t, s egyáltalán nem biztos, hogy egy SSD-re sikerül összekalapálnom azt, amit szeretnék. Aztán, ha én is eljutok majd oda, hogy már a Fedora efi-s telepítő pendrive-járól sem tudok netán boot-olni, akkor cseppet elkeseredek. Fogalmam sincs, miért kellett elbonyolítani, ami régen ment egyszerűen. A GPT még rendben, hiszen gány a dinamikusan láncolt lista, az EBR, amely az MBR egyik bejegyzéséből indul. De az elég necces, hogy a felhasználó nem nagyon telepítheti a gépét, s egy rossz mozdulattal van esélye arra is, hogy bezárkózzon a cucc.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Felesleges aggódnod. Az SSD ilyen szempontból semmivel nem speciálisabb, mintha HDD lenne. Ugyanúgy kezeli a Linux, meg az EFI boot is, mintha HDD lenne.

Igazából semmire nem kell figyelned, ha SSD-t telepítesz Linux alatt. A modern particionálóprogramok betartják a 4K-s partícióeltolást (ráadásul a modern SSD-k közül sok rá sincs szorulva a speciális alignálásra). Arra figyelj, hogy olyan SSD-t vegyél, amelyen megy a TRIM/fstrim, és az discard mount (ez amolyan minden fájltörlésnél lefutó apró TRIM) is menjen (egyes SSD-knél firmware hiba miatt a kernel nem engedi que-ban futni, hanem azonnal kikényszeríti a TRIM parancsot, és ez teljesítményromláshoz vezet). Én a discard mount TRIM-et nem is használom, csak az fstrimet, azt is csak kézzel futtatom le néha napján, nem ütemeztem be cronba vagy systemd service formájában.

Nyugodtan kísérletezhetsz GRUB és Shim nélküli EFI boottal is, annyi, hogy a bootsorrendet mindig az UEFI-ből állítsd, ne az efibootmgr -o paranccsal. Plusz ha már EFI, érdemes GPT-s partíciós táblával dolgozni, elvileg a bootot is felgyorsíthatja egy picit.

Amit még célszerű az SSD-nél beállítani, ha támogatja, az az ATA password. Feltéve, hogy az alaplap és az UEFI támogatja. Ugyanis a legtöbb SSD alapból hardveres AES256-os (ritkábban AES128-as) titkosítással jön, ezt le sem tudod tiltani bennük, transzparensen működik. Viszont ha ATA jelszót rendelsz hozzá, akkor bootkor bekéri a titkosítási jelszót, és így lesz egy 0 hardverigényű, OS-eknek transzparens titkosításod, az egész lemez felülete titkosítva lesz, nem kell hozzá LUKS-szal meg LVM-mel szenvedni külön. Ha nincs beállítva ATA jelszó, akkor is titkosít, de nem kér be hozzá jelszót, hanem automatikusan engedi használni bárkinek a meghajtót, titkosítási kulcs megadása nélkül is. Persze először lehet értelmetlennek tűnik, hogy minek úgy titkosítani, ha a kulcsot a zárban hagyjuk. Pedig van értelme, nevezetesen, hogy ha eladod az SSD-t vagy garanciában visszaküldöd, és törölni akarod róla az adataidat, akkor nem kell dd wipe-ot csinálnod rajta, hanem újrageneráltatod a hardveres titkosítókulcsot, és a meghajtón lévő adatok többé nem lesznek feloldhatóak, pseudo random adattal lesz tele az SSD felülete. Alapvetően ezért vannak felszerelve az SSD-k hardveres titkosítással, de lehet kifejezett jelszóval is használni, már ha vállalod a kényelmetlenséget, hogy minden bootkor beírod a jelszót, vagy akár ujjlenyomatot is lehet jelszónak használni, ha a gép/UEFI támogatja, ennek általában laptopokon van értelme.

Az MS miatt van, hogy az EFI partíció fájlrendszere FAT. Ugyanis az EFI partícióról akármilyen OS-nek tudnia kell bootolni, és a Windows nem támogat mást az NTFS mellett, csak FAT típusokat (modern Windowsok támogatnak ReFS-t is, ha épp olyan Windows-kiadásról van szó). Ráadásul a FAT-ot az összes többi OS is támogatja, meg az UEFI-be is könnyű volt a támogatását beleszögelni, így erre esett a választás a szabvány megalkotásakor. Naplózni is felesleges, egyszer felírod az EFI partícióra a bootbeállításokat, és onnan nem irkálsz rá többet, ha áramszünet vagy fagyás van, akkor sem történik rá újabb írás, így adatvesztés sem lesz. Plusz könnyű róla másolatot csinálni, az EFI partíció mérete 100-512 mega között szokott lenni, kevés adat van rajta alapból, könnyen tömöríthető.

Felesleges tartanod az EFI only boottól, sokkal egyszerűbb és tisztább, mint GRUB-bal vagy GRUB/Shim kombóval szenvedni.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Az a gondom ezzel, hogy én rw mount-olom, mert elég gyakran van Fedorához kernel update, lényegében követi a vanillát. A grub.cfg pedig az efi filerendszeren van. Ha disk cache-ben marad valami egy szabálytalan leállás miatt, akkor ugorhat a konzisztencia, s mivel a metaadatok is cache-elődhetnek, nem kizárólag a frissen írt file-ok sérülhetnek. Nem azt mondom, hogy ez a világunk legégetőbb megoldandó problémája, de engem némileg zavar. Mondjuk engem az is, hogy a fedorás arcok alapértelmezetten nem írtak az fstab-ba egy fmask=0111-et, megtettem hát én. Rühellem, ha még egy sima szöveg file-on is futtatási jogokat látok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A FAT nem támogat symlinket, és szükség sincs rá. Bármilyen modern systemd-s disztró tartalmazza a bootctl parancsot, ami rámásolja az EFI partícióra az EFI boothoz szükséges fájlokat. Ha nem systemd-s disztróról van szó, akkor pedig kézzel is fel lehet másolni őket, mondjuk akkor nem tudom honnan szedi őket, de Wiki-s leírások alapján lehetséges.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Ha nem friss telepítést csinálsz, csak a partíciókat hozod létre, és rsync-kel másolod a fájlokat, akkor alapból jónak kell lennie az EFI bootnak SSD-n is. Annyi, hogy ha hivatkozik valahol partíciós UUID-kre vagy PARTUUID-re az EFI/systemd loader vagy a GRUB/Shim, esetleg az /etc/fstab vagy crypttab, akkor azt módosítanod kell az SSD-re vonatkozó adatokkal (hiszen ez egyedi lesz az SSD-n és a HDD-n is, nem eshet egybe), ezeket blkid-vel tudod megnézni. Ha csak /dev/sda-s sémát használ minden, akkor módosítanod sem kell semmit a konfigfájlokban.

Egyedül egy dolgot lehet, hogy át kell írnod, ha az UEFI nem ismeri fel a EFI systemd loadert (alapból fel kéne neki ismerni), akkor az efibootmgr -c paranccsal újra hozzá kell adnod az EFI bootopciók közé. Viszont csak egy sor beírása, és puskázhatsz az előző EFI bootopció alapján (amit az efibootmgr -v paranccsal tudsz megnézni). Ha működik, akkor az efibootmgr -B négyjegyűhexa -b paranccsal törlöd a régi EFI-bejegyzést, de akár hagyhatod is, elfér. Ugyanez az eljárás a közvetlen EFI/EFISTUB bejegyzésnél is, csak ott nem ismeri fel automatikusan, de szerintem te nem ezt használsz, hanem EFI systemd loadert.

Kár, hogy ez az rsynces megoldás nem jutott eszembe, mert ezzel nekem is sokkal egyszerűbb lett volna minden, spóroltam volna magamnak 5-6 órát. Ez az újrahúzom vagy azonos partícióknál/fájlrendszernél klónozom hozzáállás még évekkel ezelőttről hátramaradt, téves windowsos berögződés nálam, akkor megszoktam, hogy a Windowsnál nem elég fájlszinten másolni, mivel egyes rendszerfájloknál a szektorszintű elhelyezkedés is számít. A jövőben viszont rsyncezni fogok, úgyis veszek majd a másik laptopba is SSD-t.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Nem EFI-s gépen költöztettem már így rsync-kel HDD-ről SSD-re oprendszert minden probléma nélkül. Nyilván nem az az oprendszer futott, amit másoltam, hanem live.

Igen, UUID-es hivatkozásaim vannak, de nem lesz egyidejűleg a gépben a HDD és az SSD, így gondolom, ugyanazt az UUID-et adhatom az SSD filerendszerének is akár. Bár kérdés, ettől mennyire akad fenn majd az UEFI (BIOS) szeme. (Bocs, ha helytelenül használom az efi, uefi, secure boot szavakat, nem olvastam utána alaposabban egyelőre.)

Azt értem, hogy a gép szempontjából semmi különbség az SSD és a HDD között, csak az a félelmem, hogy az UEFI emlékszik majd az egyedi hardware azonosítókra, s azon fog hisztizni, hogy márpedig neki az kell. A másik, hogy írod az efibootmgr használatát, de sajnos ezen a gépen egyedül a next boot-ot sikerült vele beállítanom. A bejegyzés törlése, boot order, aktív flag, timeout mind olyan mágiák, amelyeket látszólag megcsinált, de reboot után minden maradt a régiben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm az infót. Grub az kell, mert bármikor hozzányúlhatok a kernel paramétereihez, ez fontos. Ott tartok, hogy van egy rakás - kb. 45 darab - Fedora bejegyzés az efibootmgr szerint, pedig ennyiszer nem próbálkoztam, csak kb. 2-3 alkalommal. Ez a kisebbik baj, törölhetem is, meg elfér. A boot order-nél 0x2001,0x2002,0x2003 van, ez a pendrive, külső ODD, illetve a hálózat. A gond az, hogy hiába teszem a boot order-nél be a 2-t, elfelejti. Viszont, ha nextboot paraméterként megadom a 2-t, akkr feljön a Grub, és tudom boot-olni a HDD-ről az oprendszert. Mondanom sem kell, annál gányabb megoldás a világon nincs, hogy például az rc.local-ba beleteszem az efibootmgr -n 2 parancsot. Így minden nextboot önmaga lenne, de ez borzalmas. Van még ötletem, este lesz csak időm rá.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bartaszili | 2017. 06. 13., k – 10:24 )

https://fedoraproject.org/wiki/Refind

Samsung laptop makacs buta UEFI-BIOS-al vs. Win10 + LinuxMint + UbuntuStudio.

rEFInd segített az idióta boot hibákat megszüntetni.

Gondolom ez valami Acer netbook, ha jólemlékszem csak úgy indulnak el, ha egy bizonyos mappa alatt egy bizonyos nevű indító van. Hiába rakod be a szabvány szerinti mappa alá az indítódat, szabványos névvel...

A találgatásokat segített megszüntetni a rEFInd nálam. Grub helyett. Guglizd meg a típusodat. Biztos írják valahol a /boot/efi/.../valami.xyz hogyan kell kinézzen.

Őszintén? Passz. Vagy 1000 ilyen nem bootol a szarom uefivel topikot olvashattam már. Nagyon sokszor le volt limitálva csak windows indítására a kicsike. Ha szerencsés volt a szaki, akkor manuálisan engedte a bios kiválasztani az indító fájlt. Ha nem, akkor az hosszabb történet volt. Nálam olyan eset van, amikor nem lehet manuálisan megadni a biosban, grub+win10 esetén ha elindítod a Windows-t, az bejegyzi magát, automatikusan csak ő indul majd utána. Ekkor jött live rencer, grub update... Jó volt míg megint nem indult a win10. Ja és a bios upgrade után nem lehetett többé usbről bootolni. Emiatt kellett Windowst indítani, mert lehetetlen volt egyszerűen elkapni a biost bekapcsolás után. Ez volt a Samsung válasza arra, amikor anno téglásak lettek egy linux miatt az uefis samsungok. Friss bios = nem lehet pendriveról indulni, azaz nem fogja Linux Pistike elcseszni... Erre jött a rEFInd, és többé nem egyeduralkodik a win10, nem is használom azóta, mert a rEFInd látja a rádugott pendriveot.
---
Mivel a kérdező legyalulta a lapost, rakott rá egy friss Fedora-t, majd nem megy = /boot/... /fedora alatt kellene lennie a boot filenak. Nem találja a bios. Máshol keresi. De hol?
---
Standard indító hely, ahol a szabvánt szerint keresnie kell: /boot/efi/EFI/BOOT/BOOTX64.EFI
Fedora indító: /boot/efi/EFI/fedora/grubx64.efi

Amúgy nálam is tud vicceskesdi, de en ezt a szar implementációnak tudom be (egyébként van olyan lap -legyen az notebook/asztali- ahol értelmes UEFI van?). Amikor változik a háttértár (pl. kiveszek/berakok 1 HDD-t) kiosztás nem tudja hova kapkodja a fejet, akkor kell szórakozni vele.

A kérdező mondja ám, hogy mi van, csak ideje nincs foglalkozni vele, talán ma este. :)

Ez a gép Windowst sose látott, nem is fog. Egy Linpus Linux volt rajta, tettem rá egy Fedorát, de úgy, hogy az sda1-et meghagytam - ez az EFI partíció -, a többit újra partícionáltam gdisk-kel. Már úgy értem, a többi partíciót töröltem, létrehoztam azt a layout-ot, amelyre vágytam. Erre tettem egy Fedora 26-ot. Ez ment is hibátlanul, gyönyörűen, tapipadnál kellett az UEFI BIOS setup-ban advancedre állítani a működést, utána ment az is. Aztán, jött az ostobaságom. Volt egy-két file, amelyikben nyoma volt a Linpus indításának. Ezeket - mentést követően - töröltem. Viszont visszamásolás után sem gyógyult meg, bár nem tudom, hogy valóban mindent visszamásoltam-e. Úgy tűnik, a boot order környékén van a kutya elásva. Pendrive-ról a nextboot megadásával el tudom indítani a Grubot, s be tudom boot-olni a Fedorát. De ez egyszeri.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, egy picike 11.6"-os Acer. Működött ez Grubbal, csak ostoba voltam, s gondoltam, az egykori Linpusra utaló nyomokat eltüntetem. Számítottam arra, hogy ennek lehetnek következményei, de titkon arra is, hogy pár pillanat alatt helyrehozom. Az MBR+EBR világos, azt értem, ezzel szemben az UEFI új még nekem, ennélfogva félek attól, nehogy örökre magába zárjam a gépet. Egyáltalán kell ettől tartanom? Mert ugye hagyományos BIOS esetében nem, hiszen ha be tudom boot-olni a gépet pendrive-ról, akkor már azt csinálok a HDD-vel, amit akarok. Ugyanakkor úgy tűnik, az UEFI óvatosabb jószág, s a secure boot-nak talán épp az a lényege, hogy aláírás nélkül semmit se tudjak tenni. Ez meg felveti bennem azt a szörnyű gyanút, hogy egy rossz mozdulat után soha, semmiről sem tudom majd boot-olni a gépet. Nagyon fájna, megkedveltem, ráadásul új gép.

Szerk.: S persze a Fedorát sem szeretném újra telepíteni, hiszen hibátlan, up to date oprendszer.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( mark7 | 2017. 06. 14., sze – 03:35 )

'az EFI partíción kézzel kreálsz menüt (/boot/loader/loader.conf'

Az EFI partíciónak köze van a BSD -hez?
Utóljára ott láttam loader.conf fájt

( locsemege v | 2017. 09. 08., p – 03:17 )

[Megoldva]

Mivel a nextboot-tal sikerült indítanom a Fedorát, éreztem, nem lehet messze a megoldás. Az efibootmgr paranccsal meg is tudtam volna oldani, de úgy viselkedett, mintha jó néhány beállítást nem tudna a parancs érvényre juttatni. Nem tudtam bejegyzést törölni, nem tudtam inaktívvá tenni, a timeout-ot nulláról nem tudtam megváltoztatni, valamint a boot sorrendet sem tudtam módosítani. Egyedül a next boot volt az, ami működött. Elkezdtem kutakodni a neten, s ezt találtam:

Apparently Acer customizes Insyde's firmware after they take delivery, and they've (maybe) got another variable they're keeping the boot order in, and regenerating it each time during boot.

This is completely nonstandard behavior, but if we can identify what they're doing, we may still be able to make efibootmgr support it.

Ugye, most épp egy Acer Aspire notebookról van szó. Erre ronda workaround-nak mindenhol azt láttam, hogy ha már valamit bedrótoztak, akkor legyen átverve a bedrótozás: tegyük oda a grubx64.efi-t és olyan névvel, ahogyan keresi. Mivel volt mentésem arról az állapotról, amelyikben nyomokban Linpust tartalmazott, megnéztem, milyen alkönyvtárak és file-ok voltak ott. Kiderült, hogy az EFI alatt a fedora és BOOT mellett volt még egy Linux nevű alkönyvtár is, s benne egy BOOTX64.EFI nevű file. Meg valami config, de az text, ránézésre a Linpus indítójának konfigurációját tartalmazta. Így aztán létrehoztam egy Linux nevű alkönyvtárat, s bra javaslata alapján ide bemásoltam a fedora alkönyvtárból a grubx64.efi file-t, de BOOTX64.EFI névvel. Aztán mondtam neki egy sync parancsot. Nem muszáj, csak saját megnyugtatásomra.

Ezt követően újraindítottam, s gyönyörűen indult a grub, amelyik boot-olta a Fedorát.

Megnéztem, a BIOS setup-ban megjelent egy Linux nevű eszköz a lehetséges tételek között, ez most ami kell, a Grub.

Pici szépséghiba, hogy ránézve efibootmgr paranccsal, továbbra is van a listában egy unknown device. Ezt amúgy azért nem értem, mert ugyanazt az UUID-et írja ki, ugyanazt a boot file-t, mint a helyes bejegyzések esetén. Töröltem volna, de ahogy fentebb írtam, nem tudom.

Amennyiben tényleg az Acer használ ilyen bedrótozást, lehet, hogy épp azért teszi, hogy ne lehessen téglásítani a gépet. De az is lehet, hogy a hozzánemértésem az oka, hogy így sikerült megoldani. Lényeg, hogy most jó, stabilan bootol a gép, s iziben csináltam róla egy backupot. Az archiválandók listájába felvettem a /boot/efi/EFI alkönyvtárat is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE