Dotaz: Boot z jineho disku

[JN]

Nazdarek!

V NB mam SSD a HDD, ktere ma i prazdnou partisnu. SSD bych rad vymenil za vetsi, ale obsahuje system vcetne /boot-u. Momentalne pri sobe nemam USB klic, ktery bych vyuzil na instalaci systemu na novy disk. Proto bych chtel nabootovat z HDD, udelat bitovou kopii jednoho SSD, vymenit SSD a udelat bitovou kopii zpet.

Problem: zkousel jsem to prez `grub-install --boot-directory=/media/tadybudeboot/boot /dev/sda2` (pak i bez posledni 2). Jaksi to nezafungovalo, nejen ze sem stratil data na partisne `tadybudeboot`*, ale se boot z nove partisny nefunguje, ani nezacne. V boot tam nejsou zadne grub binarky, takze mozna proto.

Vite nekdo, jak na to? Nechci si rozhasit svuj puvodni boot, kdyz to pujde. Mam UEFI/GPT.

*dulezita data jsem obnovil, ale byl tam ext4, nesel pripojit a e2fsck presunul vsechno do /lost+found/.

---

---

Odpovědi

[Pavel 'TIGER' Růžička]

Ten dotaz je poněkud zmatený a zřejmě v tom stylu byly provedené i kroky. Jediné co jsem vyčetl, že HDD se hlásí jako sda. Je tomu skutečně tak? Pokud máš UEFI/GPT, tak boot musí být na fat32 oddílu. To s tou ext4 moc nechápu, na žádnou se nemělo sahat, nebyl k tomu důvod. Zřejmě si chtěl systém rozbít a jak to tak vypadá, tak se ti to i povedlo.

[Andrej]

Pokud UEFI příslušného stroje nemá problém s UAS (což by v roce 2020 fakt neměl být problém), nejlepší bude staré SSD vytáhnout, nové dát do notebooku a ze starého SSD pak nabootovat

• pomocí tohoto, pokud je to starý 2.5" SATA formát, nebo
• pomocí tohoto, pokud je to SATA skrz M.2 (pravděpodobně M-key), nebo
• pomocí tohoto, pokud je to PCIe NVMe do M.2 slotu (rozhodně M-key) (což ale podle mě není, protože by se to implicitně jmenovalo /dev/nvme0n1, nikoliv /dev/sda).

Kdyby UEFI nedokázalo nabootovat z UAS, dala by se celá věc udělat obráceně, tedy připojit přes adaptér nové SSD, tam provést celý ten přesun a pak teprve SSD v notebooku vyměnit.

[kolík]

a nebo https://www.axagon.eu/produkty/prislusenstvi-disku

[Petr Fiedler]

Jo a kvůli velikosti obrazu a jeho následném zbytečně velkém zápisu na SSD nevytvářet obraz hdd pomocí dd, ale naklonovat jej Clonezillou.

[Petr Fiedler]

EDIT: nevytvářet obraz SSD...

[kolík]

nechápu

[k3dAR]

nastroj "dd" cte i zapisuje image o velikosti celeho disku, Clonezilla pouze obsazeneho mista...
tzn. ze s dd se z 512GB disku s obsazenejma 10GB, kopiruje tam i zpet 512GB, s Clonezillou pouze tech ~10GB

[Pavel 'TIGER' Růžička]

Ale pořád můžeš ten image z dd komprimovat a případně i rozdělit. Pak se hodně přiblížíš obsazené hodnotě.

[Petr Fiedler]

... případně i rozdělit.

A jak poznáš, kde střihnout? Respektive, spíš by mě zajímalo, jak bys to celé provedl. Máš ve stroji SSD 512 GB a na něm GNU/Linux. Chceš pomocí dd udělat komprimovaný ustřižený obraz. Co dál?

[Peter Golis]

Na SSD by malo stačiť spustiť TRIM, ten vynuluje nepoužívané miesto. A bloky "zaplnené" nulami sa komprimujú veľmi dobre. Samotný TRIM sa sám spúšťa na týždennej báze, takže by som odporučil spustiť to ručne nejakú dobu pred klonovaním (a pozrieť stav v S.M.A.R.T, ak to disk nezatajuje).

