Fórum Root.cz

Hlavní témata => Distribuce => Téma založeno: jan.myslivecek 01. 02. 2019, 08:40:41

Název: GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 01. 02. 2019, 08:40:41
Zdravím všechny, řeším jeden problém s přenesením disku včetně instalace Debianu 8 na jiný disk. Oba disky jsou šifrovány pomocí cryptsetup (oddíl /boot nikoliv, sda1), rozdělení obou disků je GPT. Přenesl jsem data v live CD pomocí rsync, pod chroot provedl update-initramfs, grub-install /dev/sda, vše proběhlo bez chyb, ale když chci nabootovat z nového disku tak jen bliká kurzor a nic. Ten stroj neumí UEFI, má klasický BIOS. Zkoušel jsem to i ve virtuálu a výsledek stejný, kurzor bliká a ani písmenko z GRUBu se neobjeví. Asi bych to vyřešil, kdybych použil MBR na nový disk, ale to nepovažuji za řešení. Nenapadá vás něco?

Starý disk:

machine:~# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 72CF66DB-AA60-40F2-97C6-4A83A5D5120C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          585727   285.0 MiB   8300
   2          585728      5860532223   2.7 TiB     8300

Nový disk:
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AFD4CF59-B039-4AAD-BC03-41C554618BC8
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          976895   476.0 MiB   EF00
   2          976896      1953523711   931.0 GiB   8300
Název: Re:GRUB a (ne)bootování
Přispěvatel: alex6bbc 01. 02. 2019, 09:01:02
nevim zda je zde odpoved:
https://ubuntuforums.org/showthread.php?t=2063711

ja kdybych to delal, tak bych si na zacatek disku udelal partisny pro cistou instalaci a pro kopii a nainstaloval system znovu.
a ke konci disku bych si do tech volnych partisen zkusil pomoci dd zkusil nasypat ty partisny z predesleho disku.

pokud by to neslo, tak bych ty data z puvodniho disku ciste prekopiroval pomoci filesystemu, bez dd.
Název: Re:GRUB a (ne)bootování
Přispěvatel: Medys 01. 02. 2019, 12:44:21
Ahoj nejsem odborník ale cca půl roku zpátky jsem si dělal boot flash pro bios i efi.
Napadá mě následující:

Citace
grub-install /dev/sda
Jaké parametry? (--target=?)

Citace
Ten stroj neumí UEFI, má klasický BIOS.
To vypadá že grub-install zvolil --target=x86_64-efi dle partition type (Code)

Dále máš rozdílné Code (8300 = Linux File system; EF00 = EFI System; EF02 = BIOS boot partition)
Starý disk:
Citace
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          585727   285.0 MiB       8300
Nový disk:
Citace
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          976895       476.0 MiB   EF00

Začni pátrat tímto směrem. Večer zkusím najít postup jak jsem dělal boot flash.
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 01. 02. 2019, 14:44:36
Díky za tipy.
Zkusil jsem parametr target a bylo to i386-pc.
Změnil jsem typ code na 15 (Linux fiesystem).
Pak jsem nabootoval z jiného liveCD a zjistil, jsem, že při instalaci grubu to píše toto (to v pův. liveCD se tvářilo OK) - viz níže:
Když jsem použil --force, tak chyba též, ale nabotovalo to OK - ale stále nejde grub bez chyb nainstalovat

