[MEGOLDVA] Klónozás, EFI boot

Linux-haladó

Kedves Tapasztalt Fórumtársak!

Adott egy asztali gépen egy telepített, beállított, előkészített (Slackware 15) gép. EFI boot. Elvárásszerűen működik.

1. partíció az EFI (100 MB), 2. a swap (8 GB), 3. a rendszer (kb.248 GB, maradék), summa 256 GB SSD.

Ezt szeretném klónozni harminc másik gépre. Amikor pár éve legutóbb csináltam ilyent, ment mint a karikacsapás (igaz, lilo-s időkben).

dd-vel kiírtam az első partíció utolsó szektoráig egy file-ba, majd pedig kiírtam a tesztgép SSD elejére. Ezután a tesztgépen a parted azt listázza, amit kell, az 1. partícióra a boot flag(?) beállítva, mountolható, és azt tartalmazza, amit kell. A 3. partíció nevét megváltoztattam, majd visszaírtam az eredetit ("Linux file system"), csak hogy lássam, hogy a parted csinál is valamit.

CMOS-ban beállítva az efi boot (pendrive-ról el is indul, ahogy kell), de ha újraindítom pendrive nélkül, azt mondja, hogy nem talál op.rendszert. Namost legalább a kernelt be kellene töltenie az 1. partícióról (max. pánikba esik, hogy nincs meg a root fs).

Mit rontottam el?

Üdv:
KEA

  • 1493 megtekintés

( mauzi v | 2023. 08. 30., sze – 21:05 )

Szerkesztve: 2023. 08. 30., sze – 21:08

Kihagytad az EFI boot menü bejegyzés létrehozását.
(man efibootmgr)

A boot flagnek nincs jelentősége EFI bootnál.

