Dotaz: Nejsem schopen nainstalovat GRUB na sekundární disk

[Petr Fiedler]

Zdravím,

přidal jsem si do pc další disk a nainstaloval na něj pslední verzi Mintu, abych jí mohl testovat na železe. Problém je v tom, že mi na něj nejde nainstalovat GRUB, takže ten tesotvací Mint spouštím z primárního disku, který je však šifrován a tak musím pokaždé zcela zbytečně zadávat heslo. Chtěl bych si proto nainstalovat GRUB i na ten sekundární disk, ale nedaří se. Zkoušel jsem to podle jednoho návodu na netu, ale dopadlo to takto:

~$ sudo mount -t ext4 /dev/sdc1 /mnt
~$ sudo grub-install --root-directory=/mnt /dev/sdc
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

V tuto chvíli byl disk rozdělen takto:

Volné místo   4 MiB
sdc1          zbytek disku

Takže jsem to upravil takto:

Volné místo   4 MiB
sdc2        512 MiB FAT32 boot,esp
sdc1         30 GiB
Volné místo   zbytek disku

Když jsem potom zkusil aplikovat výše zmíněný postup pro instalaci GRUBu, tak to skončilo stejnou chybou. Tak jsem nabootoval ten testovací Mint a v terminálu dal:

~$ sudo grub-install

A dostal jsem tohle:

~$ sudo grub-install
grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.

S tímhle si nevím rady, protože když jsem dal:

~$ sudo grub-install /dev/sdc2

tak jsem dostal stejnou chybu.

Ještě jsem přemýšlel o chroot z primárního systému, ale na netu jsem nenašel nic, co by mě nasměrovalo.

Poraďtě prosím, jak ten GRUB nainstalovat.

Odpovědi

[Petr Fiedler]

Ještě jsem teď zkoušel v naběhlém testovacím Mintu:

sudo grub-install --target=x86_64-efi

ale zase to skončilo chybou. Něco ve smyslu, že neexistuje adresář, nebo soubor, nebo co.

[Andrej]

Neřešili jsme něco podobného už tady? Zkusím střelit od boku:

mount /dev/sdc2 /mnt
grub-install --target=x86_64-efi \
             --efi-directory=/mnt \
             --boot-directory=/mnt

V nešifrovaných případech se obvykle dává --efi-directory=/boot/efi a --boot-directory=/boot, nicméně pokud je filesystém obsahující adresář /boot šifrovaný (což dnes může být a měl by být), je třeba nainstalovat kompletní GRUB do UEFI oddílu, tj. oba adresáře budou stejné.

Pak bude samozřejmě problém s update-grub2, který je nutné obelstít například takto (což je ovšem nepříjemné při každé aktualizaci GRUBu na obou těch UEFI oddílech):

# mount /boot  # Mimochodem, neexistuje důvod mít /boot oddíl.
mkdir /boot/efi
mount /dev/sdc2 /boot/efi
ln -s efi/grub /boot/grub
update-grub2

Ještě několik poznámek:

• Zadávat heslo stačí jednou, v GRUBu. Návodů, jak se vyhnout druhému zadání hesla po nabootování kernelu, se na webu povalují asi tak desítky.
• Neexistuje důvod dělit disk na 30 GB a zbytek; disk je lepší nedělit, kromě UEFI oddílu tam, kde je potřeba.

Pak ještě k tomuto:

~$ sudo mount -t ext4 /dev/sdc1 /mnt

Uf. Pokud je instalace v začátcích, vřele bych doporučil rozumný souborový systém z tohoto desetiletí, nikoliv technologii z desetiletí minulých, která na dnešním hardwaru bude ztrácet data. Nejde o to, že by byl Ext4 z principu špatně navržený; to jistě ne. Jeho návrh ovšem pochází z dob, kdy disky měly 10 GB, ne 10 TB, a selhávaly najednou a úplně, nikoliv tak, že by vracely špatná data, atd. Takové doby jsou nenávratně pryč a Ext4 do dnešní doby nepasuje.

Jen tak na okraj, ještě bych upozornil (což asi není problém v tomto případě), že UEFI oddíl by neměl být daleko od začátku disku.

[k3dAR]

spatne ctes, on nezadave heslo zbytecne 2x (pro hlavni system naopak zadava 1x do Grub a initramfs ma poresenej ze mu odemkne LUKS systemovej i jinej datovej), zde mu slo o to, ze ma GRUB s hlavnim LUKS systemem, a zbytecne musi zadavat LUKS heslo do Grub, aby nastartoval "novy Mint" tedy druhej/testovaci/nesifrovanej system

ohledne zbytecneho opakovani "nedelit a nepouzivat ext4" napis radeji Blog pokud chces byt visionar, protoze jinak bud dostanes uzivatele do stavu ze bude mit roze$ranej celej BTRFS disk co nepujde nijak opravit, nebo te budou ignorovat

[k3dAR]

v prvni rade:
1. mas disk rozdelen GPT, ale NEmel si EFI
2. zkousis instalovat Grub-PC(i386) => Legacy, ale NEmas (pri GPT+Legacy) potrebnou BIOS partition (1MB, priznak bios_grub)

takze ujasni si a napis, zda startujes v Legacy nebo EFI rezimu, podle toho se pujde dal...
(zda v UEFI zjistis v nastartovanem systemu, ze "efibootmgr" zobrazi info a ne error)

jeste, jak se snazis instalovat Grub? pokud v tom nabehlem "novem Mintu" pres Grub hlavniho systemu, tak OK, to zohledni stavajici nastaveni Boot a Grub je Legacy nebo UEFI dle hlavniho systemu, toho se muzes drzet, ale pokud startujes USBLive, tak POZOR, ze muzes startovat v Legacy i presto ze DISK chces pak mit z UEFI, zalezi jednak zda pouzijes 64bit ISO, pak jak ho nahrajes na USB a pak co vyberes v BootMenu desky pro Boot (zda UEFI: ubuntu/usbflash/neco,nebo Legacy:USBremoveble/JmenoUSB/atd)

[Petr Fiedler]

Celé se to velmi zkomplikovalo. Nikdo neodpovídal a tak jsem se rozhodl, že si ten testovací Mint přeinstaluji a že si pohlídám, jestli skutečně zvolím jako zařízení pro instalaci zavaděče ten správný disk. V tomto případě se jedná o sdc. Takže jsem to přeinstaloval a pro instalaci GRUBu jsem zvolil sdc (Western Digital Caviar). Problém byl v tom, že když jsem po rebootu v boot menu (F12) vybral pro zavedení sdc (Western digital Caviar s testovacím Mintem), tak se objevil dialog pro zadání LUKS hesla od sda (SAMSUNG s primárním systémem). Tak jsem rebootoval a zcela nelogicky vybral "Ubuntu (Samsung)" (sda) a zavedl se testovací Mint na Western Digital Caviar (sdc). Rebootoval jsem a v BIOSu zakázal sda (SAMSUNG) a sdb (Western Digital Black zálohovací disk), v boot menu opět vybral Western Digital Caviar a zůstalo to viset na černé obrazovce s nějakými informacemi o GRUBu a tuším, že tam bylo grub> a šlo tam zadávat příkazy. Tak jsem v BIOSu zase oba disky povolil a ejhle, už jsem v boot menu neměl možnost vybrat sda s primárním systémem. Pokud jsem ale boot menu nevyvolal, tak se po zapnutí pc zavedl sda. Takže jsem z primárního systému zformátoval sdc a už mi primární systém nejde zavést. Ani když nabootuji z flešky, na které mám nainstalovaný Linux a v terminálu dám update-grub, tak to nepomůže. Mám tedy 2 otázky:

1. Jak opravit bootování sda? Jedná se o hybridní boot BIOS/EFI, šifrován LUKSem.
2. Je mi jasné, že když před instalací pokusného Mintu vypnu v BIOSu ostatní disky, tak se GRUB nainstaluje na sdc včetně nabídky GRUBu a bude to fungovat. Jde to ale pořešit, aniž by člověk musel něco vypínat v BIOSu?

[k3dAR]

kdyz nastartujes z USB a das update-grub, tak se nic na HDD/SSD nezmeni...

# odemknuti LUKS oddilu sdXY
sudo cryptsetup luksOpen /dev/sdXY sdXY_open

# pripojeni rootfs+efi
sudo mkdir -p /target
sudo mount /dev/mapper/sdXY_open /target
sudo mount /dev/sdXEFI /target/boot/efi

# priprava chroot
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
sudo chroot /target

# v chrootu poreseni Grubu pro BIOS (i386-pc) a EFI(x86_64)
grub-install --target=i386-pc /dev/sdX
grub-install --target=x86_64-efi /dev/sdX
update-grub
exit

# uklid
sudo umount /target/{boot/efi,dev/pts,dev,proc,sys}
sudo umount /target


# reboot
sudo reboot

[k3dAR]

ad otazka2: muzes totozne, s tim ze instalaci bys pustil pretim BEZ instalovani zavadece(v nabidce rozdeleni disku ji pak ani nezobrazi a neresi):

ubiquity --no-bootloader

[Petr Fiedler]

Ahoj Keďo,

zasekl jsem se hned na třetím příkazu (připojení rootfs):

~$ sudo cryptsetup luksOpen /dev/sda3 sda3_open
Zadejte heslo pro /dev/sda3:
~$ sudo mkdir -p /target
~$ sudo mount /dev/mapper/sda3_open /target
mount: /target: neznámý typ systému souborů „LVM2_member“.

Co teď prosím tě?

[k3dAR]

jasne, nad LUKS mas LVM, takze po odemceni cryptsetupem, misto "mount ... sda3_open /target":

# aktivaci LVM (mozna neni treba, ale neuskodi kdyz pustis i kdyz by aktivovane bylo(pripadne muzes overit zda v /dev/mapper/ vidis sve vgjmeno-lvjmena (= to by znamenalo ze je aktivovane)
sudo vgchange -ay
sudo mount /dev/mapper/lvm-rootfs /target