[Petr Fiedler]

No dobře, vyTRIMuješ SSD 512 GB s 10 GB dat a pustíš na něj dd s kompresí. Jak bude podle tebe velký výsledný obraz?

[Petr Fiedler]

Tak už mám odpověď. Výsledný obraz by byl malý, ale čtení i zápis by trvali zbytečně dlouho.

[Peter Golis]

Čo znamená zbytočne dlho? Rád by som si pozrel výsledok že či na tom spomalení aj záleží. Ale skús to s väčším bufferom (64k je zbytočne málo keďže sa jedná o lineárne čítanie), a s parametrom status=progress.

Mne išlo čítanie takýchto núl maximálnou rýchlosťou čo mi dal diskový radič (2 Gbit/s), ale bolo to na radiči ktorý bol určený na optickú mechaniku. 1/4 TB mi to tak dalo za 15 minút. Keď som to čítal cez USB3, tak to išlo rýchlejšie.

Ak by ti to išlo bežnou rýchlosťou prázdnych SSD (5 Gbit/s), tak máš to prázdno z 1/2 TB SSD prečítané do 12 minút. A ak si spomínam, tak komprimácia núl je dosť rýchla. Najpomalšie by mohlo byť akurát jednovláknové komprimovanie údajov. A to neviem či má v sebe CloneZilla vyriešené, nepoužívam ju.

[Petr Fiedler]

Na pc, nebo nb to zkusit nemůžu - LUKS, ale až bude čas, tak vypnu RPi a zkusím to.

Co se týká komprese, tak pokud má člověk dost volného místa na úložišti pro zálohy, tak jí ani nemusí zapínat a je to rychlejší.

[Peter Golis]

Skúsiť to môžeš, keď budeš čítať priamo /dev/sdX. To s LUKS nič nemá, a LUKS by mal tiež vystrieľať nuly cez TRIM. Podobne môžeš čítať aj rozkódované dáta z odomknutého /dev/dm-N, tam sa ti ale trošku prejaví spomalenie pri dekrypcii. Inštrukčná sada AES-NI (Via Padlock) zvykla mať limity v priepustnosti.

Ale robiť test rýchlosti čítania SSD na RPi, to asi nebude dosahovať rýchlosti desktopového radiča. A prejaví sa úzke hrdlo v pomalejšom radiči. Na tom RPi teda otestuješ len možnosť, ale výkon už bude mimo rozsahu.

[Petr Fiedler]

Skúsiť to môžeš, keď budeš čítať priamo /dev/sdX. To s LUKS nič nemá, a LUKS by mal tiež vystrieľať nuly cez TRIM.

Myslel jsem, že když je disk celý šifrován, tak že na něj TRIM pustit nejde.

Podobne môžeš čítať aj rozkódované dáta z odomknutého /dev/dm-N, tam sa ti ale trošku prejaví spomalenie pri dekrypcii. Inštrukčná sada AES-NI (Via Padlock) zvykla mať limity v priepustnosti.

Vzhledem k tomu, že moje SSD má čtení/zápis ~ 500 MBps, tak to nehrozí.

~$ cryptsetup benchmark 
# Testy jsou počítány jen z práce s pamětí (žádné I/O úložiště).
PBKDF2-sha1      1615679 iterací za sekundu pro 256bitový klíč
PBKDF2-sha256    2080507 iterací za sekundu pro 256bitový klíč
PBKDF2-sha512    1515283 iterací za sekundu pro 256bitový klíč
PBKDF2-ripemd160  868026 iterací za sekundu pro 256bitový klíč
PBKDF2-whirlpool  655360 iterací za sekundu pro 256bitový klíč
argon2i       7 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
argon2id      7 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
#    Algoritmus |      Klíč |       Šifrování |     Dešifrování
        aes-cbc        128b      1084,3 MiB/s      3193,4 MiB/s
    serpent-cbc        128b        90,7 MiB/s       685,8 MiB/s
    twofish-cbc        128b       205,3 MiB/s       382,2 MiB/s
        aes-cbc        256b       838,0 MiB/s      2603,9 MiB/s
    serpent-cbc        256b        93,2 MiB/s       686,0 MiB/s
    twofish-cbc        256b       209,2 MiB/s       382,7 MiB/s
        aes-xts        256b      1938,9 MiB/s      1940,3 MiB/s
    serpent-xts        256b       666,1 MiB/s       687,3 MiB/s
    twofish-xts        256b       372,7 MiB/s       378,7 MiB/s
        aes-xts        512b      1737,2 MiB/s      1762,8 MiB/s
    serpent-xts        512b       685,3 MiB/s       705,9 MiB/s
    twofish-xts        512b       382,3 MiB/s       386,6 MiB/s