Removable media esetén kell a boot loadert az \EFI\BOOT\BOOTX64.EFI címre tenni.
(Az EFI specifikáció szerint pedig a "\" azaz a backslash a directory separator)

Fixed media esetén a vendor-specifikus mappa használata, és a boot menü bejegyzés felvétele az elvárás.
(Most gyorsan végignyomkodtam egy Debian telepítőt, és csak a \EFI\Debian alá pakol, egyáltalán nincs \EFI\BOOT)

Egyébként, a Debian speciel nem teszi a kernelt az ESP-be, csak a grubot. (A grub pedig ismeri az ext4-et, és be tudja onnan tölteni a kernelt.)

Nem. Sok EFI implementáció van olyan inteligens, hogy keres neked egy bootolható perifériát, és azon betölti fentit (vagy mást!), de ahogy Mauzi is írta, van egy halom olyan megvalósítás, ami nem ilyen, hanem explicit módon neked kell felvenned a boot menüben egy első bejegyzést amely a gépben levő diszk (valószínűleg) első partíciójára és az ott levő  ...\bootx64.efi-re hivatkozik.

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

Sok EFI implementáció van olyan inteligens, hogy keres neked egy bootolható perifériát, és azon betölti fentit (vagy mást!)

Ezt nálam nem intelligenciának hívják, hanem esetenként pl. kibaszásnak.

Voltak olyan (hápé) gépeink, ahol a Windows boot loaderét konkrétan el kellett mozgatnunk a \EFI\Microsoft alól, mert hiába volt a gépen dual-boot módon másik operációs rendszer is, és hiába volt rendesen felvéve a boot menübe, ő konkrétan mindenáron a Windows-t bootolta be, amíg az a "gyári" helyén volt.

Valószínű azt hagyta ki, de megjegyezném, hogy nem minden gépen kell ezt létrehozni. Bootmanagertől, .efi fájloktól, meg géptől is függ, de pl. nálam eddig minden modern gép UEFI BIOS-a induláskor detektálta az EFI partíción lévő systemd boot (ennek semmi köze nincs a systemd-hez, a nevén kívül) .efi fájlt és az ahhoz tartozó .conf bejegyézéseket, így nem kellett semmit hozzáadni kézzel, és emlékeim szerint a GRUB is tudja ezt. Egy kivétel volt, mikor Gentoo-val kísérleteztem, de az nem systemd-boot-tal indult, hanem EFI stub boot módszerrel mindjárt a kernelt indította az UEFI.

Slackware hagyományosan lilo-t használ, de az nem tud UEFI bootot, talán az utódát használja, elilo, vagy hasonló, lehet azért nem találja meg magától a bootbejegyzést az UEFI BIOS.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( renard | 2023. 08. 30., sze – 22:25 )

Mit rontottam el?

Ezt a mondatot biztosan: "dd-vel kiírtam az első partíció utolsó szektoráig egy file-ba, majd pedig kiírtam a tesztgép SSD elejére."

A dd sok felesleget is visz, vannak fejlettebb eszközök, pl. a CloneZilla erre tökéletesen jó, és nem kerül semmibe.

Clonezilla is a partition and disk imaging/cloning program similar to True Image® or Norton Ghost®. It helps you to do system deployment, bare metal backup and recovery. Three types of Clonezilla are available, Clonezilla live, Clonezilla lite server, and Clonezilla SE (server edition). Clonezilla live is suitable for single machine backup and restore. While Clonezilla lite server or SE is for massive deployment, it can clone many (40 plus!) computers simultaneously. Clonezilla saves and restores only used blocks in the hard disk. This increases the clone efficiency. With some high-end hardware in a 42-node cluster, a multicast restoring at rate 8 GB/min was reported.

Ez rendben van, csak ő ezt írta:

Adott egy asztali gépen egy telepített, beállított, előkészített (Slackware 15) gép. EFI boot. Elvárásszerűen működik.

1. partíció az EFI (100 MB), 2. a swap (8 GB), 3. a rendszer (kb.248 GB, maradék), summa 256 GB SSD.

Ezt szeretném klónozni harminc másik gépre.

Számomra ez azt jelenti, hogy a teljes SSD-t klónozná, mivel akkor lenne ugyanaz a másik 30 gépen is, mint az eredetin.

Utána írt egy "valamit", ami - finoman szólva - nem kerek:

dd-vel kiírtam az első partíció utolsó szektoráig egy file-ba, majd pedig kiírtam a tesztgép SSD elejére.

Elvi síkon igazatok van, sőt, klónozásra én is rsync-et használok, még locsemege egyik régi topikjából szoktam rá erre a megoldásra, ahol a kapcsolókat írta. Működik is, bevált már többször.

De itt kivételesen a másik oldalnak is igaza van, 100 vagy pár száz megás EFI partícióról van szó, ott aztán mindegy, hogy a dd átvisz a fájlrendszer által nem használt szektort, meg töredezést, mert olyan kicsi, kevés adat, hogy abba SSD nem fog belassulni, HDD-nek meg jót is tesz, hogy nem fájlonként másol, hanem abszolút szekvenciálisan, bár egy mai HDD is 100-200 MB/sec-kel másol, úgyhogy annak is megvan pár másodperc alatt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Éppen a szektoros másolással tartod meg a fragmentációt, file-os másolás esetén üres filerendszerre folytonosak lesznek a file-jaid. :) És azért az sem mindegy, hogy egy 120 GB-os root fs esetén 120 GB-ot másolsz, vagy csak mondjuk 40 GB-ot, ami a tényleges oprendszer adott esetben.

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

Ssd esetén nincs fragmentáció, ugyanúgy szétszórva tárolja fizikailag, ahogy a vezérlőnek tetszik.

Van, hogy sima dd nagyságrenddel gyorsabban végez, mintha okos programmal elemezgeti a fájlrendszert. Nekem 4-5x tovább tart például gparteddel, pláne, hogy nem csak linuxos fájlrendszer van.

Igen, az SSD véletlen hozzáférésű, bár ezt azért fenntartásokkal kell kezelni manapság, amikor már a RAM sem teljesen az. Gondolok itt arra, amikor burst-ös adatátvitelnél címet mondanak neki, onnantól meg szekvenciális adatátvitel történik a RAM-ban lévő cím pointer autoincrement-jével.

Mindamellett én használok HDD-t is, nem csak SSD-t, szóval az én esetemben számít a fejmozgások miatt a töredezettség.

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

Ssd esetén nincs fragmentáció

Elnök úr, ez így ebben a formában nem teljesen igaz.