Nemáte nějaký nápad?



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.
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 01. 02. 2019, 16:10:33
pokud potrebujes BIOS Legacy a disk v GPT, tak musis pripravit pro GRUB specialni oddil "BIOS Boot Partition", nema zadnej format, velikost staci 1MB, a GRUB do nej nahrava svuj image potrebny pro start v Legacy rezimu z GPT disku...
nasledujici postup to pripravi (priklad pocita ze disk je prazdny, resp. ze prvni oblast 1MB-2MB je nepouzita(od 1MB protoze se u GPT nechava na zacatku)
Kód: [Vybrat]
parted /dev/sdX mkpart '"BIOS boot partition"' 1M 2M
parted /dev/sdX set 1 bios_grub on
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 01. 02. 2019, 16:12:53
Oba disky jsou šifrovány pomocí cryptsetup (oddíl /boot nikoliv, sda1)
proc nesifrujes i /boot? takhle ti muze kdokoliv s fyzickym pristupem snadno podvrhnout initrd kterej odchyti tve LUKS heslo a posle utocnikovi mailem...
GRUB2 umi odemknout LUKS vlastni silou, /boot pak muze byt v LUKS, v LVM, nebo soucast rootfs
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 01. 02. 2019, 23:18:28
Díky moc všem, malá oblast navíc je správné řešení, vyzkouším i šifrovaný boot. Hezký víkend!
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 01. 02. 2019, 23:36:34
k inspiraci ;-) https://www.root.cz/clanky/kompletne-sifrovany-disk-se-systemem-i-daty-debian/
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 04. 02. 2019, 12:52:40
Děkuji. Ještě k šifrovanému /boot - nějak nechápu v čem je ten systém lépe zabezpečený - když útočník sebere zašifrovaný disk, podstrčí svůj, kde si pří startu GRUB řekne o heslo a pak si ho pošle tak má přístup k datům tak jako tak. Jediná obrana je mít jiné heslo pro /boot a jiné heslo pro zbytek (/) - jde to nastavit?
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 04. 02. 2019, 13:15:12
Děkuji. Ještě k šifrovanému /boot - nějak nechápu v čem je ten systém lépe zabezpečený - když útočník sebere zašifrovaný disk, podstrčí svůj, kde si pří startu GRUB řekne o heslo a pak si ho pošle tak má přístup k datům tak jako tak. Jediná obrana je mít jiné heslo pro /boot a jiné heslo pro zbytek (/) - jde to nastavit?
"podstci svuj" co? initramdisk? to prave nemuze kdyz mas sifrovanej /boot, ale muze kdyz /boot sifrovanej nemas (staci prebalit initramfs a pridat parradkovej shell skript co odchnytne heslo, ktere pomoci pridaneho mailx odesle a pak pokracuje v odemceni, takze bys nic nepoznal)

kdyz mas sifrovanej /boot, mohl by utocnik jedine vymenit GRUB efi binarku v EFI oddilu (ten musi byt nesifrovanej), resp. v tvem pripade Legacy boot na GPT, nahradit Grub cast v "BIOS boot oddilu", ale je to mnohem vetrsi prace, resp. vyzaduje to mnohem vice znalosti, takze to profiltruje hromadu potencialnich utocniku...
u Legacy Boot si vic nepomuzes, ale pokud bys pouzil UEFI a tva deska by podporova vlastni klice, mohl by si vyhodit vychozi klice, vlozit jen svuj vlastni, tim podepsat EFI binarku (grub efi nebo primo jadro, nebo jinej bootloader ci efi binarku) a pak by nemohl utocnik podvrhnout svuj upravenej "Grub EFI" protoze tvuj stroj by odmitnul startovat cokoliv co bys nepodepsal ty sam...
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 04. 02. 2019, 13:22:43
jinak jine heslo pro /boot a / samozrejme mit muzes, rucne bys na disku vytvoril 2 oddily, na prvnim LUKS a na nem /boot, na druhem LUKS a na nem LVM a v nem rootfs, home, swap atd...
ale nevim ceho bys tim dosahl, leda bys predpokladal ze by nekdo mohl nahradit GRUB EFI co by odchytnul heslo k odemceni LUKS s /boot ale nemohl by nahradit initramdisk protoze by /boot byl sifrovanej a ty heslo k rootfs zadaval az na dotaz neupravitelneho initramdisku... jenze pokud predpokladame ze utocnik bude mit schopnosti (nebo mu to nekdo prepise, nebo to nekde najde) na to aby upravil Grub EFI binarku na odchyceni heslo a jeste do Grub EFI implementuje mail klienta, bude mit samozrejme schopnosti na to aby do GRUB EFI pridal funkci "az odemnkes /boot, uprav initramdisk aby odchytnul heslo LUKS pro rootfs a posli mi ho"
Název: Re:GRUB a (ne)bootování
Přispěvatel: zapik1 06. 02. 2019, 14:04:17
Zdravím,
taky se přidám se svým problémem s grubem. Mám nb s jedním diskem s tímto obsahem:
Device       Start       End   Sectors  Size Type
/dev/sda1  1128448 500117503 498989056  238G Linux filesystem
/dev/sda2   923648   1128447    204800  100M EFI System
A mám problém v tom, že po startu se objeví jen prompt grubu. když zadám posloupnost příkazů:
set root=(hd0,1)
linux /boot/vmlinuz..... root=/dev/sda1
initrd /boot/initrd....
boot
tak mi to normálně nastartuje.
Zdá se, že grub nenachází konfiguraci.
Jak se to stalo:
vytvořil jsem 3 partition sda3 vloženou mezi uefi  sda2 a linuxovou sda1.  Do této partition jsem instaloval další linux (dualboot) a při požadavku na místo jsem ji smazal. A v ten okamžik to začalo.
Obvyklé postupy oprav jsem zkoušel ale nic nezabralo. Momentálně, protože to umím nabootvat mě to tak netrápí, ale celkem dost štve.