Ale robiť test rýchlosti čítania SSD na RPi, to asi nebude dosahovať rýchlosti desktopového radiča. A prejaví sa úzke hrdlo v pomalejšom radiči. Na tom RPi teda otestuješ len možnosť, ale výkon už bude mimo rozsahu.

Nemyslel jsem testovat to na RPi, ale v pc. SSD bych odpojil a připojil je kabelem k pc, případně je dal do pc.

[Peter Golis]

TRIM bez problémov prelezie cez LUKS aj s LVM, používam to na skompaktovanie diskov z VMiek. Problémy boli so staršími implementáciami, ale asi sa nebavíme o distrtribúcii staršej 5 rokov. Tak isto sa kedysi neodporúčalo spúšťať ten TRIM na kryptovanom disku keďže to ukázalo kde nie sú dáta a mohlo to odhaliť využitie disku. Testom FIPS by takýto dizajn neprešiel. To však neznamená že to nefunguje.

Ja som si teraz len zo srandy postil performance test na môj SSD čo garantuje prietok 5Gbit/s, ale len na cca 1/4 veľkosti v ktorej má SLC Cache alebo na binárne nuly (ktoré ani nečíta, len strieľa cez kábel). A na 8 ročnom testovacom NB mi kolíše prenos medzi 2240 Mb/s (280 MB/s) a 3368 Mb/s (421 MB/s), podľa veľkosti buffera a či som zapol synchronizáciu. Medzi testami som dropol diskovú cache, a zápis bol do /dev/null keďže som chcel otestovať len čítanie. Tiež je ten SSD v pomalšom slote namiesto CDROM, akurát NB už neni ten blogovací plasťák z pred roka.

[Petr Fiedler]

Dobře, díky za vysvětlení.

[Peter Golis]

Vidím ale problém v dvoch drobnostiach:

Prvá drobnosť je že samotný gzip robí len na jedno vlákno. Keď som dal komprimovať prečítané dáta cez gzip, tak bola rýchlosť rerálne cca 4x menšia ako keď som zapol pigz (paralel gzip) na 4 jadrá (ten CPU čo mi tam dožíva je štvorjadro), tak sa ukazoval výkon cca 3.5x rýchlejší. Rýchlosť čítania brzdeného paralelnou kompresiou bola u mňa cca 700 Mbit/s (85 MB/s) čo je 5x prepad. Zápis to generovalo rýchlosťou 330 Mbit/s (40 MB/s) čo je u mňa akurát na kŕmenie USB2 rotačáku aký už asi ani nemám. Tento posledný test som nerobil na celý disk, pár minút stačilo. Nebudem predsa počúvať vyše hodinu hučanie starého vetráka. U teba na novom PC bude tá rýchlosť rádovo inakšia. Akurát je rozumné zamyslieť a či sa oplatí 10 minút vyklikávať CloneZillu, alebo človek napáše jeden riadok a nechá to pracovať nech to dobehne kým zje večeru.

Druhá drobnosť môže byť v tom, že s TRIM na BTRFS a ani na ZFS nemám dobré skúsenosti. Nikdy mi to poriadne nevyčistilo disk od prázdneho miesta. Kľudne mi to nechalo aj polku disku nevyčistenú. V prípade tradičného EXT4FS mi TRIM vyčistil všetko nepoužité miesto na disku.

PS: Keby si robil tú zálohu na pomalý USB2 disk, tak by to malo význam komprimovať za behu, ale to nebude tvoj prípad.

[k3dAR]

Akurát je rozumné zamyslieť a či sa oplatí 10 minút vyklikávať CloneZillu, alebo človek napáše jeden riadok