Hogyne lenne fragmentáció, pl. a fájlrendszerben ha nem egymást követő "logikai" szektorokban van az adat, akkor az töredezettségnek számít. Windows alatt ntfs fájlrendszeren meghatározott maximum darabra töredezhet egy fájl, mielőtt elérhetetlenné válna. Ezért kell windows alatt ntfs fájlrendszert ssd meghajtó esetén is defragolni.

Az pedig, hogy az ssd belül szétszórva tárolja a fájlhoz tartozó darabokat, leginkább a wear leveling miatt lehet. Normál esetben szekvenciális összefüggő területre írja az adatokat. Csak mivel az ssd controller csipp 4 v. felső kategóriás esetben 8 vagy akár 16 csatornás felépítésű, szét tudja szórni 4-8-16 párhuzamos stream-re az adatmennyiséget. De 1 stream-en belül folyamatos összefüggő területre ír. Szerintem.

A töredezettség az ssd-t is belassítja, elég megnézni a benchmark-okban a serial olvasás vs. random olvasást. Ott is nagyságrendnyi lassulás van, ugyanúgy mint egy hdd-nél. Ha nem számítana ssd-nél a töredezettség, random olvasás is ugyanolyan gyors lenne mint a folytonos olvasás.

( tovis v | 2023. 08. 31., cs – 16:49 )

A Clone Zilla nem egyszerűbb?

* Én egy indián vagyok. Minden indián hazudik.

De, egyszerűbb, semmi baj nincs vele, működőképes alternatíva. Viszont laikusoknak szánt normi tool. Aki komolyan linuxozik, annak én is azt szoktam javasolni, hogy egy szint felett inkább tanulja meg a terminált, shellt használni, és megoldani ezeket magának kézi módszerrel. Nagyobb függetlenség, és utána nem lesz másra, meg bicikli-pótkerekekre szorulva, meg érteni fogja, hogy hogyan működik a rendszer, ami akkor is nagy segítség lesz, ha mondjuk eltörik a saját rendszere, nem bootol, és meg kell javítani. Nem egy nagy szám, alig 1-2 parancsot kell hozzá tudni (lsblk, blkid, (c)fdisk, rsync, tar, dd, efibootmgr, resize2fs, vgextend, fstab, crypttab, stb. palettáról választva ki, nem kell az összes), meg max. 1 konfigfájlt, vagy valamit átszerkeszteni (egy sor vagy PART-/UUID átírása erejéig), nem egy rakétatudomány elsajátítani. Érdemes vele gyűrödni, mert hosszú távon garantálhatóan meg fog térülni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( azbest | 2023. 08. 31., cs – 17:42 )

Szerkesztve: 2023. 08. 31., cs – 17:43

a dd után a különböző diszk méret miatt még gpt javítás is kell valsz egyébként (akár egy gparted is megteszi live linux alól). Legalábbis nekem sírt azért, mert nem a teljes lemez méretről tudott.

De ahhoz létre kell hozni pont ugyanúgy a particióbejegyzéseket kézzel, ha nem ugyanott kezdőduk, akkor átszámolni.

Nem is értem, hogy miért nincs olyan könnyen kezelhető linuxos program, amivel simán átmásolhatok grafikus felületen particiókat úgy, hogy ő megcsinálja a bejegyzéseket, de nem elemzi a tartalmát, hanem lehet raw módot is választani. Gparted trljesen jó lenne, ha raw módot engedne és nem akarna okosabb lenni. 

Három kisebb ssdről akartam átmásolni a rendszereket egy multiboot nagyra, de vagy 10-20 óra lenne az ntfs particiókat, mert elemezni akar. ddvel talán 3x fél óra lenne, vagy annyi se. De ehhez kézzel létre kell hoznom mindent és kiszámolgatni az új címeket.

Szerintem azért, mert ebben a műfajban szélsőségek vannak. Van, aki teljesen buta hozzá, neki helyette is gondolkodó tool kell. Aztán van, aki érti, amit csinál, neki nem túl megterhelő egész számok halmazán összeadni meg kivonni.

