Názory k článku Záchrana nebootujícího Linuxu pomocí konzole zavaděče GRUB 2

Samotná inštalácia GRUBu mi už viackrát zachránila aj nebootujúce Windows. Po hodinách trápenia sa s bootloaderom Windows (nie som Windows expert).

prijemny clanok, dakujem. S Vasim dovolenim si ho odlozim, lebo jedneho pekneho dna ma moze dostat z pruseru ;-)

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.

Pokud je potřeba aby GRUB2 dělal opravdu to, co má, je nejlepší mu to napsat přesně a jednoduše - přímo do /boot/grub/grub­.cfg. Takto např. vypadá můj:

set default=0
set timeout=5

menuentry 'Linux 5.15.16-gentoo-WiFi sda4 /root' {
  linux /kernel-5.15.16-gentoo-WiFi root=/dev/sda4 rootflags=subvol=/root ro
}

menuentry 'Linux 5.10.76-gentoo-r1-WiFi sda4 /root' {
  linux /kernel-5.10.76-gentoo-r1-WiFi root=/dev/sda4 rootflags=subvol=/root ro
}

menuentry 'Linux 5.10.76-gentoo-r1-WiFi sda4 /root-backup' {
  linux /kernel-5.10.76-gentoo-r1-WiFi root=/dev/sda4 rootflags=subvol=/root-backup ro
}

menuentry 'Linux 4.12.5-gentoo sda4 /root-old_system' {
  linux /kernel-4.12.5-gentoo root=/dev/sda4 rootflags=subvol=/root-old_system ro
}

menuentry 'Linux 4.19.27-gentoo-r1 sda2 (backup)' {
  linux /kernel-4.19.27-gentoo-r1 root=/dev/sda2 ro
}

menuentry "memtest86+ 5.01-r4" {
  linux16 /memtest86plus/memtest
}

Jinak díky za přehledný popis jak z příkazového řádku grubu najít kernel a nabootovat.

Hezky clanek, jen bych doplnil, ze kdyz skoncite v grub rescue, tak cesta do normalniho grubu vede pres dva prikazy

insmod normal
normal

tedy natazeni modulu normal a potom zadani prikazu normal.

Prestim je jeste obvykle potreba nastavit cesty, typicky neco jako

set root=(hd0,1)
set prefix=(hd0,1)/grub

druhy radek plati pro lidi co maji samostatnou boot partiton, pokud ji mate spolecnou s korenovym filesystemem bude syntaxe

set prefix=(hd0,1)/­boot/grub

Kdyby totiz grub ty cesty znal/mel spravne, tak neskonci v grub rescue, ale az pri natahovani konfigurace nebo dokonce az ve fazi, kdy v konfiguraci ma kernel, ktery neni na disku pritomen.

Aha, já jsem myslím dělal "configfile cesta/k/grub.cfg", což mi menu zobrazilo a pak šlo normálně nabootovat. Ale zkusím příště i normal :)

Tak na 95% pokud reagoval na prikaz configfile, tak uz mel ten modul normal natazeny.

Ono se to bude jeste lisit podle toho, jestli se startuje pres UEFI nebo klasicky, protoze do EFI partiton se vejde daleko "lepsi" grub nez kdyz se pouzivaji diry na disku za MBR.

Installing for i386-pc platform.
BTW: to asi nebude na GPT disk s tim EFI oddilem, leda ze by ten prvni oddil co ma 1MB nebyl swap, ale bios_grub kterej se prave pouziva na GPT disku pro instalaci Grubu pro Legacy/BIOS ;-)