Clonezilla (nebo i ten holej partclone) take staci napsat 1 radek.

# z3 - use LZO compression (z1p for parallel gzip(pigz), for parallel bzip2(lbzip2), ...)
ocs-sr --clone-hidden-data --use-partclone -z3 --postaction choose savedisk jmeno_image sda

[Petr Fiedler]

Akurát je rozumné zamyslieť a či sa oplatí 10 minút vyklikávať CloneZillu, alebo človek napáše jeden riadok a nechá to pracovať nech to dobehne kým zje večeru.

Tipl bych to tak na ~ 3 minuty. Navíc, když spustíš klonování | zálohu | obnovu, tak ti Clonezilla řekne: "Přiště můžete spustit tento příkaz" a vypíše ti ty parametry, které jsi nastavil. Takže to můžeš vyřešit i takto a tím to zrychlit.

Jinak co se týká komprese, tak já používám lzo. Ale dávám to jen ze zvyku, protože mi to stejně nekomprimuje. Teď jsem to ověřoval a obraz 100 GiB oddílu má velikost 107,4 GB, což je těch 100 GiB. Nevím, jestli je to tím, že ten oddíl je šifrován, ale ten obraz prostě menší není. Příště to budu pouštět bez komprese a bude to alespoň rychlejší.

[k3dAR]

z praxe Clonezilly pri zaloze disků s holejma Windows je image s LZO kompresi cca polovicni oproti bez komprese
no v tvem pripade LUKS oddilu ho Clonezilla povazuje za RAW (ingoruje filesystem a pripadne (ne/)vyuziti mista) a ten oddil zalohuje pres DD

[Petr Fiedler]

Jo. Včera jsem zálohoval OS na RPi (nešifrované SSD) a lzo to stlačil z 2,7 GB na 1,3 GB.

[Peter Golis]

Pokiaľ je ten oddiel šifrovaný a TRIM na ňom nebol spúšťaný, tak sa tam nemá čo skomprimovať. Je to len "White Noise", teda náhodné dáta. Ovšem je možné, že ten disk nerobí TRIM okamžite, ale robí ho až keď nemá voľné miesto na prepis. Príslušníci ŠTB by sa takému HW potešili.

PS: Teraz som si všimol, že mne na tej mojej herke dokážem skomprimovať prúd núl maximálnou rýchlosťou cca 2.2Gbit/s (279 MB/s), čo je menej ako čitanie z SSD.

dd if=/dev/zero bs=10M status=progress count=1K | pigz -p4 - > /dev/null
10601103360 bytes (11 GB, 9.9 GiB) copied, 38 s, 279 MB/s
1024+0 records in
1024+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 38.4707 s, 279 MB/s

Takže tak ako pred rokmi, tak by som si nechal nekomprimovaný čistý obraz disku ktorý viem pripojiť cez všetky tie vrstvy aby som vedel pracovať s pôvodným obrazom. Občas si človek spomenie na nejaký starý konfigurák. A skomprimoval by som to až po dlhšej dobe.

[Petr Fiedler]

Pigz vypadá zajímavě. Někdy vyzkouším.

[j]

Kristova noho ... tady nekdo absolutne netusi, co dela trim...

TRIM nema naprosto NIC spolecnyho s filesystemem, a SSD nikde nic NENULUJE! Je to jen a pouze informace kterou si SSDcko zapise do svy tabulky, aby vedelo, ze danej blok nemusi pri zapisu cist, a nemusi ho v prubehu casu udrzovat.

Co ti bude SSDcko vracet pri cteni prazdnyho mista je pak ciste vec nahody. Rozhodne to nebudou nuly.

Kdyby trim fungoval tak jak si ty predstavujes, tak by to SSDcko chciplo po mesici provozu ...

Stejne tak zjevne netusis, jakej problem nastava na sifrovanym disku. Takze pro ty mene dementni ... problem je v tom, ze pokud mate 1TB zasifrovanyho disku, a ne nem nekde potencielne data, ktera zajimaji utocnika, tak musi desifrovat 1TB dat. Pokud mate disk na kterej je aplikovanej trim, tak muze snadno zjistit, ze treba 1/2 toho disku je ve skutecnosti prazdna (ale v tech blocich jsou JEDNICKY a NULY). Cimz se vyrazne zmensuje mnoztvi dat, ktery potrebuje resit.