Az nem igaz, hogy ugyanúgy kell létrehozni a partíció bejegyzéseket. Egy fs-t bemásolhatsz nagyobb partícióba, aztán vagy veszni hagyod a helyet, vagy beletágítod a filerendszert, s akkor ki lesz használva a nagyobb hely.

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

A hangsúly azon van, hogy kézzel kell számolgatni és marhára szét lehet cseszni dolgokat, ha valahol elcsúszik egy szám.
Win alól talán fél óra sem volt az egész munka ssd-t átklónozni nagyobb ssd-re, csak a wd ssd-khez ingyenes Acronis True image költöztetése / klónozásra van kihegyezve, az tudja okosan és "bután" is, de a többi ssd-ről átvinni particiókat már azzal is macerás.

Lehet, hogy van egyszerű megoldás. De sajnos annyira tele van a net már mindenféle kókányolós és kattintásoptimalizált szeméttel, hogy képtelenség megtalálni a zajban. Ha jól emlékszem a clonezilla is okos akart lenni és ezért marha lassú. Kézzel tudom hogyan lehet, meg is tudnám csinálni, de bassza már meg a kurva isten, hogy nem létezik értelmes megoldás, csak túlbonyolított. Ne nekem kelljen már frontendet írnom egy egyszerű feladatra egyszeri használatra.

( kea | 2023. 09. 01., p – 09:52 )

Örömmel látom, hogy megmozdítottam a t. fórumtársak gondolatait...

Köszönöm a válaszokat! Azt vélelmezem, hogy a probléma megoldása itt lehet:

Kihagytad az EFI boot menü bejegyzés létrehozását.
(man efibootmgr)

Merthogy hiába van minden átmásolva, ha a firmware-be is bele kell piszkálni... Hétfőn kipróbálom (merthogy távolról nem megy).

Pontosítanám a folyamat leírását, mert nem fejtettem ki annak minden részletét a maga teljességében.

Cél, hogy lehetőleg szabványos rendszereszközökkel oldjam meg a klónozást. Legutóbb, jópár évvel ezelőtt, még lilo korszakban ez simán ment, igaz, ott kellett futtatni még egy lilo-t.

A korábbi tapasztalatok alapján a terv az, hogy:

1. partíciós tábla (és a csekély méretű efi partíció) átmásol a klón gépekre. A dd eddigi tapasztalataim szerint kiválóan megfelel ilyen célokra, esetünkben egy-kétszáz MB-ról beszélünk, sem helyfoglalásban, sem írási i dőben nincs érdemi időigénye. Az SSD-k egyformán 256 GB-osak, tehát partcíióméretet nem kell igazítani.

2. a swap és root fs partíciókat formázni kell, elhanyagolható időigény.

3. a mintagépet pendrive-ról indítva a root fs becsomagolható tgz-be (ez eltart jó darabig, de egyszer kell megcsinálni).

4. a klón gépeken kicsomagolandó a root fs (--preserve-permissions, --same-owner)

5. lilo (régen) / efibootmgr (most)

6. gépnevet és ip címet átírni

Elvileg készen vagyunk, újraindítás.

Most gondolkoztam el, hogy a root fs tgz átvitele a hagyományos vinyók és lassú hálózat esetében egyértelműen a leghatékonyabb megoldás volt, amíg a harmadik gépen elindítottam, az elsőn átírtam az ip-t meg a gépnevet, azalatt a másodikon bőven kicsomagolt. Valószínűleg mnapság az rsync lesz a nyerő.

Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz ---X--- Gbit hálózat

Üdvrivalgással:
KEA.

Az 1) kapcsán mivel másolod át a particiós táblát? GPT gondolom. Ha nem bájtra pontosan egyforma a két diszk, olyankor kellett nekem az, hogy teljes diszk dd után javítsa a gtp -ben, hogy a teljes diszkre szóljon (gparteddel).

Az 5) szeritem is a bootmanager live rendszerről újratelepítése be szokta regisztrálni. Régebben, amikor másoltam már le ubuntut, akkor a live -ról grub újratelepítős lépéseket csináltam. (vicces módon win esetén is hasonló, csak ott meg a win telepítő recovery mód konzoljában kell kiadni pár parancsot, hogy újratelpeítse a bcd-t / bootot fixálja).