(predpokladam ze je to instalace z meho "luksuntu" skriptu, pokud ne, tak jmeno lvm-rootfs nahrad za sve vgjmeno-lvjmeno_pro_rootfs

[Petr Fiedler]

Po aplikaci:

sudo vgchange -ay
sudo mount /dev/mapper/lvm-rootfs /target

pak vše prošlo.
Jen pro jistotu se zeptám. U:

sudo mount /dev/sdXEFI /target/boot/efi

jsem to změnil na:

sudo mount /dev/sda2 /target/boot/efi

kdy sda2 je 512 MiB EFI oddíl. Správně?

Po rebootu jsem pomocí F12 vyvolal boot menu a v něm byly 2 stejné položky - Ubuntu (Samsung 500 GB). To je to SSD, na kterém je primární oddíl. Ať jsem ale vybral kteroukoliv z nich, skončilo to na tomhle:

error: no such cryptodisk found.
error: disk `lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx` not found.
Entering rescue mode...
grub rescue> _

Víš co s tím. Tak nějak tuším, že budu muset připojit lv a někam vložit to lvmid. Ale kam, to je tedy otázka?

[Petr Fiedler]

Edit: To je to SSD, na kterém je primární systém.

A ještě doplním, že jsem k instalaci použil ten tvůj skript.

[k3dAR]

ad sdXEFI - pochopil si spravne za co nahradit
stejnej postup (jen vynechas vgchange, resp. pujdes podle puvodniho postupu, pokud na druhem disku mas system bez LVM)

ohledne erroru - zkus v tom grub rescue rucne:

cryptomount (hd0,gpt3)
set root=(lvm/lvm-rootfs)
linux /vmlinuz root=/dev/mapper/lvm-rootfs ro
initrd /initrd.img
boot

(je to na miru tve instalaci, prvni(hd0) disk, luks na gpt rozdeleni 3 oddil(gpt3), jmeno VG lvm, jmeno pro rootfs rootfs (lvm-rootfs))
pokud toto rucne projde, zkus to(v grub_rescue) znovu, ale misto cryptomount (hd0,gpt3) zadas pouzijes radek ze sveho grub.cfg kterej zacina cryptomount -u tedy bude to:

cryptomount -u tvojeuuidpro3oddil

pokud toto nepujde, over zda to tvojeuuidpro3oddil odpovida realne uuid tveho LUKS oddilu:

blkid -s UUID /dev/sda3

[Petr Fiedler]

error: no such cryptodisk found.
error: disk `lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx` not found.
Entering rescue mode...
grub rescue> cryptomount (hd0,gpt3)
Attempting to decrypt master key...
Enter passphrase for hd0,gpt3 (čísla&písmena):
Slot 0 opened
grub rescue> set root=(lvm/lvm-rootfs)
grub rescue> linux /vmlinuz root=/dev/mapper/lvm-rootfs ro
Unknown command `linux`.
grub rescue> _

[k3dAR]

aha, sorry, neuvedomil sem si ze ten postup plati pro "grub" commandline a NE pro "grub rescue"
ale je videt ze odemceni LUKS probehlo ok(takze grub luks moduly i prikaz pro odemceni mas), takze by melo jit natahnout menu z grub.cfg pokud je ok:

cryptomount (hd0,gpt3)
insmod normal
normal

a dale pokracuj od "pokud toto rucne projde"
predpokladam tedy ze budes mit spatne v grub.cfg to UUID a ze rucne to dle toho UUID(v grub.cfg, radek: cryptomount -u ...) odemknout nepujde, zkus napis...

[k3dAR]

resp. kdyz to pres "insmod normal, normal" zobrazi menu a system nastartuje, zkus (nejdriv zazalohuj pro info stavajici /boot/grub/grub.cfg): "sudo update-grub" a reboot

[Petr Fiedler]

Zřejmě špatné UUID:

error: no such cryptodisk found.
error: disk `lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx` not found.
Entering rescue mode...
grub rescue> cryptomount (hd0,gpt3)
Attempting to decrypt master key...
Enter passphrase for hd0,gpt3 (čísla&písmena):
Slot 0 opened
grub rescue> insmod normal
error: disk `lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx` not found.
grub rescue> _

Takže asi chroot, že?

[k3dAR]

v chroot si update-grub pro ssd uz delal ne?
nahod Live:

sudo vgchange
sudo vgdisplay lvm | grep UUID
sudo lvdisplay lvm/rootfs | grep UUID

to co ti hlasi grub rescue lvmid/uuid_pro_vg/uuid_pro_lv by melo odpovidat vystupu z tech^^ prikazu

pripadne sem dej svuj /boot/grub/grub.cfg(z SSD s hlavnim OS) a vystup "sudo blkid"

[k3dAR]

a vystup "sudo lvdisplay" a "sudo vgdisplay"

[Petr Fiedler]

Tak špatným UUID to není.

blkid -s UUID /dev/sda3

se shoduje s

Enter passphrase for hd0,gpt3 (UUID):

prostě

error: disk `lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx` not found.

[k3dAR]

divne ze to ale hlasi "error: no such cryptodisk found." jde ti rucne v grub_rescue odemknout pres

cryptomount -u to_UUID_pro_sda3

kdyz pak das

set root=(lvm/lvm-rootfs)

zobrazi se ti obsah rootfs pomoci:

ls /

?

[Petr Fiedler]

Špatně jsem tě pochopil s tím grub.cfg Tam mám úplně jiné UUID, než ke kterému zadávám heslo v grub rescue. Chvíli vydrž. Pozorně si teď přečtu tvoje reakce a odpovím ti.

[k3dAR]

jeste me napadla drobnost(?), pokud novej Mint nahodou pouziva uz nejnovejsi verzi Grub(jako napr. Debian10), tak ten si dava miniaturni grub.cfg primo do EFI oddilu, mozna ti tam zustal a ted to blbne, zkouknu... verze Grub pred toutou zmenou (napr. Debian9, *buntu18.04) pouzivali "inkektovani" infa o LUKS UUID primo do EFI binarky, nikoliv oddelenej grub.cfg soubor v EFI oddilu...

[k3dAR]

k otazce proc druhejOS se "nacpal do prvniho Grub" i kdyz si vybral pro zavadec /dev/sdDRUHEJDISK, tim ze si puvodne ve vypisu nemel EFI, tak se pouzilo EFI prvniho disku, ted kdyz to zkousim ve virtualu doinstalovat Mint na druhej disk, s tim ze na prvnim mam LUKS-LVM-Debian9, tak me to trklo, tedy predpokaldam ze spravne mas (zatim)predpokladam:

- rozdleeni disku - zvolit neco jineho
- na sdDRUHEJDISK - vytvorit tabulku oddilu
- na sdDRUHEJDISK - vytvorit oddil EFI, 512MB
- na sdDRUHEJDISK - vytvorit oddil ext4, zbytek
- vybrat instalaci zavadece sdDRUHEJDISK

[Petr Fiedler]

Tak tohle je naprosto klíčová věc, Keďo. Takhle jsem to právě neudělal. A já si říkal: "Přece není možné, aby se to chovalo takhle hrozně"

Velké díky!

[Petr Fiedler]

Tak tohle je naprosto klíčová věc, Keďo. Takhle jsem to právě neudělal.

Blouzním. Udělal. Je to hned v dotazu.

[k3dAR]

blouznis v dotazu si psal ze si EFI pri instalaci nevytvoril, ale jak sem psal pak, i kdyby jo a vse ostatni, tak stejne je v instalatoru bug

[Petr Fiedler]

Máš pravdu. EFI jsem vytvořil dodatečně pro doinstalaci GRUBu.

[k3dAR]

tak uvaha se nepotvrdila, protoze prestoze sem v "rozdeleni-neco jineho" pripravil EFI na druhemdisku a zaroven sem EFI na prvnim disku vybral "nepouzivat tuto oblast" a zaroven sem vybral pro instalaci Grub druhejdisk:
- jednak na konci instlace oznameni ze se Grub-Efi nepodarilo nainstalovat (balicek pritom tam je)
- zaroven vidim ze si instalator do /target/boot/efi pripojil EFI z prvniho disku
=> instalator ma proste bugy, nepocita s tim ze ma pouzit EFI jine, ignoruje ze nema pouzivat EFI na prvni disku, atd...

ale kdyz necham zobrazenej ten "grub nepodarilo error" (tedy zustane v /target pripoejej rootfs disku2, sys, proc, dev) a dam:

sudo chroot /target
umount /boot/efi
mount /dev/sdb1 /boot/efi
grub-install /dev/sdb
update-grub
exit
# odtuknu error instalatoru

tak takto rucne nainstaluju spravnej Grub(-EFI) do spravneho EFI(druhejDisk) na spravnem(druhem) disku...
zaroven pak funguje, ze pri startu kdyz vyberu z Disku1(LUKS), tak se zepta na LUKS heslo, zobrazi Grub a nastartuje Debian
kdyz vyberu z Disk2(BezLUKS), tak se na LUKS heslo nepta, nezobrazi Grub(protoze *buntu/Mint ho schovava kdyz je jen 1 OS(a update-grub nrenasel Debian kdyz byl na zamcenem LUKS Disk1) a nastartuje rovnou Mint

[Petr Fiedler]

ale kdyz necham zobrazenej ten "grub nepodarilo error" (tedy zustane v /target pripoejej rootfs disku2, sys, proc, dev) a dam:

To jako necháš zobrazenou tu chybovou hlášku, zmáčkneš alt+F2 pro přepnutí se do konzoly a příkazy zadáš odtam? Nebo ctrl+alt+t pro terminál, nebo jak?

[k3dAR]

nevim jak tobe, ale ja kdyz pustil Mint19-Xfce-64bit, v rezimu UEFI (urcujes to ty zda vyberes v BootMenu desky UEFI:CDROM/USB, nebo (Legacy/BIOS)CDROM/USB), tak se zobrazila nabidka Grub (ta se pouziva z ISO pro UEFI rezim) kde neni Instalovat/Vyskouset, ale jen "Pustit"/"Pustit v nouzi", takze kdyz jen odtuknu, tak se pusti normalne Desktop kde instalaci vyvolam tuknutim na Instalovat ikonu na plose... (v Legacy rezimu zalezelo jestli si vybral Instalovat (to si pak plochu nemel) nebo Vyzkouset(to si pak mel plochu a ikonu Instalovat na plose)...
takze pak normalne pustim terminal ze "startmenu" kdyz mi instalator ukazal error, jinak samozrejme muzes odtuknout instalator, on se ukonci, odpoji /target a ty pak rucne pripojis do target rootfs, efi oddil, dev, dev/pts, proc, sys a udelas chroot (viz ten chroot postup vejs)

[Petr Fiedler]

Jasně, díky.

[Petr Fiedler]

Ahoj Keďo.

... s tim ze na prvnim mam LUKS-LVM-Debian9 ...

Koukám, že si hraješ s Debianem. Jestli si vzpomínáš, tak jsem tu před časem řešil přechod na něj, ale krachlo to na tom, že jsme nemohli kvůli bugu použít tvoje Luksuntu. Podařilo se ti nainstalovat Debian i s NEodděleným šifrovaným /boot?

A jak se ti vlastně Debian líbí? Předpokládám, že na něm máš Xfce. IMHO by to mělo být celé lepší, než Xubuntu. Co říkáš?

Shodou okolností jsem teď zkoušel pár dister, protože nejsem úplně spokojen se Skořicí (havárie, zamrzání, blikání panelu). Zkusil jsem i tvoje oblíbené Xubuntu 18.04. Vlastně je mám stále nainstalováno. Z počátku jsem z Xubuntu byl doslova nadšený, ale bugy jsou prostě všude. Když jsem třeba nastavoval velikost ukazatele, tak se při nějaké hodnotě zvětšil, pak klikáš a nic a pak se zvětší až na hodnotě 41. Problém ale je, že po rebootu je ukazatel zase malý. Když pak jdeš do nastavení a navýšíš na 42, tak se zase zvětší. Ale zase to po rebootu nedrží. Dokonce pak stačí ze 42 snížit na 41 a zase se zvětší. Taky se ti to tak chová, nebo došlo k chybě při instalaci jen u mě?

[k3dAR]

to byl jen Debian pro testovaci ucely ve virtualu (nepocitam Debian sem pouzival na zacatku stoleti :)
instalaci Debian9+LUKS vcetne /boot mam ve virtualu take, resil sem to jako zkousku pro nekoho co mu nesel (v diskuzi jsou jeste nejake me poznatky z instalace) postup popsanej v clanku na rootu, k tomu pak druha diskuze(tam sem posilal i "video howto" vcetne zkousky Debian10+LUKS kde bylo potreba udelan jeste neco jinak...

kazdopadne uz si nepamatuju co byl u Tebe problem s Debianem, resp. matne ze luksuntu pousti instalator kterej v Debianu neni a/nebo ze nema funkcni Live instalator, ale jen SamostatnejInstaltor, takze "neslo" poustet skript

[Petr Fiedler]

kazdopadne uz si nepamatuju co byl u Tebe problem s Debianem ...

Šlo o tohle.

[k3dAR]

jo tak sem si vzpominal dobre to pokud vim stale doresene nemaji, mozna by sel poustet (jinej/upravenej "luksbian" skript) pri instalaci v textovem rezimu v jine konzoli, udelal by pripravu, pak prepnout zpet do instlatoru (skript by cekal na "press space") pokracovat v instalaci a po dokonceni nedat reboot ale prepnout na konzoli se skriptem a dokoncit, tedy podobne jako to vlastne resi ten clanek, jen ty prikazy by se nepsali, ale poustel by je skript...

[Petr Fiedler]

Budu ti vděčný, když před vypnutím nb nacvakáš velikost ukazatele myši na např. 42 a až si pak zapneš nb, tak mi sem napíšeš, jestli ti to v Xubuntu 18.04 drží, nebo ne.

[k3dAR]

pouzivam sice Xubuntu 18.04 ale mam pridane vyvojove verze Xfce pres (nekolik) Xubuntu-Dev PPA, chova se to divne, mys po vypnuti/rebootu kdyz sem nad plochou je nezmenena (jak velikost, tak v pripade ze sem vybral jine mys tema (tre ba to cervene), tak i vyvhozi barva/tema) , ale kdyz pustim nejakej program a najedu nad jeho okno mys je stejna (velikost i barva) co sem pred rebootem vybral...
tzn. vypada to na bug Xfce soucasti co zobrazuje plochu (spravce oken xfwm4), ze se pousti driv nez se inicializuje mysi konfigurace, overil sem to i tak, ze kdyz v prave nabehlem systemu dam xfwm4 pustit znovu, tak mys nastaveni si nacte to moje a i nad plochou se zobrazuje spravne...

xfwm4 --replace &

takze jako workaround by v nejhorsim slo nastavit v "Relace a spousteni" pusteni tohoto prikazu... nezkousel sem...

jinak ted koukam ze kdyz v bezicim vratim velikost a tema na vychozi, tak se zmeni pro Plochu, pro Terminal, Kalkulacku, ale treba pro Vivaldi je stale velka cervena (nejspis dokud ho nezavru a nepustim znovu

[k3dAR]

kdyz sem Vivaldi vypnul/zapnul mys uz ma ok, totez delal Skype (nevim zda to souvisi, ze oboje je postavene (v podstate) nad Chromium)...

pak sem to zkusil jeste v (KVM) virtualu, take Xubuntu 18.04 ale BEZ tech PPA, tzn. melo by to byt jako mas ty, tam se mys po restartu a zapnuti chova ok, zustava velikost i barva i pro Plochu, nevim zda muze mit vliv beh ve virtualu, jednak v nem jsou "doplnky pro virtual" a pak ze neni fyzicka mys, ale neni to tak ze by pouzival mys hostitele, protoze v tom mam barvu/velikost ted jinou a kdyz prepnu na virtual prepne se mys na to co ve virtualnim Xubuntu nastavene je...

[Petr Fiedler]

Zkusím to v tom "Relace a spouštění".
Díky moc!

[Petr Fiedler]

xfwm4 --replace &

takze jako workaround by v nejhorsim slo nastavit v "Relace a spousteni" pusteni tohoto prikazu...

Zabralo to Keďo

[k3dAR]

neni to sice uplne ciste reseni, ale neni to ani moc prasarna, ten parametr --replace je vlasnost toho xfwm4, pouze se bezneji pouziva kdyz bys jine bezici WM (WindowsManager=SpravceOken) chtel nahradit za behu timto... ale tak hlavne ze to zabralo

jake dalsi bugy v Xubuntu vidis?

[Petr Fiedler]

jake dalsi bugy v Xubuntu vidis?

Nejsem si jistý, jestli jde o bug, ale asi ano. Já používám motiv "Adwaita-Dark". Takže pozadí oken je tmavé a písmo je světlé. K mému překvapení a k mé radosti bylo tohle téma v Xubuntu hned po instalaci, takže jsem si je nastavil. Nefungovalo to ale u aplikace "qshutdown" a možná by to zlobilo i jinde. Nevím, moc jsem toho nezkoušel. Jak bude ale čas, tak se na to chci pořádně podívat. V Mintu má ale qshutdown tmavé pozadí jako ostatní okna.

Mimochodem, nešlo by tam dostat nějaké ještě tmavší téma? Já tu Adwaitu-Dark používám i na Mintu, ale raději bych měl pozadí oken úplně černé. Šlo by to nějak pořešit? Já jsem za ty roky nic černého nenašel, ale možná by to šlo odladit v kofiguráku té Adwaity, ne? Klidně to zkusím sám, jen mi řekni, jestli to má nějaký smysl se s tím lopotit, abych tomu nevěnoval čas zbytečně.

[k3dAR]

zkus tohle, je to sice starsi, tak nevim jak se kde bude chovat, ale neoficialni Adwaita-Black
adresar z archivu nahrajes do $HOME/.local/share/themes/ upravovat muzes zkusit, jsou to textove soubory, pozor ze jsou "dvojmo" jedno je tema pro GTK2(starsi programy) druhe GTK3(novejsi programy)

ze qshutdown nerespektuje tema urcite nevidim jako chybu Xubuntu/Xfce navic Xfce (Gnome, Mate, Cinnamon) jsou GTK prostredi a qshutdown je Qt aplikace, tzn. jednak je to zbytecne(zkusil bych spis pouzit GTK proram pro autoshutdown), druhak je potreba doinstalovat i Qt tema a Qt nastavovas pro GTK prostredi:

# Qt tema
sudo apt install adwaita-qt

# Qt5 nastavovac (podle zavislosti baliku je qshutdown nad Qt5)
sudo apt install qt5ct

# Qt4 nastavovac (kdyby neco...)
sudo apt install qt4-qtconfig

ten Qt5 nastavovac je potreba pustit z terminalu takto (kvuli nastaveni te promene):

QT_QPA_PLATFORMTHEME="qt5ct" qt5ct

[k3dAR]

EDIT: vse je jinak, nebo jednodusejc, vydrz nez to dooverim, Qt5 aplikace se pak bude menit tema podle toho co vyberes v normalnim nastaveni/vzhled

[k3dAR]

takze aby Qt aplikace (v tvem pripade qshutdown) sdilela nastaveni tematu (GTK) prostredi, staci pouze:

sudo apt install qt5-style-plugins

[Petr Fiedler]

Tak to je super, díky.

Ještě mi prosím napiš, jak se ti jeví Xfce co do stability?

[k3dAR]

naprosto bezproblemu, pouzivam jak vychozi Xfce z Xubuntu 18.04 (na sekundarnim desktopu a vsude jinde) a vyvojovou/nestabilni/experimentalni Xfce balicky (z Xubuntu-Dev PPA) v Xubuntu 18.04 na primarnim/kazdejden stroji...
a i s tim z PPA nemam zadnej problem s nestabilitou...

[Petr Fiedler]

To je skvělé. Ponechám si tedy Xubuntu nainstalované a pokusím se je odladit a budu je zkoumat a sledovat. Pomohl bys prosím s odladěním? Když bych si s něčím nevěděl rady, nebo to nedohledal, tak bych se zeptal v tématu, které bych na to založil. Pokud bych byl s Xubuntu spokojen, tak bych na něj přešel. Už kdysi se mi líbilo, protože hned po instalaci v něm byla funkční lupa. Stačilo zmáčknout levý ALT a točit kolečkem myši. Tehdy ale nešla (neuměl jsem a nezkoumal) nastavit velikost ukazatele, což byl problém. Lupa vše krásně zvětšila, ale neviděls kurzor. To bylo k ničemu. Teď už to pořešit jde, takže pohoda ...

[k3dAR]

s odladenim s Xfce urcite comuzu-pomuzu

prvni co me napada, klavesa Super(Windows) aby zobrazovala startmenu:

sudo apt xcape

a v Relace&Spusteni pridat "Xcape" s prikazem(vcetne tech uvozovek):

xcape -e "Super_L=Control_L|Escape"

[Petr Fiedler]

Paráda, díky!

S tou klávesou jsi na to kápl. Zrovna tohle mi hodně vadilo, že se to menu nezobrazovalo.

[Petr Fiedler]

jake dalsi bugy v Xubuntu vidis?

Vzpomněl jsem si na jeden bug, který se tě netýká, ale zmíním jej. Když máš v *ubuntu/Mintu zapnutý odečítač Orca a máš nastaveno, aby odečítal už při startu na přihlašovací obrazovce, tak se při startu systému z repráků ozývá takové škrčení. Řešením je:

# V terminalu:
sudo editor /etc/pulse/default.pa

# Vyhledat retezec:
load-module module-udev-detect

# A dopsat za nej:
tsched=0

Přímo tobě to bude asi k ničemu, ale možná tím někdy někomu pomůžeš

[k3dAR]

ok, ale to je koukam letitej bug v PulseAudio, tedy nesouvisejici s Xfce co mas dalsiho k Xfce?

[Petr Fiedler]

Vím, že je letitý. A vím, že nesouvisí s Xfce, ale s PA. Ptal ses ale na bugy v Xubuntu. I když teď si uvědomuju, že tě spíš zajímalo Xfce. Já si je prohlížel jen opravdu ktátkou dobu. Asi jen 1 hodinu. Narazil jsem jen na to s tou myší včetně toho, že když přidáváš (asi pixely), tak se ukazatel nezvětšuje postupně a najednou se zvětší hodně. Ale to mi nevadí. Další bugy jsem neviděl. Spíš mě tam zarážely určité vlastnosti jako např. že se neukazovalo startmenu po stisknutí Super. Pak mi ještě nesedělo něco ve správci souborů, ale teď si nevybavuji co. Ale taky šlo spíše o absenci nějaké vlastnosti. Hodlám si teď ke Xubuntu ještě na zkoušku nainstalovat Debian s Xfce (Btrfs, LUKS, LVM) a hodlám si s tím vším hrát. Tak pokud něco, co bude souviset s Xfce objevím, tak ti určitě dám vědět

[k3dAR]

slo mi spis o bufy prostredi, s kterejma bych zkusil poradit, ale samozrejme kdyz budes mit obecnej problem take napis, jen mozna v nejakem novem k tomu urcenem vlakne

nevim jestli je dobrej napad poznavat Xfce s Debianem... neni tam moc odladene, je tam starsi verze nez v Xubuntu 18.04, nejde (pokud vim) tam snadno pripadne pridat vyvojove Xfce (jako v Xubuntu pres PPA), spis bych bejt tebou to Xubuntu 18.04 co uz mas zacal zkoumat

[k3dAR]

edit: nevim kde se vzalo bufy? myslel sem Xfce

[Petr Fiedler]

Edit Tvoho Editu:

Myslel jsi bugy

[Petr Fiedler]

No a edit mého editu:

Tvoho=Tvého

[k3dAR]

jo bugy davaj vetsi smysl i toho preklepu )

[Petr Fiedler]

Jo, jasně. Včera jsem psal, že bych na to založil nové téma. Tohle už je zase pěknej mrakodrap

Dám na tebe a od toho Debianu upustím.

[k3dAR]

nechci te obecne odrazovat od Debianu, je to vynikajici distro a *buntu/Mint/atd na nem prave proto stavej, ale zrovna u Xfce vim ze kdyz nahodim Debian trva mi nez ho doodladim do stavu Xubuntu po instalaci a nic mi to navic neprinasi... takze pokud seznamit z Xfce, je proste Xubuntu idealni pro jeho odladenost (navic nekolik vyvojaru Xfce jsou zaroven vyvojari Xubuntu), a kdyz se ti zalibi a zacnes ho pouzivat budes uz znat co a jak a tak treba pak zkusis Debian10+Xfce :)

[Petr Fiedler]

No, já jsem právě nevěděl, jaký grub.cfg myslíš a tak jsem si připojil EFI oddíl na sda:

sudo mount /dev/sda2 /media/user

a v /media/user mám:

/EFI/Ubuntu/grub.cfg

Tohle je v tom grub.cfg:

search.fs_uuid f9c53f3f-cffb-490b-bfde-c53d7336e331 root hd2,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Výstupy se shodují s tím, co mi hlásí grub rescue:

sudo vgdisplay lvm | grep UUID
sudo lvdisplay lvm/rootfs | grep UUID

pripadne sem dej svuj /boot/grub/grub.cfg(z SSD s hlavnim OS)

Jak se k tomu mám dostat?

~$ blkid
/dev/mapper/luks: UUID="AuCsdg-hIah-gdbJ-0SB2-TckA-WfVB-ZE8equ" TYPE="LVM2_member"
/dev/mapper/lvm-rootfs: LABEL="rootfs" UUID="1d861095-d4e1-42f5-a5c2-733868a31bb4" TYPE="ext4"
/dev/sda2: LABEL="EFI" UUID="21D3-E236" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="e9650f9e-0d34-44e5-86d4-3a6b99f4f3d4"
/dev/sda3: UUID="6ad97f1a-12b8-4381-93a1-ae698dc56773" TYPE="crypto_LUKS" PARTLABEL="LUKS" PARTUUID="600bfa06-8464-4e88-8b8e-f8dadf000c06"
/dev/sda4: UUID="a893b32c-22d2-4f57-8040-256cabd37512" TYPE="crypto_LUKS" PARTLABEL="data_evo" PARTUUID="be0d1096-8891-4ab8-97a8-fd1ed6d411b3"
/dev/sdb1: UUID="529ED27F9ED25B55" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="03026594-9ad9-4cec-93b8-cc3e2021ee87"
/dev/sdb2: UUID="AEDA-5DC7" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="900eda82-aac5-4521-84c4-f548f02b7880"
/dev/sdb5: UUID="53265bf0-873f-48a0-94a3-4580420426f0" TYPE="crypto_LUKS" PARTLABEL="wd_black" PARTUUID="17384e43-91ce-4aa2-a06b-f941501bb3cf"
/dev/sdc1: UUID="00d856b9-8b25-4930-ac4f-51b8b5d57f78" TYPE="ext4" PARTUUID="8c7550b7-de0d-4f33-8205-1d02649b6bc2"
/dev/sdd2: LABEL="EFI" UUID="D96F-3DF3" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="e2b4a4ef-cff7-4513-87a0-dd689077741e"
/dev/sdd3: UUID="37dbe1df-b888-46f0-81c2-76991bf9adf7" TYPE="crypto_LUKS" PARTLABEL="LUKS" PARTUUID="5d66d54a-d0a5-4064-a5ec-2890d62ebbae"

~$ sudo vgdisplay
  --- Volume group ---
  VG Name               lvm
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               29,33 GiB
  PE Size               4,00 MiB
  Total PE              7509
  Alloc PE / Size       7509 / 29,33 GiB
  Free  PE / Size       0 / 0   
  VG UUID               LiJYd0-lEWD-Kim8-jOC4-Ej3K-7x8L-u07cXR

~$ sudo lvdisplay
  --- Logical volume ---
  LV Path                /dev/lvm/rootfs
  LV Name                rootfs
  VG Name                lvm
  LV UUID                kGS5q3-mTyZ-xUXO-2rij-ooEu-EKsP-YGIOzg
  LV Write Access        read/write
  LV Creation host, time mint, 2019-02-16 12:01:42 +0100
  LV Status              available
  # open                 1
  LV Size                29,33 GiB
  Current LE             7509
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

[k3dAR]

aha, takze jo novej Mint ma novej Grub co to resi takto, a tim ze se vecpal na EFI prvniho disku se ti ho ASI snazi natahnout i Grub EFI pro prvni disk... takze smaz na SSD v EFI oddilu soubor /EFI/Ubuntu/grub.cfg
bud to bude stacit(pokud na SSD je ted spravnej Grub EFI z Mintu na SSD disku), nebo si zopakni kolecko v chrootu na SSD preinstalaci Grubu a regeneraci grub.cfg

[k3dAR]

btw: v tom grub.cfg to nastavuje zakladni koren pro grub radkem:

search.fs_uuid f9c53f3f-cffb-490b-bfde-c53d7336e331 root hd2,gpt1

na nesifrovanej prvni oddil druhehoos(tretihodisku), kterej tim ze si mezitim preinstaloval uz neexistuje, proto to prestalo fungovat, ale pretim to startovalo druhejos i kdyz si vybral bootmenu:diskprvni

[Petr Fiedler]

Smazat grub.cfg nepomohlo. Tak jsem si dal ještě jedno kolečko a skončil jsem v grub rescue

[Petr Fiedler]

Rád bych to zkusil, ale nevím, jaké UUID mám použít. To z blkid souhlasí s tím, které se zobrazí při zadávání hesla pro odemčení LUKS. Ale liší se s tím, které bylo v /dev/sda2/EFI/Ubuntu/grub.cfg. A ten soubor už nemám. Je smazaný.

[Petr Fiedler]

divne ze to ale hlasi "error: no such cryptodisk found." jde ti rucne v grub_rescue odemknout pres

cryptomount -u to_UUID_pro_sda3

kdyz pak das

set root=(lvm/lvm-rootfs)

zobrazi se ti obsah rootfs pomoci:

ls /

?

S tím UUID mi to ručně odemknout jde a ls / vypíše obsah kořene.

[k3dAR]

divne, ze pak nejde "insmod normal" to by melo natahnout grub moduly a grub.cfg z /boot, resp. z cestu nastavene v hodnote prefix, v grub rescue dej:

set

zobrazi to pro prefix: (lvmid/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx) + na konci /boot/grub ?

pokud ne zkus:

set prefix=(lvm/lvm-rootfs)/boot/grub
# pak vylistovat tuto promenou, melo by zobrazit obsah adresare /boot/grub/ s (mimojine) grub.cfg
ls $prefix
# pokud vylistovalo spravne, opet zkus natahnout modul normal
insmod normal
# a pokud nebude erorr, tak nahodit menu
normal

[k3dAR]

jeste k tomu grub.cfg z /boot/grub ssd... ziskas to tak, ze v live po odemceni luks a pripojeni rootfs, to vykopirujes na 99% si myslim ze tam mas proste spatne UUID na radku s cryptomount -u, to by presne odpovidalo tomu "error: no such cryptodisk found"

[Petr Fiedler]

Tak jsem zeditoval grub.cfg na SSDčku. Místo UUID pro sda3 tam bylo UUID flešky sdd3. Nicméně po rebootu jsem skončil v grub rescue. Co teď?

PS: pomlčky v tom UUID jsem v grub.cfg smazal.

[k3dAR]

tzn. ze se spatne delal chroot => ted udelat spravne chroot
predpokladam ze USB flash mas take sifrovanou, take pres luksbuntu skript, tzn. ze take lvm-rootfs, pak se nejspis nenahodi LVM z SSD spravne, protoze totozne nazvy LVM/VG/LV jsou uz z Flash, kdyz nahodis flash co ti ukaze:

sudo pvscan
sudo vgscan
sudo lvscan

nevim jak se to chova kdyz jsou stejne, tusim sem to uz nedavne (snad i pro tebe?) zjistoval ale nepamatuju se :)
mozna ted budes mit nejjednodusi, nastartovat USBFlash s cistym/nesifrovanym Live Mintem a udelas chroot a budes mit jistotu(?) ze se provede opravdu s SSD a opravis si hlavni system...

[k3dAR]

jde o to ze si sice zmenil rucne na SSD v grub.cfg UUID pro SSD oddil s LUKS, ale zustalo tam lvmid s UUID pro VG/LV na Flash, nez to rucne dohledavat a prepisovat, proto radim spravnej chroot, kde update-grub to musi udelat sam spravne

[Petr Fiedler]

~$ sudo pvscan
  PV /dev/mapper/luks   VG lvm             lvm2 [29,33 GiB / 0    free]
  Total: 1 [29,33 GiB] / in use: 1 [29,33 GiB] / in no VG: 0 [0   ]
~$ sudo vgscan
  Reading volume groups from cache.
  Found volume group "lvm" using metadata type lvm2
~$ sudo lvscan
  ACTIVE            '/dev/lvm/rootfs' [29,33 GiB] inherit

[k3dAR]

~30GB mas co SSD nebo USBFlash, predpokladam USBFlash, takze plati co sem psal, tim ze jsou stejne jmena LVM/VG/LV mas aktivni jen LVM na USBFlash a pro chroot na SSD je potreba nahodit LiveUSB bez sifrovani/LVM...
(mohl bys samozrejme zmenit u USBFlash jmeno VG a LV na USBFlash, zmenit fstab, pregenerovat grub.cfg a initramfs, mozna jeste neco co mi ted vypadlo ale porad plati ze jednodusi budes mit pouzit obyc LiveUSB)

[Petr Fiedler]

Jen pro tvou informaci: 3O GB je šifrovaná fleška a SSD má 500 GB.

[k3dAR]

ok a ted kdyz uz mas SSD opravene, postup jak zmenit LVM VG jmeno na USBFlash (pretim sem tim nechtel komplikovat opravu SSD):
nastartujes z USBFlash (sice by nemelo byt treba, kdyz vime ze se USB vetrelo, ale radeji s odpojenym SSD (nebo na jinem HW))

# prejmenovani VG puvodniho jmena lvm na nove VG jmeno usb
sudo vgrename lvm usb

# rucne prepises radky s lvm-lvjmena (rootfs, home, var, swap) na usb-lvjmena
sudo mc(nebo_tvuj_oblibenej_editor) /etc/fstab

# pregenerovani grub.cfg
sudo update-grub

# pregenerovani initramfs (mozne neni treba, ale nic tim nezkazis)
sudo update-initramfs -k all -u

v /etc/crypttab menit nic nemusis, tam to mas jednak podle UUID a druhak je tam sdXY s LUKS tedy nezavisle na LVM/VG/LV
snad sem na nic nezapomel, vyzekousej...

[k3dAR]

pro jistotu tohle ^^^ NEdelas v chroot ale normalne, jen pustis terminal, tim ze to mas nastartovane z USBFlash, chroot je jen kdyz se chces "prepnout" do jineho rootfs(/, korene, systemu) nez mas nastartovanej...

[Petr Fiedler]

Chyba:

~$ sudo vgrename lvm usb
   Volume group "lvm" successfully renamed to "usb"
~$ sudo nano /etc/fstab 
~$ sudo update-grub
   /usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/lvm-rootfs'.

[k3dAR]

a zmenil si jak sem psal /etc/fstab prepanim lvm-rootfs => usb-rootfs (resp. i pro pripadne home, var, swap atd) ?

[Petr Fiedler]

Ano.

[k3dAR]

a mel si to nastartovane z te USBFlash kterou oopravujes s (radeji) odpojenym kde mas take z luksbuntu instalaci? (tedy nespolehat ze USB co startuje si to stavajici LVM jmeno opravu/naplno privlastni)

[k3dAR]

jen bacha, pokud to mas jeste nabehle a budes restartovat prejmenuj zpet z usb na lvm, zmen zpatky fstab a pust update-grub, jinak by tak USBFlash nenabehla a musel bys to domenit z jineho systemu v chrootu do odemcene usbflash

[Petr Fiedler]

To jsem si uvědomil a udělal ještě dřív, než jsi to napsal Tedy bez update-grub, protože když se předtím neprovedl, tak jsemm usoudil, že to nebude třeba. Každopádně teď to Keďo můžeme nechat být. Kdybych se zase v něčem rýpal, tak si to pohlídám a když tak chroot, Clonezilla, nebo ty A v budoucnu při přeinstalaci mám skript který to řeší, takže pohodička

[Petr Fiedler]

Ano. Napřed jsem v BIOSu vypnul primární SSD a pak jsem nahodil tu flešku a vše prováděl v systému, který je na ní nainstalován. V /etc/fstab jsem měl pouze řádek s lvm-rootfs, který jsem upravil na usb-rootfs a uložil. Pak při update-grub to vypsalo tu chybu. Nemělo náhodou místo vgrename být lvrename?

[k3dAR]

vgrename je urcite ok, prejmenovavame VG, to je to v nazvu v mapper pred pomlckou, tedy u tebe/luksuntu nazev: lvm

predpokladam ze tedy vadi ze je system nabehnut a je primontovan pod puvodnim nazvem, a odpojit/poschazovat lvm by bylo komplikovanejsi nez to predelat (postup stejnej) v chroot z jineho systemu

nebo poloprase reseni: zacatek postupu stejnej, jen misto "sudo update-grub" to prepsat "rucne" (po restartu/priste uz update-grub pujde tim ze bude start z noveho nazvu)

sudo sed -ibak 's#mapper/lvm#mapper/usb#' /boot/grub/grub.cfg

pregenerovani initramfs sem zjistil ze neni treba, nazev VG v nem pouzit neni, pripadnej SWAP pro hibernaci je pres UUID ktere se nemeni.
kdyz das reboot, tak se to asi sekne (me ted pri overeni ve virtualo ano), takze proste vypnout natvrdo (nebo viz vejs to zkusit v chroot

[Petr Fiedler]

Tady.

[Petr Fiedler]

mozna ted budes mit nejjednodusi, nastartovat USBFlash s cistym/nesifrovanym Live Mintem a udelas chroot a budes mit jistotu(?) ze se provede opravdu s SSD a opravis si hlavni system...

Přesně tak Keďo, tohle zabralo. Jen je mi divné, že mám v BIOSu při nastavování pořadí boot priority 2x stejnou položku. Ať nastavím kteroukoliv z nich, primární systém se zavede. Podivnost je ještě v tom, že pokud při bootu nevyvolám boot menu (F12) a nechám výběr na BIOSu, tak se systém zavede Legacy. Pokud vyvolám boot menu a vyberu tu stejnou položku, která je v BIOSu nastavená v boot priority jako první ručně, tak se systém zavádí jako UEFI (soudím podle loga GIGABYTE na login screen). Jako ničemu to nevadí, protože systém startuje, ale zajímalo by mě, čím by to mohlo být? Nenapadá tě něco?

Zítra (dnes) zkusím tohle. Pokud to zafunguje, tak tu reakci označím jako řešení a hotovo.

Jinak zase VELKÉ DÍKY za to, co pro mě děláš. Jak bude čas, všechno si odsud zase napíšu do učebnice a ještě si to pro lepší pochopení znovu projdu.

[Petr Fiedler]

Napadlo mě, že až nainstaluji znovu ten testovací Mint, tak ta duplicitní položka (možná) z BIOSu zmizí. Jestli třeba něco nezůstalo v prvním sektoru toho testovacího disku.

A pro příště, abych se takovým problémům s UUID vyhnul, tak bude lepší upravit před instalací skript např. místo lvm-rootfs zadat lvm-rootfs-corsair, lvm-rootfs-samsung atp., ne?

[k3dAR]

neni treba preinstalovavat, staci v nabehlem (v UEFI rezimu) pouzit:

# zobrazeni EFI polozek, budes mit nejspis 2x ubuntu stejne radky (krome prvniho sloupce Boot00XY)
efibootmbr --verbose

# smazani jedne ubuntu polozky, misto 00XY das co mas(bez slova Boot) na zacatku radku s ubuntu kterej chces smazat
sudo efibootmgr --delete-bootnum --bootnum 00XY

[Petr Fiedler]

Provedl jsem, ale nepomohlo. Každopádně je to fuk, protože jsem byl donucen obnovit systém Clonezillou a po obnově bylo vše OK.

[k3dAR]

Příloha:

• luksuntu-20190419.sh (11318 bytů)

A pro příště, abych se takovým problémům s UUID vyhnul, tak bude lepší upravit před instalací skript např. místo lvm-rootfs zadat lvm-rootfs-corsair, lvm-rootfs-samsung atp., ne?

pretim sem spatne napsal ze je problem i s LV jmenem => problem je jen s VG jmenem, protoze muzes mit klidne na SSD vg1-rootfs a na USBFlash jine vg2-rootfs
=> upravil sem skript, nahore mas k user nastaveni LVM_VG promenou

[Petr Fiedler]

Díky za úpravu skriptu. Klidně jsem to mohl měnit "ručně", ale takhle je to samozřejmě lepší.

[k3dAR]

v BIOSu mas asi nastavene nekde neco jako "Legacy First", tedy ze nejdriv zkouse Legacy a pak UEFI, mohlo by to jit zmenit na "UEFI First", pokud nebude na vyber jen "Legacy First, UEFI Only"... zkoukni, uvidis

[Petr Fiedler]

Prohledal jsem celý BIOS, ale nic takového jsem nenašel. Ale nevadí, pokud je UEFI lepší, tak hold budu muset bootovat přes F12. Nedávno tu někdo psal proč má raději UEFI, ale ty důvody už si nepamatuji a ani jsem tu reakci nenašel. Je podle tebe v něčem zásadním UEFI lepší než Legacy?

[k3dAR]

na jakem HW? treba najdu info/screen na netu...

ad UEFI Vs Legacy - zasadni je asi to ze muzes mit vice OS s jejich nativnim zavadecem, protoze v EFI se nepouziva 1 zavadec v MBR (ktere k pro Linux klidne WIndows pri nejakem update prepisou), ale kazdy OS si hodi svoji EFI binarku(=zavadec) do EFI oddilu a deska-efi nabizi v BootMenu(EFI) tyhle binarky klidne z jednoho disku, v Legacy je pro to potreba mit kazde na jinem disku a v BootMenu(Legacy) vybiras z pripoejenejch disku)...

dalsi rozdil je ze UEFI pouziva GPT rozdeleni, ze je nutne(pokud se nepletu) pro >2TB disk, GPT zaroven nema omezeni na pocet oddilu, coz kdyz pouzivam LVM je mi stejne jedno...

dalsi vec ze EFI pristupuju k HW jinak (hlubsi podrobnosti nevim/neresim) kdy startovat z disku zacne rychleji a nepreblikava pri tom obraz, coz je jen esteticka vec...

rozdilu + vyhod/nevyhod bude jiste vice...

[Petr Fiedler]

na jakem HW? treba najdu info/screen na netu...

GIGABYTE Z170-D3H

Díky za info k EFI. Já jsem dneska četl článek o EFI a tam psali, že by měl být EFI boot stabilnější s ohledem na chyby v ovladačích. Ale vztahovalo se to k Windows a nedovedu posoudit, jak je na tom Linux.

[k3dAR]

co sem nasel nejake screeny biosu tve desky, z toho co vidim me napada v sekci BIOS polozka "Storage Boot Option Control", na foto je nastavene na UEFI, zkoukni jake moznosti tam mas

[Petr Fiedler]

... zkoukni jake moznosti tam mas.

• Do not launch
• UEFI
• Legacy

Samozřejmě to mám nastaveno na UEFI. Budu se prostě muset smířit s tím, že pokud budu v budoucnu potřebovat využívat UEFI, tak budu muset při bootu mačkat F12. Do té doby budu nechávat automatické Legacy. Ale trochu nechápu logiku firmu té desky.

[k3dAR]

divne, mozna to maj jeste nekde jinde, ale kdyz to nemam pred sebou tak se blbe hleda kdyz musim spolehnout jen na to ze nekdo nekdy nejake screenshoty biosu tve desky na net hodil )

jeste me napadlo, zkus zapnout "Secure Boot", vim ze nektere desky vypinaj LegacyBoot pri jeho zapnuti...

[ewew]

Odporúčam aby si pozrel man stránku pre grub-install na tebou používanej distribúcii.

[Petr Fiedler]

Dobře, díky.

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

A přitom stačilo odpojit ten šifrovaný disk, nainstalovat na druhý systém a zase zpět připojit ten šifrovaný. Pak jen přepínat disky při bootu.

[Petr Fiedler]

Dobrý den pane profesore

A přitom stačilo odpojit ten šifrovaný disk, nainstalovat na druhý systém a zase zpět připojit ten šifrovaný. Pak jen přepínat disky při bootu.

To je mi jasné. Tady to zmiňuji v budu 2.:

Je mi jasné, že když před instalací pokusného Mintu vypnu v BIOSu ostatní disky, tak se GRUB nainstaluje na sdc včetně nabídky GRUBu a bude to fungovat.

Se stejným problémem jsem se setkal před pár týdny. Tenkrát se to v mých očích chovalo nelogicky, ale nebyl jsem si teď jistý, jestli to tenkrát nebylo způsobeno tím, že jsem nainstaloval zavaděč na špatný disk. Takže jsem si teď chtěl ověřit, jak se to bude chovat, když si pohlídám, abych nainstaloval zavaděč na správný disk. K mému úžasu se to chová stejně nelogicky, jako předtím.
V miulosti jsem nadával na MS, jak můžou používat takový instalátor, který ti záměrně nainstaluje systém na jeden disk a zavaděč na druhý. Udělal to tak vždy, pokud druhý disk v pc byl. Pak stačilo, aby si např. někdo z rodiny odvezl ten druhý disk, který byl datový na víkend k babičce a nenabootovals. Tak mě zajímalo, jak je na tom Linux.
Popravdě řečeno, přijde mi divné, že když v instalátoru určím pro instalaci zavaděče sdc, že pak musím v boot menu vybírat pro zavedení daného systému sda. To mi přijde nelogické. A taky se divím, že v instalátoru není možnost si vybrat, na jakém disku bude ta GRUB nabídka. To mi přijde user antifriendly.

Vlastně bych byl rád, kdyby mi tu někdo vysvětlil, proč se to chová tímto způsobem.

[lertimir]

No GRUB 2 má většinou automaticky zapnutou funkci "prohlédni disky a zařaď nalezené operační systémy do menu". Navíc v multidiskovém systému je vhodné důsledně se připojovat k diskům pomocí UUID, protože se pořadí sdx může měnit, (o pořadí rozhodují milisekundy, kdy který disk odpoví) UUID se nemění.

[Petr Fiedler]

Ahoj

No GRUB 2 má většinou automaticky zapnutou funkci "prohlédni disky a zařaď nalezené operační systémy do menu".

To chápu. Co ale nechápu je, proč se při nové instalaci nevytvořilo na sdc nové menu.

Navíc v multidiskovém systému je vhodné důsledně se připojovat k diskům pomocí UUID, protože se pořadí sdx může měnit, (o pořadí rozhodují milisekundy, kdy který disk odpoví) UUID se nemění.

Pokud myslíš v /etc/fstab, tak to tak samozřejmě dělám. sda a sdc jsem psal pro vaši lepší orientaci.

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

Já ovšem myslel fyzické odpojení, vytrhnutí kabelů. Grub je mocný nástroj, nelze přednastavit všechny možné varianty automatu. A co si budeme vykládat, sestavitelé distribucí mu nevěnují moc pozornosti. Proto je dobré znát jeho základní možnosti, pochopit je a umět si ho nainstalovat ručně. Pak neudělá to co nechceš. Narozdíl od Windowsů se instalátor ptá, jestli jej chceš instalovat.

[Petr Fiedler]

Já ovšem myslel fyzické odpojení, vytrhnutí kabelů.

Tak to je zajímavé, protože jsi to byl právě ty kdo mi před časem radil, že je zbytečné sundávat z disku kšandy. Že jej stačí zakázat v BIOSu. To mi právě tenkrát přišlo jako dobrá rada. Je to podstatně elegantnější, než odpojovat všechny kabely, tahat case z poza stolu a něco demontovat a pak vše zpátky.

Nebo je v něčem rozdíl?

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

Ano, mělo by to stačit, ovšem, co je to za Bios, má poslední firmware, chová se korektně? Pak je Bios a UEFI. Už jsem i viděl, že Linux kašlal na nastavení Biosu. Takže pokud to tímto způsobem uděláš, pak je nutné při instalaci zkontrolovat, jestli nějakým způsobem není druhý disk vidět, což se stát může. Pak se to dá obejít skrytou partitions atp. Tedy, když už chceš spoléhat na nastavení automatu. Ale není nad to si to všechno ošéfovat vlastnoručně. Ale neboj, také jsem si to musel nastudovat a zkoušel postupy způsobem pokus --> omyl. Lépe se to asi ani pod kůži dostat nedá.

[Petr Fiedler]

Za tuhle reakci jsem rád. To tedy koukám, že se může stát, že Linux ignoruje nastavení BIOSu. Takže při nastavení automatu si to pak pohlídat a kdyby něco, tak kšandy dolů.
Ten fígl s skrytou partyšnou znám. To je super.

Jinak BIOS má poslední firm. Docela si to hlídám. Korektně se chová a jde o BIOS/UEFI.

[k3dAR]

* ODOZNACUJU jako reseni
protoze neresi problem ale jen informuje jak mu slo predejit a navic to tazatel psal ze vi drive

[Petr Fiedler]

No, nechtěl jsem to napsat takhle natvrdo, ale v podstatě s tebou souhlasím

Za chvilku zkusím ten tvůj postup.

[theseuszn]

Příloha:

• uefi boot menu.jpg (125010 bytů)

Původně jsem reagovat nechtěl, nějak mi to ale nedalo. Takhle to mám dočasně já, tak jak psal Petr Šobáň:

SSD-1:
Disk /dev/sda: 111,8 GiB, 120 034 123 776 bajtů, 234 441 648 sektorů
Zařízení   Začátek     Konec   Sektory Velikost Druh
/dev/sda1     4096    208895    204800     100M Systém EFI
/dev/sda2   208896 234438655 234229760   111,7G Souborový systém Linuxu

SSD-2:
Disk /dev/sde: 232,9 GiB, 250 059 350 016 bajtů, 488 397 168 sektorů
Zařízení   Začátek     Konec   Sektory Velikost Druh
/dev/sde1     2048    198655    196608      96M Systém EFI
/dev/sde2   198656 440199167 440000512   209,8G Souborový systém Linuxu

Je to jen zkrácený výpis, mezi aktivními disky sou ještě 2 hdd bez bootu. Každé sd-éčko je na začátku malinko jinak, ale to je putna.

V příloze Menu pro výběr OS.

[k3dAR]

timto mas 1 grub kterej pro 2 disky, jenze tazatel ma 1-LUKS 2-BezLUKS, takze:
s Grub na 1 by zadaval LUKS heslo pro odemceni "oddilu" (kde ma grub moduly a grub.cfg) i pri startu disku BezLUKS
s Grub na 2 by nezadaval LUKS heslo a tedy OS na 1 by nemel pristup k rootfs (kde ma /boot s jadrem a initramfiskem)

proto potrebuje mit Grub na kazdem disku zvlast...

[theseuszn]

No popsal si to hezky, aspoň si to teď tazatel bude moct správně pořešit. A budu se těšit na tu chvíli, až se tazatel tady pochlubí (jako že je to nemožný), jak moc mu ta tvá poučka pro mě pomohla :D

[k3dAR]

ses mimo, co sem popsal bylo info pro tebe, tazatel toto vi, proto to zacal resit, aby pri startu OS z disku2 NEmusel pouzivat Grub na disku1-LUKS a tedy NEmusel pro start nesifrovaneho-OS-disk2 zadavat zbytecne heslo pro disk1...

reseni je mozne, tak jak se snazi, mit na obou diskach svuj grub a vybrat v UEFI boot seznamu konkretni disk podle toho co za OS chce, kdyz vybere disk1 s LUKS, zada luks heslo, kdyz vybere disk2 bez LUKS, heslo zadavat nebude...
(naopak resenim nebylo ta tva nesmela informace

[Petr Fiedler]

Zdravím,

i když mi tvá rada nepomůže, tak jsem rád, že jsi se osmělil a napsal

[Petr Fiedler]

A víš, že mě obojí napadlo? Řešení ala "poloprase" pro mě nepřichází v úvahu. Přesně tohle (vypnutí natvrdo) mi dost rozbíjí systém, takže pak musím obnovovat. Takže jsem v BIOSu vypnul primární i datový disk a zavedl jsem ten pokusný Mint, který je na tom starém hdd. Připojil jsem flešku a v terminálu dal:

user@mint19:~$ sudo cryptsetup luksOpen /dev/sdb3 sd3_open
user@mint19:~$ sudo mkdir -p /target
user@mint19:~$ sudo mount /dev/mapper/lvm-rootfs /target
user@mint19:~$ sudo mount /dev/sdb2 /target/boot/efi
user@mint19:~$ sudo mount --bind /dev /target/dev
user@mint19:~$ sudo mount --bind /dev/pts /target/dev/pts
user@mint19:~$ sudo mount -t proc proc /target/proc
user@mint19:~$ sudo mount -t sysfs sysfs /target/sys
user@mint19:~$ sudo chroot /target
root@mint19:/# sudo vgrename lvm usb
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  Volume group "lvm" successfully renamed to "usb"
root@mint19:/# ls /dev/mapper/
control  sdb3_open  usb-rootfs
root@mint19:/# nano /etc/fstab 
root@mint19:/# update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/lvm-rootfs'.
root@mint19:/#

A skončilo to stejnou chybou, jako když jsem to dělal z nastartované flešky. U vgrename jsem nemusel použít sudo, ale neuvědomil jsem si, že jsem zrovna root. Ale to nevadilo, protože k přejmenování došlo. Napadlo mě dát exit a pak update-grub s odemčeným a připojeným LVM, ale bál jsem se to udělat. Pak mi to stejně přišlo jako nesmysl. Takže jsem to zase přejmenoval zpět a změnil zpátky i /etc/fstab a necháme to být. Jak jsem psal včera. Pokud se budu v něčem rýpat, tak si to pohlídám a až budu v budoucnu flešku přeinstalovávat, tak si dám vgname dle uvážení.

Každopádně díky :)

Ještě se chci zeptat. Připojení sdb2 (efi) byl správný krok, nebo zbytečný?

[k3dAR]

zkus to "sudo vgrename lvm usb" udelat hned po cryptsetup, tedy pred tim nez primountovavas rootfs stareho nazvu

[Petr Fiedler]

Vše šlo jako po másle, ale jen do update-initramfs:

root@mint19:/# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-4.15.0-48-generic
cryptsetup: WARNING: invalid line in /etc/crypttab for sd3_open - 
root@mint19:/#

Až ale teď si všímám, že v tom varování není sdb3_open, ale jen sd3_open. To tak má být, nebo jde o chybu?
Jinak jsem se do /etc/crypttab díval a ten řádek byl nezměněn.
Po rebootu jsem v bootmenu vybral flešku, zadal heslo, objevilo se logo Mintu a systém startoval. A pak:

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.2) built-in shell (ash)
Enter "help" for a list of built-in commands.