Poradíte co s tím?
Název: Re:GRUB a (ne)bootování
Přispěvatel: Daniel Novotný 06. 02. 2019, 14:38:57
Zdravím,
taky se přidám se svým problémem s grubem. Mám nb s jedním diskem s tímto obsahem:
Device       Start       End   Sectors  Size Type
/dev/sda1  1128448 500117503 498989056  238G Linux filesystem
/dev/sda2   923648   1128447    204800  100M EFI System
A mám problém v tom, že po startu se objeví jen prompt grubu. když zadám posloupnost příkazů:
set root=(hd0,1)
linux /boot/vmlinuz..... root=/dev/sda1
initrd /boot/initrd....
boot
tak mi to normálně nastartuje.
Zdá se, že grub nenachází konfiguraci.
Jak se to stalo:
vytvořil jsem 3 partition sda3 vloženou mezi uefi  sda2 a linuxovou sda1.  Do této partition jsem instaloval další linux (dualboot) a při požadavku na místo jsem ji smazal. A v ten okamžik to začalo.
Obvyklé postupy oprav jsem zkoušel ale nic nezabralo. Momentálně, protože to umím nabootvat mě to tak netrápí, ale celkem dost štve.

Poradíte co s tím?
znovu nainstalovat grub jste zkoušel? (grub-install a update-grub) pokud se posunul začátek té partition kvůli té nové která tam byla, tak grub možná šahá do prázdna...
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 06. 02. 2019, 15:36:47
Děkuji, zkoušel jsem zašifrovat i /boot a v Debianu 9 dle návodu pro UEFI a vše OK. Zkoušel jsem to samé nastavit v Debianu 10 také na UEFI a tam stále grub najíždí do minimálního módu. Rovněž dopadl upgrade ze Stretch na Buster. Netušíte čím by to mohlo být?
Název: Re:GRUB a (ne)bootování
Přispěvatel: zapik1 06. 02. 2019, 18:55:48
Ano,
vyzkoušel jsem postupy co jsem našel v záchranných howto:
  #after starting the root shell, check that your EFI system partition (most likely /dev/sda1) is installed on /boot/efi
  mount /dev/sda1 /boot/efi
  #reinstall the grub-efi package
  sudo apt-get install --reinstall grub-efi
  #place the debian boot loader in /boot/efi and create an appropriate entry in the computer's NVRAM
  sudo grub-install /dev/sda
  #re-create a grub configuration file based on the current disk partitioning mode
  sudo update-grub