Leginkább azt hiányolom, hogy valamiért nem nagyon van linuxon könnyen kezelhető grafikus frontend ezekhez. Pedig az emberek 99%-a nem reszelni akarja, hanem használni és két kattintással lehetne parancsok ismerete nélkül megoldás. Új gépemen már inkább a grafikus biosban lett rá felület, ahol törölni lehet bejegyzést (és talán újat hozzáadni is)

Szerintem igaza van a kollégának, jó lenne GUI-s megoldás, sok embernek óriási segítség lenne, csak az a baj, hogy a linuxos felhasználás sokszínű. Nem lehet egy megoldással minden esetkört lefedni, mert lefeded a szokásos GRUB, ext4, stb. use case-t, de akkor mindjárt jön a másik, hogy neki Slackware-rel, meg lilo-val nem megy, vagy másik disztrón systemd-bootal, vagy EFI stub boottel, meg aszerint is variálódik, hogy van-e initramfs, meg milyen módszerrel van létrehozni, egyesenek a btrfs snapshotok bootolhatósága is fontos, aztán azokról még nem is beszéltünk, akik LUKS titkosítát, RAID-et, LVM-et, vagy netán ZFS zpoolt használnak, mind-mind más felállás teljesen.

Windowson azért is van GUI, mert ott normikra gyúrnak, céges, mivel ott megéri nekik fizetősen nyújtani, van elég user, aki kifizeti, meg a windowsos megoldások homogénebbek, elég a bitlocker, NTFS, FAT, exFAT-ot támogatni (lassan már az MBR-t sem kell majd, ha megszűnik a Win10 support, mert a Win11 az normálisan, hackek nélkül csak GPT only), és viszonylag kis varianciával lefednek mindent.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Épp írni akartam, hogy ezt jól megcsinálni szinte lehetetlen, ha meg elreccsen a klónozó program, ott áll a felhasználó megfürödve. Minden eset egyedi szinte, nehezen automatizálható. Ha meg pilótavizsgás a kezelői felület a rengeteg opció miatt, akkor egyszerűbb a command line.

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

nem kell minden esetet automatikusan kezelnie, de a mostani toolok is sokszor frontendek. Csak lehagyják a képességek nagy részét, mert csak pár lehetőséget támogatnak. A terminálos frontenddel sem lenne gond, de sokkal korlátozottabban lehet sok információt vagy opciót megjeleníteni. Egyébként is 99% grafikus felületen lévő terminál ablakkal találálkozik az emberek többsége. Ha mindig az összes lehetőség összes automatizálása a cél, akkor soha semmit sem fog senki megcsinálni, hanem csak sajnálkoznak, hogy jaj azt nem lehet. Grafikus felületen a különböző opciókat gyorsan átlátható módon ki lehet vezetni, tooltipekben infókat jelezni, nem kell órákig nyálazni hozzá, hogy most éppen milyen betűkombinációs paramétert kell használni és milyen formában vár paramétereket. 

Gyakorlatilag most is tudna kb mindent a gparted, vagy más hasonló tool is. De nem érezték fontosnak a block copy opció lehetőségét, hogy ne fájlrendszert másoljon, hanem particiót... lehet rosszul emlékszem, de talán a clonezillában sem láttam ezt. Bosszantó, amikor ott a tool, de lekorlátozzák a legalapvetőbb funkcióját, mert uh hát a nagyon okos megoldás a legjobb. Csak éppen 10x tovább tart és nincs értelme sok esetben.

Persze azt is megértem, hogy rengeteg órát ki lehet számlázni favágásért és ha ismétlődő feladat, akor magának még meg is automatizálhatja az ember. Sokszor ezt látom, hogy el van misztifikálva a primitív manuális munka és nem cél hatékonynak lenni, mert időre fizetnek.

1) Azért nézd meg fdisk -l vagy gdisk -l paranccsal a pontos méreteket, mert a két 256 GB-os SSD nem biztos, hogy pontosan ugyanannyi szektor.

