LUKS šifrovaný disk + MBR. Jak vytvořit EFI boot?

[- -]

Ahoj, byl bych moc vděčný za radu. Nový počítač podporuje podle všeho jen UEFI, ne BIOS MBR/legacy.
A já mám ve starém PC šifrovaný LUKS disk s MBR. Takže když změním UEFI boot tak POST hlásí 3F0 chybu a s diskem se nebaví.

Zjistil jsem, že je asi potřeba vytvořit EFI oddíl, jenže problém je jak. Když v gparted dešifruju ten LUKS disk, tak není vidět boot oddíl , jen ext4 a gparted říká: Cant have a partition outside the disk! (díky tomu nelze disk zálohovat pomocí FIleZilla, RedoBackup fungoval)

$ sudo fdisk -l /dev/sda* ukazuje jen 1 oddíl:

    Disklabel type: dos
    Disk identifier: 0xc75ac368

    Device Boot Start End Sectors Size Id Type
    /dev/sda1 * 2048 234436544 234434497 111,8G 83 Linux

$ sudo gdisk -l /dev/sda ukazuje:

    GPT fdisk (gdisk) version 1.0.6

    Warning: Partition table header claims that the size of partition table
    entries is 1153912944 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Warning: Partition table header claims that the size of partition table
    entries is 0 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: not present
    …
    Partition table holds up to 128 entries
    Main partition table begins at sector 2 and ends at sector 33
    First usable sector is 34, last usable sector is 234441614
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 7084 sectors (3.5 MiB)

    Number Start (sector) End (sector) Size Code Name
    1 2048 234436544 111.8 GiB 8300 Linux filesystem

Jak byste tedy postupovali ohledně umožnění UEFI bootování z toho disku? Pod odkazem v prvním odstavci jsou popsané postupy jak pracovat s grub ohledně EFI, nevím ale jestli to stačí, protože podle manuálu pro můj systém se uvádí že potřebuju asi 300MB EFI oddíl FAT32, asi s boot a esp flag.

děkuji

[Reklama]

[by_cx]

Osobně bych asi přeinstaloval systém a přizpůsobil oddíly novému hardwaru. Pokud bych opravdu chtěl zachovat oddíly, tak bych udělal přes dd obraz disku na jiný disk, vytvořil GPT tabulku a oddíly jak potřebuju a pak bych tam přes dd nakopíroval oddíly, na kterých mi záleží, z té zálohy. Přes nějaké rescue CD bych pak nainstaloval grub do EFI oddílu a možná by to i naběhlo :-)

[Radek Zajíc]

Pro boot pomocí UEFI skutečně potřebujete FAT32 oddíl (EFI System Partition, type/GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B). Ten nicméně nemusí být na tom samém disku, kde je systém. Klidně může být na flashce.

Pokud chcete mít tenhle oddíl na hlavním disku, budete na něj muset udělat místo. To znamená:
1) odemknout LUKS kontejner (uvnitř partition /dev/sda1) a zmenšit oddíl/filesystém uvnitř LUKS kontejneru tak, aby bylo následně možné zmenšit LUKS kontejner (nenapsal jste, jak to přesně máte rozložené, takže tady nelze poradit líp)
2) zmenšit LUKS kontejner
3) zmenšit LUKS partition (/dev/sda1)
4) vytvořit EFI partition, klidně na konci disku (/dev/sda2)
5) do EFI partition nainstalovat GRUB
6) v setupu nebo pomocí efibootmgr nastavit pořadí bootování UEFI, aby první byla tahle EFI partition

Je to realizovatelné, ale pokud uděláte chybu v pořadí kroků (např. pokud máte v LUKSu ještě LVM), můžete přijít o data. Varianta "data vykopírovat ven, disk znovu rozdělit, vytvořit nový LUKS kontejner a data nakopírovat zpátky" tak může být jednodušší a bezpečnější.

[IDontCare]

Je opravdu nutne z toho disku bootovat?

[k3dAR]

- -: dodej vypis z "lsblkd /dev/sda"
Zalohovat pomoci FileZilla? to urcite neni vhodne pro system, na nej pouzit rsync, neco jako:

Kód: [Vybrat]

