Vlákno názorů k článku Záchrana nebootujícího Linuxu pomocí konzole zavaděče GRUB 2 od RDa - Zajimave, z v dobe grub/bios/mbr jsem nemel potiz...

Zajimave, z v dobe grub/bios/mbr jsem nemel potiz nastartovat OS, ale jak prisel grub2,uefi,gpt, tak to je jedna rozbita instalace za druhou a nikdy se nemuzu spolehnout ze to najede.

Rad totiz kopiruji partisny pres DD kdyz delam novou instalaci jako klona a vsechno moderni se tomu nesmyslne brani.

A zmena z mbr na uefi/gpt je tak na 3-4 rebooty nez upravim vse tak jak ma byt.. clovek aby si na to pomalu udelal migracni skript.

No ale za to si (asi) můžete sám, když používáte /dev/sdX v /etc/fstab, (hd,0) v grub.cfg ...
dd pro kopii GPT disku taky nejde, je třeba sgdisk /dev/sdx -R /dev/sdy a to ještě s NVMe je třeba počítat s /dev/nvme0n1p2 a ne /dev/sda2..., pro kopii partition to použít jde.
Tedy důvod pro použití UUID, PART-UUID apod.
Ano, trošku komplikace ale zase vám (po změně disků) BIOS nezamíchá písmenka u /dev/sdX (resp. je to jedno).
Než jsem byl nucen přejít na GPT/EFI, tak jsem taky trošku nadával, proč Ubuntu používá UUID. No a už vím :-)
Mimochodem, takto jsem dost dlouho hledal, proč mi nejde naklonovat Raspbian z SD karty na flešku - totéž, nutno opravit /dev/mmcblkxxxx na nejlépe UUID nebo PART-UUID, protože nevíte jistě, jestli ta fleška bude vždycky /dev/sda nebo náhodou, když tam při startu bude ještě jedna, třeba najednou /dev/sdb

Prave ze pouzivam UUID a mam rad oddeleny /boot partition.

Cela ta snaha bootloaderu si sahat do ciloveho rootfs kvuli grub modulum, fontum nebo pozadi, je opravdu pitoma. Takze pak v grub.cfg mate dvoje UUID (neco je /boot a neco je /) nekolikrat zopakovano.. jako proc probuh? Vzdyt to umi promenne, tak nejsou schopni to tam nadefinovat na pocatku jenom jednou? Protoze zpusob jakym se config generuje je, ze se vezme ta sama sablona a iteruje pres existujici kernely.. argumenty se opakuji.

U me je bootloader neco, co pouzivam jednou za rok, nebo dva, takze nejake snahy o frikulinska vylepseni jdou mimo me.

Spis to vidim na vykoumani moznosti direct bootu kernelu z EFI, jen je treba slepit par veci dohromady (image+karg+i­nitrd+efiloader).

Buď vám to vygeneruje instalátor, pak to zopakování je jedno, nebo to máte vlastní (upravené) a pak tam máte ty proměnné, ne?
Kromě toho se mi zdá (ale podívat se teď nemůžu), že Ubuntu používá proměnnou $root, rozhodně v EFI/ubuntu/grub­.cfg:

search.fs_uuid ed93914f-....-61f46fcb7f12 root
set prefix=($root)'/bo­ot/grub'
configfile $prefix/grub.cfg

Nemam ubuntu, a instalator k instalaci linuxu jsem nepouzil snad 20 let :)

@RDa
Spis to vidim na vykoumani moznosti direct bootu kernelu z EFI, jen je treba slepit par veci dohromady (image+karg+i­nitrd+efiloader).

presne tak to dela automaticky Sicherboot zavadec ;-) tedy krome efiloaderu, ten je zvlast, resp. jde o systemd-boot...

navic ten "slepenec" (jadro+initrd+karg) podepise tvejma klicema (ktere hodis do uefi a puvodni smazes)...

Co jsou zač ty zkratky karg a efiloader? Ty 2 ostatní znám.
Přel léty j jsem s tím laboroval, aby mi fungoval Ach Linux jako přímo Efi "aplikace". Initrd nebyl potřeba.

@Sama Doma
karg = Kernel Arguments = startovaci parametry jadra
efiloader = EFI binarka pro BootLoader (napr. ten Grub)

to ze "initrd neni potreba" je pravda, ale jen do te chvile nez "initrd je potreba" ;-) napr.:
- rootfs v LUKS, Grub sice muzes mit nastaven ze se zepta na heslo a natahne si sve moduly, grub.cfg a kernel z fs v LUKS, nicmene natazene jadro uz o odemcenem LUKS nic nevi a je potreba initrd kterej odebceni zaridi (zadani hesla lokalne, pres ssh, ...)
- naborenej rootfs, s initrd mas oklestenej system z ktereho muzes provest opravu rootfs

Proč nejde použít dd pro kopii disku s GPT? Samozřejmě nemluvím o následném provozu obou disků ve stejném stroji...

Protoze na konci disku ma kopii partition table. A kdyz nesedi, tak to ma tendenci padat do nejakeho divneho stavu (a la.. objevi se v editoru protective mbr, namisto gpt rozlozeni).

Jde delat DD jenom celych a stejnych disku, coz neni to, co delam kdyz delam rychly klon z aktualne bezici instalace, viz:

umount /boot
dd if=SRC of=DST bs=1M count=300 # kopie MBR, /boot a kousek /
fdisk DST
- remove partition 2
- create partition 2
mkfs.ext4 DST2
mount DST2 /new
mount -o bind / /old
cp -a /old/* /new
+ editace fstab s novym UUID pro /
umount /new /old
+ editace grub.cfg s novym UUID pro / (v DST1)

Grub2 pridava nutnost zmenit uuid pro /boot at se lisi od puvodniho, a musim delat chroot, coz vyzaduje dalsi mounty abych dal ciste grub-update pod novym systemem... a jeste kdyz je tam i uefi, tak potes.

s Grub1 jsem krasne zmenil jedno uuid na real_root= a bylo, ten konfigurak je proste cistejsi.

Pokud se nepletu, tak ta záložní partition table GPT na konci disku se dá pomocí gdisk opravit.

Tu je potreba si davat velky pozor na UUID filesystemu.
Grub obsahuje zaznamy UUID filesystemu v /boot/grub/grub­.cfg, tie sa tam vygeneruju pri update grub.

V pripade ze pouzivat napriklad restore/dump utilitu je potreba pri vytvarani filesystemu mu to UUID vnutit aby bolo rovnake.

To iste v pripade windowsov tam sa zase odkazuje na partition uuid takze to je potreba si tiez postrazit.