2) Ha dd-vel szektor szinten másolsz, akkor nem kell formázni, hiszen a filerendszert másolod. Ha file-osan másolsz, akkor kell előtte formázni, de akkor figyelj az fstab-ban arra, hogy nem fog egyezni a filerendszer UUID, vagy másik lehetőség, hogy az új filerendszerre az eredeti UUID-ját erőszakolod.

5) Olyan is lehet, hogy kell az efibootmgr, de ha a shim még csak a grub2-t indítja, akkor grub-ot is futtatni kell majd. Akkor kell pendrive-ról boot, meg egy rakás mount --bind, továbbá chroot.

Szerk.: Ja, igen, UUID nem egyezés lehet a grub-ban is, szóval lehet, hogy rondább, de kényelmesebb az azonos fs uuid használata.

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

Az 1)-hez az is hozzátartozik, hogy GPT esetén a diszk elején és a diszk végén is van egy partíciós tábla. A dd-s másolásnál ez rohadt nagy problémát fog okozni, ha nem a fizikailag legkisebb diszkből készül a másolat - ez a másodlagos tábla a kisebb diszk(ek)re nem fog ráférni.

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

Már persze, mindezt csak akkor probléma, ha "koppanásig" tele volt partícionálva a (nagyobb méretű) forrás diszk - de az MBR partíciós tábla esetén is probléma.

Linuxon, partíciós tábla szkriptelt átvitelére ott az sfdisk --dump opciója. (sfdisk --dump /dev/sda | sfdisk /dev/sdb)
A dump egy sima plaintext fájl, ami egyszerűen kezelhető akár sed-del is.
(Az sfdisk tud json és xml kimenetet is, de azokat nem tudja visszaolvasni)

Ezért célszerű olyan alkalmazást használni, ami az eltérő mértetek kezelésére is képes. A Clonezilla pont ilyen, ugyan nem GUI-s, hanem TUI-s, de parancssorból is lehet paraméterezni (akinek GUI-s változat kell, annak ott a Rescuezilla).

Clonezilla esetén nem kell túl sokat számolgatni, miért is tennénk, hiszen nem azért írunk programokat, hogy egyszerűsítsük az életünket? Persze tudni kell, hogy mit akarunk, tudni kell, hogy honnan hova és mit, melyik meghajtó és melyik partíció mekkora, de akkor, ha a meggyőződtünk róla, hogy a másolandó adatok elférnek az új (akár kisebb) meghajtón, megfelelően paraméterezve a Clonezilla elvégzi a munkát.

30 tokegyforma gep

Ugyanolyan néven simán lehet, hogy teljesen más ssd-k vannak. A gyártóknak szokása variálni a beszállítókkal. Például kingston nv2 2TB méretűből is van legalább 4 változat, különböző kontrollerrel, van amelyik tlc van amelyik qlc flash-sel :( Brand gépeknél is előfordulhat különbség a gépek közt, hiába "egyformák". Persze, ha már konkrétan átnézted őket és tényleg egyformák, akkor mázlid van :)

( locsemege v | 2023. 09. 04., h – 23:34 )

Nem nyitok másik témát, mert teljesen ontopic, viszont a saját küzdelmem.

Ma klónoztam egy Linuxot egy másik gépre, de kétségbeejtő nehézségek árán tudtam szögelve, szigszalagozva boot-olhatóvá tenni.

Forrás gépbe betettem a célgép HDD-jét és SSD-jét. GPT-re particionáltam, majd formáztam, kicsit gány módon a forrás filerendszerek UUID-jait adtam a cél fs-eknek is, hogy ne kelljen a configokat átírni. Aztán, mivel élő oprendszer file-jai változhatnának, live-ot boot-oltam, majd ott rsync -avxHASX forrás cél módon másolgattam a /, /home, /boot tartalmát. Természetesen a /dev, /proc, /run, /sys, /tmp, /home könyvtárak nem kerültek másolásra, azokat üresen létrehoztam.

Áttettem a háttértárakat a cél gépbe, majd chroot-olt környezetben feltettem a shim-x64-et, telepítettem a grub2-t a /dev/sdb-re. Futtattam grub2-mkconfig -o /boot/grub2/grub.cfg parancsot is.