sudo mount --bind / /mnt
sudo rsync -av --progress --sparse --links --hard-links /mnt/ sshuser@sshserver:/adresar/kamresp. vhodnejsi by bylo na cilovej aktivovat rsync demona (a nastavit kam muze) a rsync do cile ne pres ssh, ale pres rsync protokol:

Kód: [Vybrat]

sudo rsync -av --progress --sparse --links --hard-links /mnt/ rsync://rsyncserver:/adresar/kammuze
by_cx: URCITE nedelat dd zalohy oddilu(nebo odemceneho luks konkejneru), protoze kdyz by je pak vracel zpatky, tak by byl dd img VETSI nez novej oddil a tedy by image "vytekl" pres nasledujici oddil, ci "mimo disk" tedy by se neokopiroval, ale luks a/nebo filesystem si  myslel ze je vetsi nez je oddil, atd...

IDontCare: a jak by asi systemovej disk nastartoval? telepatii? nebo zbytecne pridaval USBFlash ci dalsi disk na kterem by mel zavadec co by startoval system z reseneho disku?

Radek Zajic: zmensovat(resp. pouze zkracovat zprava, pokud vim zleva to normalne nejde) LUKS kontejner je trochu opruz, obzvlast jak pises kdyby tam mel mezi ext4 a LUKS jeste LVM, takze pokud by do toho sel tak ROZHODNE nejdriv vyzalohovat   

[Reklama]

[Radek Zajíc]

k3dAR: zrovna nedávno jsem zmenšoval svůj LUKS, ve kterém mám LVM a btrfs, takže mám v paměti, jaká pakárna to je.:-)
Zmenšení zleva se dá udělat tak, že ho zmenším zprava a přesunu celý kontejner doprava, čímž si vytvořím místo vlevo. Je to další krok navíc nad rámec toho, co už jsem napsal v předchozím příspěvku, ale jde to. Pokud jde jen o vytvoření bootovacího oddílu, tak to není s UEFI potřeba.

Jinak rozhodně souhlasím: zálohovat, zálohovat, zálohovat!

[- -]

Děkuji. Nemám žádné velké novinky zatím, ale přesto:
@k3dAR

Kód: [Vybrat]

$ lsblk /dev/sda
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0 111,8G  0 disk 
└─sda1                                          8:1    0 111,8G  0 part 
  └─luks-... 254:0    0 111,8G  0 crypt /
Na disku není LVM, vše kromě asi zavaděče by mělo být šifrované LUKS, žádný jiný oddíl (ani swap) by tam neměl být.

Překlep, ne FileZilla ale CloneZilla zahlásila oddíl mimo disk, to samé gparted. RedoBackup (stará verze) to zdá se zazálohovala, i když trochu podezřele.

> sudo mount --bind / /mnt
tomuhle moc nerozumím (včetně toho bind), v chroot bych asi nepoužil / ale /dev/sdX a při bootování z toho disku, který chci zálohovat nevím jaký by byl efekt to mountnout 2x (zapoměl jsem podotknout že nejsem pokročilý uživatel Linux).

[k3dAR]

z vypisu(+to co si dal pretim) je to jiz jiste:
- mas 1 oddil, na nem LUKS a na nem(=jeho odemcenem kontejneru) 1 oddil pripojen jako koren /

s "mount --bind / /mnt" sem uvazoval ze rsync bys delal na HW kde z toho disku slo bootovat, tedy z nebehleho systemu, duvod proc existujici pripojeni /dev/sda1 do / pripojujes jeste 1x do /mnt, je ten abys odfiltroval dalsi pripojeni (tedy /dev, /dev/pts, /proc, /sys) a rsyncoval tedy cistej obsah z sda1... rsync ma sice parametr --one-file-system (ci to same zkracene: -x ) , takze se zda ze misto bind bys mohl rsyncovat s timto parametrem primo stavajici koren / ALE pak bys mel prazdnej adresar /dev (protoze na nej je pripojen udev/devtmpfs), jenze v sda1 adresari /dev jsou pritom staticke soubory zarizeni pouzite nez se udev nahodi, kdyz rsyncujes bindnutej adresar tak tam prave tento obsah toho /dev mas...