(initramfs)

Co teď? :)

[k3dAR]

ad sd3_open - si se preklep u cryptsetup
ad update-initramfs_error + nebootovani - souvisi to s tim preklepem
ad co ted - udelat to znovu pres preklepu

[Petr Fiedler]

No bezva :(

[k3dAR]

co bezva? o nic nejde ne? proste to udelas znovu ale nepreklepnes se u cryptsetup odemnuti na sd3_open, ale napises spravne sdb3_open

[Petr Fiedler]

To si jen myslíš

Měl jsi pravdu. V terminálové historii bylo skutečně sd3_open. Tak jsem celý postup kromě přejmenování zopakoval, ale nepomohlo to. Při update-initramfs -k all -u jsem dostal naprosto stejnou chybovou hlášku, jen tentokrát pro sdb3_open. Takže reboot a celé znovu. Tentokrát jsem to přejmenoval zpět na lvm a hned zase zpět na usb. Při update-initramfs opět stejná chyba. Takže reboot, blkid a do /etc/crypttab jsem dal UUID pro /dev/mapper/sdb3_open a pak reboot, ale systém pořád nenabíhal stejně jako párkrát před tím. Takže další chroot a to UUID jsem vrátil zpět, ale zase systém nenaběhl. Podle přísloví tonoucí se stébla chytá jsem zkusil všechno možné i nemožné, ale marně.

Nějaký nápad? Že by Clonezilla? A nebo to rozlouskneme?

[k3dAR]

v prvni rade si prehlednul, ze sem se pak opravil, ze pregenerovani initramfs po zmene VG jmena neni treba sice ten koukam pro do rozbaleneho initramdisku a v conf/conf.d/cryptroot VG-LV uvedene vidim, ale kdyz to pretim zkousel ve virtualu rebootlo se po prejmenovani VG i bez pregenerovani initramfs, kazdopadne kdyz uz ho mas vadnej generovat musime

1. v /etc/crypttab ma byt UUID pro LUKS oddil na disku, v tvem pripade /dev/sdb3 NIKOLIV pro odemcenej LUKS kontejner 2. ted byla chyba na me strane a nedoslo mi to nazev pod kterym to v chroot odeknes, musi bejt stejnej jako co mas uvedene jako prvni slovo v cryptab radku, tzn. z luksuntu to je "luks" klidne to muzes nechat, protoze tohle se mlatit u 2 stejnejch luksuntu instalaci zapohjenejch do sata/usb nemuze... ale udelej si znovu chrootove kolecko, jen odemkni takto:

sudo cryptsetup luksOpen /dev/sdb3 luks

[Petr Fiedler]

Budu chrootovat, jak když bičem mrská Kolečko dám, ale až ráno. Dobrou a dík za vše

[Petr Fiedler]

Právě ti píšu ze systému, který mám nainstalovaný na flešce

~$ ls /dev/mapper/
control  luks  usb-rootfs

Výborně!

[Petr Fiedler]

A ještě mám 2 otázky:

1. Když zadávám heslo k odemčení LUKS a zadám je špatně, tak se pak objeví pár řádků a na posledním je "grub>" a bliká tam kurzor. Vždy to řeším tak, že tlačítkem rebootuji pc a pak znovu zadám heslo. Moc se mi ale tohle řešení nelíbí. Mohl bys mi sem prosím tě napsat, co zadat, aby se mi odemknul LUKS a naběhl systém?
2. Snažím se změnit iteraci, ale nedaří se mi to. Dohledal jsem, že volba --iter-time je relevantní pouze pro LUKS operace jako luksFormat a luksAddKey. Poraď prosím, jak snížím iteraci na 1000 ms? Mám 35 místné heslo, které obsahuje číslice, malá i velká písmena a speciální znaky, takže IMHO iteraci 10 s nepotřebuji.

[Petr Fiedler]

Edit:

A ještě mám 2 otázky:

1. Když zadávám heslo k odemčení LUKS a zadám je špatně, tak se pak objeví pár řádků a na posledním je "grub rescue>" a bliká tam kurzor...

[k3dAR]

ad 1) bohuzel nevim jak v GrubRescue poznat kterej disk je kterej, urcite neni poradi totozne jako sda,sdb,sdc pak pridelene v nabehlem systemu... takze pokud mas vice disku a na nich stejny pocet oddilu, tak leda zkouset postupne, problem ale bude kdyz budes mit zapojene 2 disky kde bude oboje s 3 oddily a oboje na tretim bude mit LUKS, pokud by kazde melo jine LUKS heslo, tak spatne vybranej poznas ze ti nevzalo heslo :) presna moznost by byla pouzit UUID LUKS oddilu, ale to predpokladam si pamatovat nebudes, mozna na papirek na monitor nalepit jinak postup je(v GrubRescue)