Az első, amit észrevettem, hogy a kernel paraméterek között ott maradt a forrás gép lvm hivatkozása. A /etc/default/grub file-ban javítottam. Javítottam a /etc/fstab hivatkozásait is, valamint csináltam új initrd-t dracut -f initrd_image kernel_version paranccsal.

Az alaplap támogat EFI boot-ot és legacy BIOS boot-ot is, valami nem a legújabb brand HP gép. Fura volt, mert a Fedora telepítő, amelyet console módban használtam live-ként, noha látszott EFI és legacy device-ként is, csak legacy módban boot-olt, így viszont nem volt /sys/firmware/efi alkönyvtáram. Magam sem tudom, hogyan, de valamikor belemászott a Fedora, mert a grub2 elindult, de csak addig, hogy promptot adott.

Órákig nem jutottam előrébb. Aztán észrevettem a grub promptja alól, hogy a grubenv-et nem a szokásos helyen, hanem a /EFI/fedora/grubenv helyen várja, ahol semmi keresnivalója. Odamásoltam a többi file-lal együtt. A grubenv-et manuálisan editáltam, noha felhívják a figyelmet, hogy nem kéne. Vigyáztam, hogy 1024 byte maradjon, # karakterekkel newline nélkül volt feltöltve a vége.

Végre lett boot menüm, behúzta a kernelt, de szinte minden szolgáltatás [FAILED]-et mondott. Tettem a gyökérbe egy .autorelabel file-t, érzésből visszatettem a régi initrd-t. Emiatt a video hw kezelés kicsit elmúlt, ellenben megcsinálta vaktában a SELinux relabelinget. Utána végre boot-olt a gép!

Eljött a pillanat, hogy nem chroot-olt környezetben csináljak initrd-t. Fura, hogy az eredeti méretnek kb. a 60 %-a lett, de működik.

Egyébként hogyan lehet elmesélni a grub2-nek, hogy a grubenv ne a /boot/efi/EFI/fedora/grubenv legyen, hanem a /boot/grub2/grubenv? Mert elég gány, hogy az EFI filerendszerre másoltam fel.

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

Szerintem ez ide van bedrótozva!
RedHat-en így néz ki kb.(7,8,9):

# ls -l /boot/efi/EFI/redhat/grubenv
-rwx------ 1 0 0     999 Jul  3 15:41 grubenv

Ez alapján : Grub2 commands fail with error /usr/bin/grub2-editenv: error: invalid environment block or error: environment block too small - Red Hat Customer Portal

Valóban ott kereste a grub, nevezetesen az efi filerendszer /EFI/fedora/grubenv volt a file, mount pointot figyelembe véve /boot/efi/EFI/fedora/grubenv.

Annyiban meglepő, hogy civilizált helyeken ez a /boot/grub2/grubenv szokott lenni. Bár meglehet, hogy az előbbi EFI boot esetén, az utóbbi pedig legacy BIOS esetén van így. Viszont akkor lehet, hogy készen vagyok, nem is kell hozzányúlnom.

Ami viszont nem világos, hogy noha újratelepítettem a szükséges csomagokat, ideértve a shim-x64-et is, a post install scriptek valamiért mégsem pakolták be a helyére. Na jó, lehet, hogy ezt is értem. Valamiért a live Fedora - netinstall rescue console módban - legacy módon indult, s nem volt /sys/firmware/efi könyvtáram, tehát a post install scriptek arra gondoltak, ez nem efi-s környezet, pedig de.

Köszönöm az infót, akkor úgy tűnik, nincs vele dolgom tovább. Annál is inkább, mert nekem nincs Red Hat előfizetésem, s nem látom a forrásodban megjelölt cikket végig.

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

( kea | 2023. 09. 06., sze – 09:41 )

Úgy néz ki, működik, a kulcs az efibootmgr. Még ellenőrzök pár dolgot, aztán megírom a részleteket.

( kea | 2023. 09. 07., cs – 09:07 )

Kedves Mind!

Nagyon örülök, hogy ilyen élénk eszmecserét váltottam ki a kérdésemmel, külön érdekessége ennek, hogy mennyire szerteágazó részletekre is kitértetek. Összefoglalnám az eddigi tapasztalatokat, merthogy a probléma megoldva. A magam részéről a kulcsmozzanat az efibootmgr (hiánya) volt. Összefoglalva:

Adott 30+1 géptermi gép, nagyjából egyformák. Slackware 15 megy rájuk, klf. kiegészítőkkel. Ezt szeretném klónozással megoldani egyrészt a hatékony gyorsaság, másrészt a garantált egyformaság miatt. A folyamat most így néz ki:

USB boot (Slackware 15 gyári), CMOS-ban beállítandó az UEFI mód (l. lennebb). A rendszer elindulta után az USB-t minden további nélkül ki lehet húzni, mehet a következő gépbe.

Másik USB-ről (vagy az elsőről, de akkor csak később mehet a köv. gépbe) a partíciós táblát és az efi partíciót (kb. 100 MB) kiírom dd-vel az sda elejére. A mintagép esetében az fdisk megmondta, hogy az első partíciónak a hányadik szektoron van vége, ennyi darab szektort kellett a pendrive-ra kiírni a mintagépről (bs=512, count=ennyi).

parted -- azt mondja, hogy a GPT tartalék partíciós tábla a korrupció híve, és az elsőt használja (természetesen ez OK). A majdani rednszerpartíció nevét megváltoztatom (egyrészt rokonszenv alapon, másrészt meg hogy legyen adatváltozás, tutira írjon a lemezre), kilépés, innentől ez rendben.

mkfs.ext4 /dev/sda3

mkswap /dev/sda2

rootfs kicsomagolása az sda3-ra (mount után odamenni a csatolási pontra, sda3 gyökere), tar -xzps --same-owner -f valahol-van-a-csomag.tgz (nincs rsync, ill. scp távolról ide lehetőség a gyári boot usb-ben, és ez is elegendően gyors, egy-két perc alatt kicsomagol)

chroot . a /dev/sda3 gyökérkönyvtárában

mount /proc -t proc

mount -t sysfs sysfs /sys

modprobe efivarfs (na ez nem megy, ha nem uefi módban indult a gép, l. fennebb)

mount -t efiwarfs efivarfs /sys/firmware/efi/efivars

mount /dev/sda1 /boot

efibootmgr -c -L "Slackware15" -l '\EFI\Slackware\elilo.efi' (saját adatok;)

/etc/HOSTNAME javít (gépnév)

/etc/rc.d/rc.inet1.conf javít (IP cím)

/etc/udev/rules.d/70-persistent-net.rules javít (eth0 MAC address, ha ez nincs, akkor időnként(!) eht1 lesz a kártya)

Újraindítás most már vinyóról, és elvileg minden rendben. (hacsak valamit össze nem kevertem vagy el nem felejtettem tegnap este óta).

Köszönet a hosszászólásokért, különösen is az efibootmgr-ért.

Üdvrivalgással:
KEA.

Hm... Köszönöm a tippet. Én is ezt gondoltam, de a sebesség miatt allokáltam SSD-re a swap-et arra hagyatkozva, hogy manapság felesleges már HDD-re tenni a gyakran írt részeket, mart az SSD-k strapabírók már. Akkor tehát mégse. Kénytelen leszek áttenni a swap-et HDD-re az általam klónozott gépen.

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

Érdekes, én chroot előtt szoktam bind mountolgatni. Tegyük fel, hogy a root fs fel van csatolva a /mnt/sysimage alá. Ekkor:

cd /mnt/sysimage
ls
mount --bind /dev ./dev
mount --bind /proc ./proc
moubt --bind /run ./run
mount --bind /sys ./sys
mount --bind /tmp ./tmp
chroot .

A rendszer elindulta után az USB-t minden további nélkül ki lehet húzni

Azért erre nem vennék mérget. Attól, hogy read only squashfs - bár lehet, hogy fölötte van egy fs, ami csak a változásokat tárolja, nem jut eszembe most a neve -, attól még lehet baj ebből szerintem. De lehet, hogy a Slackware másképp működik, s berántja RAM-ba az egész image-et, ezt nem tudom.

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

( kea | 2023. 09. 07., cs – 09:10 )

Hol lehet ennek beállítani, hogy [MEGOLDVA]?