pokud bys delal rsync z LiveUSB, tak samzrejme staci 1x pripojit /dev/sdXY kamkoliv a rsync pak ten adresar, naopak NEdelat chroot (kde bys opet pripojil /dev, /dev/pts, /proc, /sys a opet by byl potreba bind jinam ;-), chroot je potreba POUZE pokud bys chtel treba instalovat zavadec, aktualizovat balicky, aktualizovat initramfs atd...)

jeste takove doporuceni, disk mas 120GB, muzes si usetrit cas a pripadne komplikace, kdyz misto odlejt data jinam, disk format a vrait zpet, proste poridis druhej disk, a z stavajiciho 120GB to na novej pretahnes, s tim ze 120GB proste hodis pak do suplete jako backup
250GB za 1044Kc
 ci rovnou 500GB za 1624Kc, sice chapu ze ti treba 120GB staci, ale tu u WD Blue uz nevidim, zaroven kdyz 500GB stoji jen o 600Kc vice... ;-)

[- -]

1) odemknout LUKS kontejner (uvnitř partition /dev/sda1) a zmenšit oddíl/filesystém uvnitř LUKS kontejneru tak, aby bylo následně možné zmenšit LUKS kontejner (nenapsal jste, jak to přesně máte rozložené, takže tady nelze poradit líp)
2) zmenšit LUKS kontejner
3) zmenšit LUKS partition (/dev/sda1)
...

V gparted je právě ta chyba oddíl mimo disk a nemožnost cokoliv dešifrovat, přidat nebo resize. Viz obrázek pod odkazem níže.
Nástroj "Disks" někeré funkce umí, ale neumožňuje resize (volba je neaktivní) nebo přidání oddílu. Ani ten nedokáže dešifrovat LUKS, viz. chyba na obrázku, odkaz níže.

Zkusil jsem dešifrovat manuálně:
$ cryptsetup luksOpen /dev/sda1 abc
Disks ukázal ext4 ale stále nemůžu resize a když jsem zkoušel manuální příkaz resize2fs -p /dev/sda1 tak si to stěžovalo že je využíván a nemůže nic udělat. Možná jsem jen zadal špatnou cestu.
Jelikož jsem lama, tak bych tuhle úlohu nejraději udělal v gparted, ale nemůžu, obrázky:

https://postimg.cc/gallery/mRTVTTG

Pokud vás NEnapadne jak to resize a novou partition vytvořit, tak se budu asi klonit k instalaci od nuly a možná pak zkusit to, co tu psal @k3dAR (skopírování dat ze starého disku na nový):

sudo mount --bind / /mnt
sudo rsync -av --progress --sparse --links --hard-links /mnt/ sshuser@sshserver:/adresar/kam

Možná, že nový počítač by musel být v režimu live-usb a root filesystem mountnutý, kvůli tomu aby nebyl při nahrazování používán.
Jinak druhá varianta je jen obnovit /home/user a nainstalovat aplikace
STARY: pacman -Qqen > pkglist.txt;pacman -Qqem > pkglist_aur.txt
NOVY: pacman -S --needed - < pkglist.txt; for p in $(cat pkglist_aur.txt);do pamac build $p --no-confirm;done

[k3dAR]

ok, mas Arch, tak ohledne rsync nejake info z Arch Wiki:

Full System Backup (v ramci jednoho stroje z disku na disk)
https://wiki.archlinux.org/index.php/rsync#Full_system_backup

File System Cloning (v ramci 2 stroju v siti, ze stroje na disk v jine stroji)
https://wiki.archlinux.org/index.php/rsync#File_system_cloning
INFO: misto meho reseni s bind, je zde uvedena moznost exclude vsech "virtualnich" ci "docasnych" adresaru,
porad to ale neresi ze v cili v /dev budes mit prazdno, coz resi prave ten rsync z bindovaneho kde exclude jiz neni treba...

POZOR: pokud cil je ssh server, tak musis pouzit root@server
nebo jak sem psal lepe pouzit cil protokol rsync:
https://wiki.archlinux.org/index.php/rsync#rsync_daemon
nezapomenout vytvorit config kam rsync muze:
https://wiki.archlinux.org/index.php/rsync#Example_configuration