ale situace je pořád stejná. Evidentně je problém někde v tom, kde grub má hledat konfigurační soubor.
Název: Re:GRUB a (ne)bootování
Přispěvatel: Medys 07. 02. 2019, 07:31:59
Citace
Ano,
vyzkoušel jsem postupy co jsem našel v záchranných howto:
#after starting the root shell, check that your EFI system partition (most likely /dev/sda1) is installed on /boot/efi
mount /dev/sda1 /boot/efi
Jenže z toho co ji psal máš EFI system partition na /dev/sda2. viz
Citace
Device       Start       End   Sectors  Size Type
/dev/sda1  1128448 500117503 498989056  238G Linux filesystem
/dev/sda2   923648   1128447    204800  100M EFI System
Název: Re:GRUB a (ne)bootování
Přispěvatel: zapik1 07. 02. 2019, 09:03:44
Ano, efi partition mam jako sda2.  parametry tech příkazů jsem samozřejmě modifikoval podle reality.  Sem jsem je vykopíroval z howto tak jak byly, pro ilustraci co jsem zkoušel.
při pokusu o opravu žádný z nich nedopadl s chybou.
Diky Petr
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 07. 02. 2019, 11:11:40
Ano, efi partition mam jako sda2.  parametry tech příkazů jsem samozřejmě modifikoval podle reality.
pokud zadas radu, je potreba uvadet co si konkretne delal a ne nejaky universalni=jinej postup ;-)
- ten reinstall provadis v tom nabehlem systemu?
- po "sudo update-grub" vidis aktualni datum/cas souboru /boot/grub/grub.cfg ? (= tedy ze se opravdu regeneroval a na spravne misto)
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 11. 02. 2019, 19:27:23
Děkuji, zkoušel jsem zašifrovat i /boot a v Debianu 9 dle návodu pro UEFI a vše OK. Zkoušel jsem to samé nastavit v Debianu 10 také na UEFI a tam stále grub najíždí do minimálního módu. Rovněž dopadl upgrade ze Stretch na Buster. Netušíte čím by to mohlo být?
zkusil sem s Debian10 a doslo tak k zmene, EFI Grub uz netaha prvotne primarni cfg z /boot/grub/grub.cfg, ale z /boot/efi/EFI/debian/grub.cfg v kterem je pouze uvedeno vyhledani oddilu se systemem (resp. asi pujde to kde je /boot) a natazeni z neho ten hlavni grub.cfg (tentokrat ten klasicky z /boot/grub)...
nicmene v tom v EFI schazi instrukce pro dotaz na odemceni LUKS, takze neni mozno najit oddil ten oddil z ktereho by natahlo hlavni grub.cfg, (docasnym) resenim je, rucne pridat na zacatek /boot/efi/EFI/debian/grub.cfg radek:
Kód: [Vybrat]
cryptomount -u UUID_SDXY_ODDILU_S_LUKSto UUID najdes jak v /boot/grub/grub.cfg na totoznem ^ radku, nebo z vypisu "sudo blkid" co ti ukaze pro LUKS (neodemcenej, v clanku slo o sda3, u tebe muze byt jinej) oddil
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 11. 02. 2019, 19:53:47
koukam ze ten problem (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917117) by mel byt od vcera opraven (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917117#22) :-)
(samozrejme je potreba stahnout nove daily iso (u netinstall si nejsem jistej, tam snad i grub taha aktualni z netu)
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 13. 02. 2019, 00:18:55
Dobrý den, zkoušel jsem to dnes v Debianu 10 nightly build a stále stejná chyba se objevuje i při upgrade z Debianu 9 na 10, dopsání řádku nepomáhá. Používám LVM, vyzkoušel jsem co mě napadlo i z návodů vše a nic nepomohlo. Používáte LVM nebo jen dm-crypt? Děkuji.
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 13. 02. 2019, 01:43:55
Dobrý den, zkoušel jsem to dnes v Debianu 10 nightly build a stále stejná chyba se objevuje i při upgrade z Debianu 9 na 10, dopsání řádku nepomáhá. Používám LVM, vyzkoušel jsem co mě napadlo i z návodů vše a nic nepomohlo. Používáte LVM nebo jen dm-crypt? Děkuji.
ta oprava je v verzi "grub2 2.02+dfsg1-11", zatim je v unstable (https://packages.debian.org/sid/grub2), v testing (https://packages.debian.org/buster/grub2) je zatim neopravena "2.02+dfsg1-10"...
ten radek mi funguje, pridal si spravne UUID? zkousel sem to s LVM nad LUKS, s neoddelenym /boot ktery je soucasti lv rootfs
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 13. 02. 2019, 16:31:50
Dobrý den,
nevím, co dělám špatně:

root@mix:~# lsblk
NAME                 MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                    8:0    0  1,1T  0 disk
├─sda1                 8:1    0  512M  0 part  /boot/efi
└─sda3                 8:3    0  1,1T  0 part
  └─sda3_crypt       254:0    0  1,1T  0 crypt
    ├─mix--vg-root   254:1    0    1T  0 lvm   /
    └─mix--vg-swap_1 254:2    0 63,7G  0 lvm   [SWAP]
root@mix:~# cat /boot/efi/EFI/debian/grub.cfg
cryptomount -u 61cb768b-62db-4b83-99c1-f4e101f19412
search.fs_uuid c061a3cd-c154-4881-8a71-55c2e778aff2 root lvmid/lTs9Wc-V7ak-5SMV-aMNG-kslH-Ajaa-ZeiDUC/rvmX3v-de1h-Q7Vx-hQsn-7mwl-b06Q-tA2r8M
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

root@mix:~# blkid
/dev/mapper/sda3_crypt: UUID="t0UzCf-UMwW-oK5y-pCq5-kvn2-1RtN-U2AkKg" TYPE="LVM2_member"
/dev/mapper/mix--vg-root: UUID="c061a3cd-c154-4881-8a71-55c2e778aff2" TYPE="ext4"
/dev/sda3: UUID="61cb768b-62db-4b83-99c1-f4e101f19412" TYPE="crypto_LUKS" PARTUUID="9a062dcf-8941-47d8-88d6-d9156ed328cb"
/dev/sda1: UUID="2E1D-8289" TYPE="vfat" PARTUUID="cc1ead8e-fe0b-4d54-b179-604b4e3f0be9"
/dev/mapper/mix--vg-swap_1: UUID="854dcc51-4197-4e86-8742-76e707e221c6" TYPE="swap"

Po rebootu: grub>

GRUB mám verze 2.02+dfsg1-10.
Název: Re:GRUB a (ne)bootování
Přispěvatel: Daniel Novotný 13. 02. 2019, 17:00:28
set prefix=($root)'/boot/grub'
tady se to odkazuje na proměnnou $root a nikde nevidím, že by byla definovaná
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 13. 02. 2019, 23:08:52
set prefix=($root)'/boot/grub'
tady se to odkazuje na proměnnou $root a nikde nevidím, že by byla definovaná
ten /boot/efi/EFI/debian/grub.cfg je krome radku cryptomount vychozi generovanej v Debian10 a promenou root definuje funknce search.fs_uuid
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 13. 02. 2019, 23:16:04
nevím, co dělám špatně:
uz to vidim :-) blkid zobrazuje UUID klasicky s pomlckama ale cryptomount pozaduje bez pomlcek ;-) to sem si predtim kdyz radil blkid nevsiml, pokud bys to vytahoval z /boot/grub/grub.cfg tak tam to bez pomlcek je, viz:
Kód: [Vybrat]
grep cryptomount /boot/grub/grub.cfg
Název: Re:GRUB a (ne)bootování
Přispěvatel: k3dAR 13. 02. 2019, 23:19:07
pokud by ti to i tak neslo, zkus zda z grub shellu to odemknes&nastartujes rucne:
Kód: [Vybrat]
cryptomount (hd0,gpt3)
set root=(lvm/mix--vg-root)
linux /vmlinuz root=/dev/mapper/mix--vg-root ro
initrd /initrd.img
boot
a pokud jo, zda to pujde i kdyz rucne odemknes pres UUID(bez pomlcek):
cryptomount -u 61cb768b62db4b8399c1f4e101f19412
Název: Re:GRUB a (ne)bootování
Přispěvatel: jan.myslivecek 14. 02. 2019, 11:08:43
Dobrý den, děkuji za radu, skutečně cryptomount bez pomlček funguje OK. I ruční způsob odemčení a nabootování funguje. Jen jsem zkoušel použít balíček GRUB grub2_2.02+dfsg1-11_amd64 z unstable a bez cryptomount -u UUID bez - nefunguje. Ale to už není tak podstatné. Děkuji všem za rady.