# zobrazeni dostupnych disku a oddilu
ls

## dejme tomu prvni disk(cislovane je od 0), s rozdelenim gpt, treti oddil (cislovane je od 1)
# odemceni pres disk,oddil
cryptomount (hd0,gpt3)

# nebo odemceni pres UUID
cryptomount -u uuidluksoddiluBEZpomlcek

# inicializace normalniho Grub rezimu
insmod normal

# aktivace normalniho grub rezimu
normal

ad 2) neresil sem, ale rychlej find, a jde to menit i bez preformatovani/presifrovani, je ale potreba nahradit (pridat novej, overit ho a smazat starej) stavajici klic

# pripojeni upovidane, ktere zobrazi cislo slotu pro pouzitej klic (to cislo na konci pouzijes jako CISLOSTAREHOSLOTU)
sudo cryptsetup --verbose luksOpen /dev/sdXY sdXY_open

# zobrazeni infa se seznamem pouzitejch/nepouzitejch slotu (jeden pozuitej bude heslo co zadavas rucne, druhej ten klic-soubor)
# koukni kterej je prvni nepouzitej (predpokladm treti slot s cislem 2) ten v naslednem pouzijes jako CISLONEPOUZITEHOSLOTU
sudo cryptsetup luksDump /dev/sdXY