~~~
ohledne zmenseni, nejde o to zda me neco napadne, ale zda neprijdes o data ;-) proto sem jako nejvhodnejsi navrhnul koupit novej disk ;-) protoze Radej Zajic ti psal hrubej postup a to ze nesmis udelat nic ve spatnem poradi a ty prvni co udelas je spatnou vec ve spatnem poradi "resize2fs -p /dev/sda1" = na sda1 NEmas filesystem, ale LUKS ! je potreba pochopit ze filesystem je az na odemcenem kontejneru, v tvem pripade /dev/mapper/abc, ten (filesystem) bys mohl zmensit pres resize2fs, pak je potreba contejner zavrit a provest resize LUKS, pak provest resize oddilu sda1 - to vse delat z USBLive a po (dobre provedene) zaloze a VZDY ten dalsi krok provest radeji zmenseni o neco mene nez predchozi krok, tzn klidne filesystem(pred zmenseni a po zmenseni provest "e2fsck -f /dev/mapper/abc) o 30GB, contejner o 20GB, oddil o 10GB = radeji nez se splest a neco NAD zmensit mene nez to POD ;-) presnejsi info pripadne az po tom co opravdu provedes spravne zalohu ;-)

[k3dAR]

k tomu rucnimu zmensovani, dobra zprava (resp. pokud bys vyresil problem s tim tvojim divnym oddilem GParted 1.2, resp. nahozene gparted-live-1.2.0-1-amd64.iso sem uspesne na par kliku zmensit LUKS (na pozadi to udelalo to co sem psal, nejdriv filesystem na kontejneru, pak luks, pak oddil)

ale bohuzel mi unika co mas za problem:
gdisk i fdisk ti ukazuje pro oddil 1 start 2048s end 234436544s
pritom gparted rve ze oddil 1 zacina na 3054462464s
a total ze ma disk: 234441648s coz udaje z gdisk a fdisk a oddil 1 NEpretekaj...

napada me ze mas naborenou MBR, nebo ze mas tak i GPT z nejakeho pokusu (i kdyz gdisk GPT nevidi)
zkus jeste hodit komplet vystup z: sudo parted /dev/sda unit s print...
pak bych asi zkusil vymazat mbr i gpt a vytvorit znovu mbr s 1 oddil totoznej start 2048s end 234436544s

[by_cx]

URCITE nedelat dd zalohy oddilu(nebo odemceneho luks konkejneru), protoze kdyz by je pak vracel zpatky, tak by byl dd img VETSI nez novej oddil a tedy by image "vytekl" pres nasledujici oddil, ci "mimo disk" tedy by se neokopiroval, ale luks a/nebo filesystem si  myslel ze je vetsi nez je oddil, atd...

Tak měl jsem na mysli dd toho LUKS oddílu. Ale ani v jednom případě se nemůže nic stát a dá se ddčknout jak zamčenej i odemčenej, jen se podle toho musí upravit velikost cílového oddílu.

[k3dAR]

URCITE nedelat dd zalohy oddilu(nebo odemceneho luks konkejneru), protoze kdyz by je pak vracel zpatky, tak by byl dd img VETSI nez novej oddil a tedy by image "vytekl" pres nasledujici oddil, ci "mimo disk" tedy by se neokopiroval, ale luks a/nebo filesystem si  myslel ze je vetsi nez je oddil, atd...

Tak měl jsem na mysli dd toho LUKS oddílu. Ale ani v jednom případě se nemůže nic stát a dá se ddčknout jak zamčenej i odemčenej, jen se podle toho musí upravit velikost cílového oddílu.

jasne, ale vychazel sem z toho ze kdyz ddckem udelas image oddilu, pak disk prerozdelis abys meli efi oddil a vracis image zpet, tak logicky ten novej cilovej oddil uz bude mensi o velikost toho efi oddilu, takze tvuj postup ano, ale pokud by to bylo obnovovane na jinej/vetsi disk (s tim ze pak natahnout oddil, natahnout luks, natahnout filesystem - na velikost vetsiho oddilu na vetsim disku)

[- -]

Četl jsem nějaké návody k té změně velikosti:
https://unix.stackexchange.com/a/41093
https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKS#Resize_LUKS_volume

až jsem se po zmenšení ext4 v LUKS a zmenšení LUKS dostal na zmenšení samotného oddílu, ale nepokračuju dál, protože se mi to nechce zničit zadáním špatných čísel:

$ sudo parted /dev/sda
GNU Parted 3.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit                                                             
Unit?  [compact]? s                                                       
(parted) p                                                               
Error: Can't have a partition outside the disk!
Ignore/Cancel? i                                                         
Error: Can't have a partition outside the disk!
Ignore/Cancel? i                                                         
Error: Can't have the end before the start! (start sector=3054462464 length=-2098627181)
Model: ATA Samsung SSD 850 (scsi)                                         
Disk /dev/sda: 234441648s
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
(parted) q

takže jsem zkusil připojit oba disky,
sudo cryptsetup luksOpen /dev/sdc1 abc
druhý už byl připojen podle $lsblk
Zkoušel jsem ten mount s přepínačem --bind, ale byla tam chyba:
sudo mount --bind /dev/mapper/abc /mnt
mount: /mnt: mount(2) system call failed: Not a directory.
bez --bind ale fungovalo:
sudo mount /dev/mapper/abc /mnt
sudo mkdir /mnt2;sudo mount jmeno-desifrovaneho-oddilu-Noveho-Disku-podleLSBLK /mnt2

a pak tedy překopírování dat ze starého disku /mnt na /mnt2:
sudo rsync -qaHAXS /mnt/ /mnt2/

po vložení nového disku  do nového PC to nenachází cryptodisk, protože ten rsync asi přepsal grub apod. Já jsem tedy změnil UUID aby souhlasily s tím co je v boot/grub/grub.cfg:
sudo cryptsetup luksUUID /dev/sda1 --uuid newuuidHERE (a skutečně to změnilo UUID kryptodisku)
sudo tune2fs -U 6a62939e-9d02-4cd1-ad50-297d166daf23 /dev/mapper/luks-0bbfe23e-921f-46df-89a0-e299032688ef
(podle https://scriptthe.net/2016/08/24/changing-uuids-on-luks-encrypted-partitions/ )
bylo potřeba udělat kontrolu fsck přes gparted.

Problém je, že boot z disku nejde, pořád to hledá kryptodisk který není nalezen, asi ten starý. fstab UUID neobsahuje. Končí to v grub příkazové řádce.

[k3dAR]

ten bind byl opravdu POUZE pokud bys rsyncoval bezici system, resp oddil co mas jiz pripojen v / korenu ;-)
obecne: "mount --bind /dev/COKOLIV /nekam" NE, bind ma zdroj VZDY existujici mountpoint ci existujici adresar ci soubor, muzes treba udelat "cp /proc/cpuinfo /tmp; mount --bind /tmp/cpuinfo /proc/cpuinfo; nano /proc/cpuinfo # a upravit flagy pro cpu [samozrejme jen priklad, resp. pouzitelne to pamatuju jen u PentiumM ktere umelo PAE a od vyrobce mu schazel pro pae flag]

chapu tedy ze mas druhy disk, takze prozatim(?) vynechame reseni puvodniho disku a jeho oddilu...

pokud se snazis nastavit UUID pro luks ci extfs, stejny jako mel zdrojovej disk, tak NEMEJ zapojenej zdrojovej disk,
jadro by se urcite nechovalo korektne pri 2x stejne UUID

novy disk si tedy rozdelil jak?
- rozlozeni GPT
- 1 oddil EFI (a pridan v gparted priznak Boot a ESP)
- 2 oddil pro LUKS, ten si odemknul, zformatoval a rsyncem prehodil vse z odemknuteho puvodniho disku?

a zkousis boot v UEFI rezimu? nebo si novej disk udelal MBR, EFI oddil nedaval a jen si overujes zda dokazes naklonovat disk z puodniho na novej?

v obou pripadech je potreba nainstalovat Grub (v chrootu) coz si asi udelal kdyz ti to startuje, pokud tedy nestartuje Grub z puvodniho stale zapojeneho disku

cryptodisk hleda kdo? Grub? initramdisk? a jake luks uuid to hleda? to co bylo puvodni?
"sudo cryptsetup luksUUID /dev/sda1" ti zobrazi UUID to ktere si menil? to co to hleda?
v /etc/crypttab mas jake UUID pro LUKS?
v pripade ze si regeneroval initramdisk, mel si v tu chvili luks kontejner odemcenej pod STEJNYM nazvem jako mas uvedene v /etc/crypttab? (prvni sloupec) a mel si tam spravne UUID=... ? (druhej sloupec)