---

Dete s tim guuglem dopice!

[Pavel 'TIGER' Růžička]

Tak třeba pro zálohu disku pomocí dd, komprimaci a rozdělení na soubory po 700MB (toho se dříve hojně využívalo pro zálohování na cd) bych použil:

dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c | split -b 700m - ./system_drive_backup.img.gz

a pro obnovu:

cat system_drive_backup.img.gz.* | gzip -dc | dd of=/dev/sda conv=sync,noerror bs=64K

Tím však nechci psát, že clonezilla je špatná, to rozhodně ne. Také ji používám, ale spíše na náročnější úkony.

[Petr Fiedler]

Tohle mi je jasné. BTW: To umí i Clonezilla, rozsekat zálohu na více kusů např. po 700 MB. Já jsem ale myslel, že mluvíš o tom, že bys nějak zjistil obsazenost toho oddílu a nastavil dle toho parametr pro dd. Např. systém o velikosti 10 GB by byl na prvních 15 GB disku a pro dd bys nastavil, aby to rozseknul po 16 GB se zapnutou kompresí. Při vytváření druhého kusu 16 GB pak Ctrl + C a ten první kus obrazu by byla ta záloha. Myslel jsem, že mluvíš o něčem na tomto principu. Pokud ale budeš pomocí dd dělat komprimovaný obraz 512 GB rozsekaný po 700 MB, tak si moc nepomůžeš, protože IMHO bude i tak dost velký. Po kompresi např. 490 GB. Proto jsem psal, že by bylo lepší použít Czillu, protože jak vysvětlil Radek, zazálohuje jen obsazené místo, tedy těch 10 GB. Je to rychlejší pro zálohu i obnovu a hlavně nemusíš zbytečně přepsat celé SSD kvůli 10 GB. Nebo jsem tě pochopil špatně a tím tvým způsobem by záloha neměla např. těch 490 GB, ale mnohem méně?

[k3dAR]

komprimovana zaloha z dd by mohla byt stejne velka (pri pouziti stejneho komprimatoru a trimnutych filesystemu) jako z Clonezilly, jenze stejne by se cetlo cele z disku (coz znamena jen cas navic) a zapisovalo cele na disk (coz znamena cas a 1 zbytecne prepsani ssd navic)... rozdil by byl "jen" v tom, ze ten image nekde ulozenej by nezabiral misto

[Petr Fiedler]

Díky za vysvětlení.
Takže použít Czillu je mnohem lepší.

[k3dAR]

CloneZillu nebo pokud nekdo chce tam primo ten partclone...
btw: bacha jak zkracujes Czilla je neco jineho

[Petr Fiedler]

To je CZilla, ne Czilla. A píšu to jen lidem u kterých vím, že ví, o čem píšu.

[Petr Fiedler]

A v případě HDD by to bylo úplně o ničem.

[k3dAR]

v pripade HDD se da "~trimovat" tak ze zapises do celeho volneho misto soubor obsahujici pouze nuly:

sudo dd if=/dev/zero of=/cesta/k/pripojenemu/oddilu/treba_soubor_smaz bs=1M status=progress

az to zarve ze doslo volne misto, soubor "treba_soubor_smaz" smazat, odpojit oddil a udelat dd komprimovanej image, ale porad bych misto toho celeho spis pouzil clonezillu ci partclone

[Petr Fiedler]

Ale to je asi oproti TRIMu mnohem delší proces, ne?

[Pavel 'TIGER' Růžička]

Tohle já nerozporuji, jen jsem chtěl upozornit, že i pomocí dd jde udělat záloha disku, která nemusí zabírat velký prostor. Nic víc.

[Pavel 'TIGER' Růžička]

Ne tohle jsem skutečě nemyslel. Jak psal Radek, když se provedou patřičné úkony, můžeš se velikostí zálohy hodně přiblížit té z clonezilly. Ano, je to časově náročnější a přepíše to 1x disk. Jen jsem to uvedl jako jednu z dalších možností. Já sám na jednoduché zálohy používám Redo Backup and Recovery a na ty složitější Clonezillu, dd používám jen když ty nástroje nemám po ruce, protožeje v každé distribuci. Ale v minulosti jsem jej využíval poměrně hojně.