# pridani noveho klice
sudo cryptsetup --iter-time 1000 --key-slot CISLONEPOUZITEHOSLOTU luksAddKey /dev/sdXY

OVERIT, OVERIT a jeste jednou radeji OVERIT, ze novej klic funguje(odemknout s --verbose a zda ukaze spravne cislo noveho slotu

# smazani puvodniho
sudo cryptsetup luksKillSlot /dev/sdXY CISLOSTAREHOSLOTU

[Petr Fiedler]

Ad 1) - když je tomu tak, tak je lepší restartovat tlačítkem, než zadávat UUID atd.
Mě by v podstatě stačilo, aby se při zadávání hesla zobrazila za každý znak např. hvězdička. To by nešlo nastavit?

Ad 2) - zkusím později, pak dám vědět.

[k3dAR]

no ted sem pri zapinani si vsiml ze pri dotazu na LUKS (tom prvnim po zapnuti, v Grub) zobrazuje hdX,gptY, takze pokud si budes vsimat toho (i toho zda se meni, nebo ne), muzes bez dohledavani pri spatne zadanem pouzit to rovnou :)

[Petr Fiedler]

Absolutně nerozumím, co mi tím chceš říct.

[k3dAR]

kdyz zapnes stroj, zobrazi se po chvilce dotaz od GRUBu na zadani LUKS hesla a zobrazuje:

Attempting to decrypt master key...
Enter passphrase for hdX,gptY (tvojeuuidlukdoodilubezpomlcek)

kdyz zadas spatne heslo, tak (misto toho dohledavani spravneho hdX a gptY nebo pouziti dlouheho UUID), lze odemknout pres to hdX,gptY co ti zobrazovalo, nevim zda se meni, pokud ne, tak by sis snadno pamatoval 2 cisla, pokud meni, tak by sis musel vzdy pamatovat to konkretni a kdyz by zadane heslo bylo spatne pouzil bys v grub rescue:

cryptomount (hdX,gptY)
insmod normal
normal

nevim teda duvod toho proc si nechtel mackat reset tlacitko, pokud ses bal ze to je "natvrdo" tak to nemusis resit, protoze v tu chvili(kdyz je LUKS zamcenej) neni zadnej filesystem pripojen

[Petr Fiedler]

nevim teda duvod toho proc si nechtel mackat reset tlacitko ...

Protože relativně dlouho trvá, než se to rebootuje a zobrazí se zase login screen. Otázka je, jestli tohle bude rychlejší. Dost to zdržuje ta iterace 10 s. Pokud zadáš špatné heslo, tak se to doszvíš celkem pozdě.

V drtivé většině případů zadám špatné heslo proto, že málo stisknu nějakou klávesu a daný znak se nezapíše. To ale nevidím, protože se na login screen nezobrazují ty hvězdičky. Když se loguji do šifrovaných Windows, které jsem si ponechal jako sekundární systém ze studijních důvodů (sítě), tak se mi na login screen zobrazuje za každý znak puntík a špatné heslo tak zadám jen zřídka, protože když vydím, že mi to nějaký znak nevzalo, tak prostě jen zmáčknu danou klávesu znovu. To ale v Lunuxu s LUKS nejde. Alepsoň při současné konfiguraci. Šlo by s tím něco udělat? Zkoušel jsem googlit, ale marně.

[k3dAR]

pokud budes znad X a Y, tak zalezi jak rychle budes psat

zobrazovani hvezdicky u GRUB-LUKS dotazu zapnout (pokud vim) nejde, je to predpokladam obecna chtena bezpecnostni vlastnost, aby neslo odkoukat pocet zadavanejch znaku, coz u tebe s 30 je asi irelevantni, kdyz to ani pozorovatel nedokaze spocitat bez matlani na lcd :D (jinak proc 30?? ja pouzivam 20 (male/velka/cisla/znaky) a prijdu si uz dost paranoidni, ale mozna se branis prolomeni pri pouziti vsech pocitacu na svete, vcetne tech vladnich/tajnych superpocitacu

[Petr Fiedler]

... jinak proc 30??

Ne 30, ale 35. A proto, protože tomu nerozumím a tak jsem dal raději více, než málo. Ale pokud říkáš, že 20 stačí, tak uberu.

[k3dAR]

no u 20 (male/velke/cisla/znaky) je na prolomeni v radu let potreba miliony dnesnich nejsilnejsi superpocitacu

[Petr Fiedler]

Fajn, tak to zkrátím na 20. Tím lépe.

[k3dAR]

sice ten odhad prolomeni byl na 20mistne, ale pro LUKS mam vlatne 38miste :D

[Petr Fiedler]

Možná se bráníš prolomení při použití všech počítačů na světě, včetně těch vládních/tajných superpočítačů

[k3dAR]

je to mozne :D jinak dnes sem take zadal spante LUKS pri zapnuti NB a vsiml si ze to hdX,gptY si NEmusis vuubec pamatovat/vsimat pri zadavani, protoze kdyz se uklepnes a skoci error, stale to mas nahore napsane

[Petr Fiedler]

Vím to. Je tam i to UUID. Podívám se tedy na ty příkazy, co jsi radil a až zadám špatně heslo, tak to schválně zkusím.

[Petr Fiedler]

jinak dnes sem take zadal spante LUKS pri zapnuti NB ...

A ještě mě napadá: A zkusil jsi to tedy odemknout "ručně", nebo si rebootoval?

[k3dAR]

zkusil, bez problemu

[Petr Fiedler]

U mě taky bez problémů. A je to mnohem rychlejší, než reset. Jenom ta iterace je tedy pořád dlouhá. Zkusím tedy ještě ubrat a dám vědět.

[Petr Fiedler]

Ad 2) - Nemůžu pochopit, jestli se to týká právě používaného systému na SSD, nebo jestli mám do pc zasunout flešku a z právě naběhlého systému na SSD řešit tu flešku? A pak samozřejmě naopak.

[k3dAR]

muzes to delat pri nabehlem systemu z toho, ale pro overeni zda lzde novym odemknout musis dat restart, nebo to muzes delat z jineho (netreba v chroot) a pak overeni muzes tim ze luks zavres a otevres pres nove rovnou...

[Petr Fiedler]

Ad 2):

~$ sudo cryptsetup --verbose luksOpen /dev/sda3 sda3_open
Zadejte heslo pro /dev/sda3: 
Pozice klíče 0 odemknuta.
Zařízení /dev/sda3 nelze použít, protože se již používá
(již namapováno nebo připojeno).
Příkaz selhal s kódem -5 (zařízení již existuje nebo zařízení je zaneprázdněno).