[k3dAR]

Ale pořád můžeš ten image z dd komprimovat a případně i rozdělit. Pak se hodně přiblížíš obsazené hodnotě.

to samozrejme muzu, ale porad plati co sem psal, jinejma slovama: ze zdrojoveho disku se bude cist obsah celeho disku, na cilovy disk se bude zapisovat obsah celeho image obsahujici obsah celeho zdrojoveho disku.

pokud se nekdo chce (z jakehokoliv duvodu) vyhnout Clonezille, tam misto "dd" stale muze pouzit nastroj "partclone" (od autoru Clonezilly), ktery Clonezilla pouziva jako vychozi a ziska tim (oproti dd) podobnou vyhodu jako pri pouziti Clonezilly, ze se cte/zapisuje jen to obsazene misto...

[Petr Fiedler]

Zrovna ohledně partclone jsem ti dnes v jedné z reakcí psal. Chtěl jsem zjistit, jestli se dá použít sólo bez Czilly. Pak jsem si ale uvědomil, že Czilla ti právě nabízí vše pohodlně nastavit ("klonovat skrytá data mezi MBR a první partition", atd.) a že nemám důvod používat partclone sólo. I když by asi šel vychytat skript s parametry, ale to jde podobně i u Czilly.

[Jendа]

Mam UEFI/GPT.

S tím mám zatím málo zkušeností, ale podle mě není potřeba grub-install, ale stačí zkopírovat binárku grubu z jedné VFAT partition na druhou. To by mělo spustit minimálně stage1.5, z ní pak můžeš zkusit ručně najít zbytek grubu. Ani moduly by žádné chybět neměly, protože binárka grubu je sestavená tak, že na tom počítači ty disky a jejich FS vidí.

Problem: zkousel jsem to prez `grub-install --boot-directory=/media/tadybudeboot/boot /dev/sda2` (pak i bez posledni 2).

Měl jsi při tomhle pripojené v /boot/efi (nebo /media/tadybudeboot/boot/efi, kdo ví) tu novou FAT partition kde má být novej GPT boot? A zapsal se na ní soubor s imagem grubu? A když na něj dáš file, je to normálně PE32? A když dáš file na grub na stávajícím disku, ukáže to stejný výstup?

[JN]

S tím mám zatím málo zkušeností, ale podle mě není potřeba grub-install, ale stačí zkopírovat binárku grubu z jedné VFAT partition na druhou. To by mělo spustit minimálně stage1.5, z ní pak můžeš zkusit ručně najít zbytek grubu. Ani moduly by žádné chybět neměly, protože binárka grubu je sestavená tak, že na tom počítači ty disky a jejich FS vidí.

Diky, tohle vypada nadejne. Ten VFAT/FAT mi chybel, mel sem tam EXT4 a doufal jsem, ze to po grub-install nabootuje.

Na druhou otazku neodpovidam, nebot FS nesedi. Udelam FAT a napisu.

[Jendа]

Diky, tohle vypada nadejne. Ten VFAT/FAT mi chybel, mel sem tam EXT4 a doufal jsem, ze to po grub-install nabootuje.