Tak tohle se mi zobrazilo jak po tom prvním příkazu, tak při OVĚŘOVÁNÍ. Přitom ten luksDump mi ukázal, že první volný slot je 2. Tak jsem pro vytvoření nového klíče do toho příkazu zadal 2 a při ověření se mi zobrazilo zase to samé.

[k3dAR]

odemknout podruhe uz nepujde, ale vidis ze se snazilo odemknout klicem v slotu 0 mozna to zbytecne komplikuju a prvne zadanej klic primo pri vytvareni LUKS asi bude vzdy v slotu cislo 0

[Petr Fiedler]

# smazani puvodniho
sudo cryptsetup luksKillSlot /dev/sdXY CISLOSTAREHOSLOTU

Po odentrování to chtělo jakékoliv nové heslo. Tak jsem je zadal, rebootoval a iterace je stále 10 s. V /boot je crypto_keyfile.bin jen jeden, IMHO ten původní. V GUI mi to v jeho vlastnoustech ukazuje:

Poslední přístup: Po 14. ledna 2019, 13:43:22 CET
Změněný:          Po 14. ledna 2019, 13:42:23 CET

[k3dAR]

crypto_keyfile.bin ma byt jen 1... vysvetim:

- pri zadavani do Grub LUKS - zadavas heslo NEsouvisejici s crypto_keyfile.bin
- crypto_keyfile.bin pouziva az druhe automatizovane odemceni z initramfs

to co si ty delal(?) je o tom, ze:

- pridas dalsi heslo kteremu nastavis pri vytvareni jine iter-time
- odeberes puvodni heslo ktere melo pro tebe nevyhovujici iter-time
- po zmene se pri zadavani do GRUB LUKS pouzije to nove heslo

zobrazi se ti ted slot 0 prazdnej a slot 2 nove pouzitej?

sudo cryptsetup luksDump /dev/sdXY

[Petr Fiedler]

Key Slot 0: DISABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

[k3dAR]

tak predpokladam ze se provedlo co melo (v prubehu startu/startanimace se to nezacalo ptat na LUKS heslo?), to ze to trva dele nevim, zkus to s jeste mensim iter-time, jak sem psal tak to nepouzivam a i kdyz by 1000 mela byt 1vterina, koukam ze jde o 1CPU vterinu, delas to na stejnem HW na kterem to pak pouzivas? kdyz bys delal na rychlem a prendaval pak disk do pomalejsiho stroje, tak by to trvalo dele... taky nevim nakolik snizi bezpecnost snizeni iter-time, obecne a nebo s dlouhym heslem

[Petr Fiedler]

v prubehu startu/startanimace se to nezacalo ptat na LUKS heslo?

Myslíš login screen? Pokud ano, tak vše bylo jako při běžném startu. Prostě po chvíli se objevil "dialog" na zadání hesla. To jsem zadal, čekal asi tak těch 10 vteřin a pak se začal načítat systém. Možná to nebude iterací, ale tím, že se hledají další OS, ne?

koukam ze jde o 1CPU vterinu, delas to na stejnem HW na kterem to pak pouzivas?

Ano

taky nevim nakolik snizi bezpecnost snizeni iter-time, obecne a nebo s dlouhym heslem

Před časem jsem tu řešil, jaký typ klíče použít pro zabezpečení SSH. V dané man page jsem se dočetl o nějaké volbě, která (tuším) při vytváření klíčů nastavuje iteraci. Přišlo mi to jako super vlastnost. Filip Jirsák mi k tomu napsal tohle. Přemýšlel jsem o tom a podle mě na tom něco je. Myslím, že součet kombinací velkých a malých písmen, číslic a běžných speciálních znaků je +/- 90. Takže pokud přidáš 2 znaky, je to 8100 x více kombinací. Při iteraci 1 s by jen při dvoumístném heslu zabralo více jak 2 hodiny, abys vyzkoušel všechny kombinace. A teď si vem, že máš 20 místné heslo. To je 90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90. S desetisekundovou iterací Země nebude trvat dost dlouho, abys vyzkoušel všechny možnosti. A myslím, že ani s 1 s iterací by na to život 1 člověka nestačil. Já mám pětatřiceti místné heslo, takže s iterací 1 s asi cajk

[k3dAR]

myslel sem zda se nezacal initramdisk (v prubehu zobrazovani boot animace) ptat na heslo, tedy to co se pretim neptalo protoze si mel pro initramdisk ten keyfile, tedy jesli si nedopatrenim nesmazal keyfile, tedy jestli z nevim jakeho duvodu nebyl na pozici slotu 0 misto 1 keyfile :) ale spis teda jde o to ze bys musel nastavit iter-time jeste na mene, ono si to zkus v nabehlem systemu, kdyz davas odemknout jak dlouho to trva? Grub (narozdil od v nabehlem systemu) nepouziva akcelerovane rutiny pro desifrovani z CPU a mozna se ten iner-time na cpu 1s bere prave s nima

[Petr Fiedler]

ad 2) neresil sem, ale rychlej find, a jde to menit i bez preformatovani/presifrovani, je ale potreba nahradit (pridat novej, overit ho a smazat starej) stavajici klic

# pripojeni upovidane, ktere zobrazi cislo slotu pro pouzitej klic (to cislo na konci pouzijes jako CISLOSTAREHOSLOTU)
sudo cryptsetup --verbose luksOpen /dev/sdXY sdXY_open

# zobrazeni infa se seznamem pouzitejch/nepouzitejch slotu (jeden pozuitej bude heslo co zadavas rucne, druhej ten klic-soubor)
# koukni kterej je prvni nepouzitej (predpokladm treti slot s cislem 2) ten v naslednem pouzijes jako CISLONEPOUZITEHOSLOTU
sudo cryptsetup luksDump /dev/sdXY

# pridani noveho klice
sudo cryptsetup --iter-time 1000 --key-slot CISLONEPOUZITEHOSLOTU luksAddKey /dev/sdXY

OVERIT, OVERIT a jeste jednou radeji OVERIT, ze novej klic funguje(odemknout s --verbose a zda ukaze spravne cislo noveho slotu

# smazani puvodniho
sudo cryptsetup luksKillSlot /dev/sdXY CISLOSTAREHOSLOTU

Tak se mi podařilo snížit tu iteraci. Dělal jsem vše naprosto stejně jako minule, jen jsem u psaní příkazů používal tabulátor a to mi zřejmě pomohlo, protože když jsem jej stiskl po napsání --iter-, tak to doplnil takto:

# Ve tvem prikazu nebylo = 
--iter-time=

Takže jsem za to doplnil těch 1000 a to ověření se zkrátilo tak na 2,5 s. Což tak asi už nechám. A navíc se teď opět používá slot 0, což je systémovější. Takže paráda.

Díky K3ďo

[k3dAR]

divne jednak v manualu nepisu = , zaroven co si vybavuju jinde je --pro-delsi-varianty pouziti = volitelne a hlavne by to snad zarvalo chybu parametru, nedalo mi to a zkusil sem ted pridat klice do 2 prazdnejch slotu, s "--iter-time=1000" a s "--iter-time 1000" a oboje se pridalo bez chyby, oboje v luksDump zobrazovalo "Iterations: 640000"(cca), takze parametr podle me bere s i bez = (jen mi unika proc tam neni ten 1000, ty ho u luksDump SLOT 0 mas?

napadlo me, neni mozne ze si pretim pridal do SLOT 2 klice stejneho hesla? pak rebootnul, zkusil zadat klic, ale protoze byl stejnej pouzil se (LUKS je zkousi zda sedi v poradi od 0 do 7) z SLOT 0, v nabehlem si smazal klic ze SLOT 0, ale uz si nerebootoval? (aby se pri zadani pouzil to stejne heslo ted jiz z SLOT 2, kdyz SLOT 0 byl prazdnej)? a pri zkousce s = si overoval prvnim rebootem kdy to bralo v poradi prvni SLOT 0 kde uz bylo take iter 1000?

[k3dAR]

ted mi doslo, ze vysvetleni je mozna o dost jednodusi tim ze to bylo v SLOT 2, tak nejdriv LUKS zkousel SLOT 0 (a 1) kde iter bylo puvodni, takze ve vysledku to zabralo vice casu nez kdyz by se odemklo rovnou tim v SLOT 0 s puvodnim/delsim iter :)

[Petr Fiedler]

nedalo mi to a zkusil sem ted pridat klice do 2 prazdnejch slotu, s "--iter-time=1000" a s "--iter-time 1000" ...

Taky jsem to zkusil ještě jednou. Napřed jsem úmyslně zadal špatné heslo (u slotu 0, ve kterém se to odemykalo rychle) a než se objevilo grub rescue >, tak to trvalo dost dlouho. Takže patrně nastavení té iterace na tohle nemá vliv. Koukal jsem do man page a u luksFormat se dá ještě nastavit --pbkdf-force-iterations, ale to nevím k čemu je.
Znovu jsem přidal klíč a použil jsem rovnítko a nastavil slot 2. A odemykání trvalo dlouho. Takže je to jak jsi psal v té následující reakci. Prostě LUKS napřed zkouší slot 0. Pak jsem to vrátil zpátky na 0 (úplně stejným způsobem) a už se to opět odemyká rychle.

oboje v luksDump zobrazovalo "Iterations: 640000"(cca), takze parametr podle me bere s i bez = (jen mi unika proc tam neni ten 1000, ty ho u luksDump SLOT 0 mas?

Nemám:

Slot 0 462335
Slot 1 1889326
Slot 2 už si nepamatuji, ale velmi podobný slotu 0. Přibližně 411000.

A proč jsme vlastně použili luksKillSlot a ne luksRemoveKey?

[k3dAR]

luksRemoveKey odstranuje klic nezavisle na tom v jakem je slotu (nevim co by se stalo kdyz bys mel stejnej klic v 2 slotech, mozna by to ignorovalo ten pres kterej si odstraneni potvrzoval), s tim teda souvisi ze pro overeni dobre zadaneho stejneho(jako stavajici v 0) do slotu 2, bys pro overeni musel jednak pouzit odemceni mimo nabehlej system a zaroven vynutit konkretn slot, coz sem puvodne nepsal:

sudo cryptsetup --verbose luksOpen --key-slot=2 /dev/sdXY sdXY_open

protoze jinak by se pri overovani pouzil stejnej klic ze slotu 0 a nevedel bys zda v 2 je ok, pokud mas v 2 slotech jine hesla, tak se vynutit key-slot konkretni nemusi, protoze postupne k 2 dojde samo...

zaroven me tohle trklo, zda nejde v /etc/crypttab take vynutit key-slot a jde, sice to usetri jen par vterin (v tvem pripadde se snizenym iter-time mozna mene, ale z principu proc ne), v crypttab to pridas na konec radku, cislo slotu z luksuntu pro keyfile je 1:

jmenoodemceneho UUID=uuidzamcenehooddilu /crypto_keyfile.bin luks,keyscript=/bin/cat,keyslot=1

(cesta /crypto_keyfile.bin je jak si mozna vzpominas proto ze je to pouzito z initramfs kteremu to pri regeneraci initramfs kopirujem do / (myusleno koren initramdisku nikoliv rootfs)...
a po zmene crypttab pregenerovat initramfs:

sudo update-initramfs -k all -u