V tom je hlavní rozdíl (z pohledu admina) oproti BIOS bootu. BIOS bootuje tak, že natáhne první sektor z disku a ten spustí. Mělo by mu být úplně jedno, co dalšího na disku je. (některé ještě ověřují, že je tam partition table a na ní partition s nastaveným boot flagem). GRUB stage 1 je v MBR a stage1.5 se typicky dává do volného místa mezi prvním sektorem a začátkem první partition (která dříve začínala na 63. sektoru, tedy 31.5 KiB, a nové (2013+) nástroje ji dávají 2048 sektor, protože disky začaly vyžadovat zarovnání na celé MiB (SSD někdy ještě na víc). Ve stage1.5 je driver filesystému, takže stage2 (to je to, co máš v /boot/grub, a je to asi stovka modulů) pak může být na libovolném FS.

EFI se bootuje tak, že firmware najde FAT partition (možná ještě musí mít nějaký flag, že to je EFI system/EFI boot), v ní adresář EFI, a v něm jsou .efi soubory, což je PE32 spustitelný soubor. Ten natáhne do paměti a spustí. V případě grubu je to soubor grubx64.efi a obsahuje stage1.5.

Teď se pouštím na tenký led, ale myslím, že Debian dodává soubor /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi, což je EFI binárka se všemi moduly, a je velká (1.7 MB), ale nikdo ti nebrání ji použít. Instalace grubu tak je jednoduše nakopírování této binárky do EFI/Boot/. A když děláš grub-install, tak se stane přesně totéž (zapíše se binárka do /boot/efi/EFI/něco/něco.efi), ale detekuje se, jaké moduly jsou potřeba, a jen ty se v ní zahrnou, takže u mě má jenom 170 kB.

Pak mám ještě vedle toho grubx64.efi soubor grub.cfg s obsahem

search.fs_uuid 9f070ae6-7995-4b3a-8eea-b8b66d7da2da root 
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

protože jinak se ti spustí stage1.5 shell místo menu.

[Petr Fiedler]

Tak tohle je super koment. Sice nebyl určen mě, ale i tak díky za vysvětlení.

[JN]

Diky! FAT mi nejak nesel, mozna je chyba u me. Vyzkouseno: zapis do /EFI/ubuntu/ubuntu.efi. Disk se "preskoci", flag boot jsem zkousel. Mozna to nepodporuje me UEFI, mozna ma SSD vetsi prioritu a proto ani nevidim chybu.

Kdyz uz vim, ze je to ve FS, tak mi nakonec stacilo udelat `dd if=ubuntu.iso of=/dev/sda2` (kde sda2 je volna partice) a z tohoto to bootuje vzdy kdyz to vyberu. Diky tomu muzu udelat bitovou kopii stare SSD->HDD->nove SSD.

Takze pro me vyreseno - diky.

[k3dAR]

- FAT oddil pro EFI ma mit flag boot a esp
- prioritu bootu urcis v "BIOSu" nebo jednorazove pres hotkey tve desky pro BootMenu (vybrat nejspis jmeno disku, viz nasledujici)
- normalne grub-install na efi dela zaroven registraci sve efi binarky do UEFI vars Boot00xx a nastavi ji do BootOrder, pod jmenem ktere pak lze vybrat v biosu ci bootmenu hotkey

- parametr --boot-directory rika kam ma dat adresar grub (vychozi je /boot tedy pouzije se /boot/grub) - pri instalaci efi verze zaroven v boot-directory musis mit adresar efi a v nem pripojen ten EFI oddil, nebo pouzit parametr --efi-directory=/kde/je/efi
nejsem si ted uplne jistej jak se chovaj tyto ^^ 2 parametry, pouzivam postup:

## pripojeni disku
sudo mount /dev/${kde_je_rootfs) /target
sudo mount /dev/${kde_je_pripadne_oddelenej_boot} /target/boot
sudo mount /dev/${kde_je_efi_oddil} /target/boot/efi

## priprava virtualnich systemovych pripojeni
sudo mount --bind /dev /target/dev
sudo mount --bind /dev/pts /target/dev/pts
sudo mount -t proc proc /target/proc
sudo mount -t sysfs sysfs /target/sys

## prepnuti do takto pripravene ciloveho filesystemu
chroot /target

nasledne instalaci grubu jako by byl system nastartovan z toho ciloveho filesystemu, bez parametru, protoze vse ma pripravene jak ma byt....

## instalace grubu na DISK sdX, nikoliv na ODDIL sdxY
sudo grub-install /dev/sdX

[Jendа]

Mimochodem ta tvoje ztráta dat by mohla být způsobena tím, že se to tam snažilo ten FAT vyrobit. Osobně bych tohle považoval za bug (přepsat ti FS bez jakéhokoli varování) a nahlásil ho.

[Jendа]

Jinak osobně nedávám --boot-directory, ale prostě se do nového systému chrootnu (předtím je potřeba nabindovat /dev, /run a namountovat /proc a asi /sys), tam to všechno připojím, a udělám grub-install /dev/sda.