Pro toho komu v Debianu stále řádně nefunguje dual-boot, by mohla být užitečná tahle stránka. missing os-prober Po aplikaci informací zde zjištěných, už se člověk nemusí starat o konfiguráky Grubu2 při každé druhé aktualizaci.
Tak tak, například boot z RAID1 je přes něj daleko jednodušší.
Výměna Grubu (2) je v Debianu docela snadná, stačí odinstalovat (a purgenout, ať nezůstává nepořádek v /etc/) grub + závislosti, pak nainstalovat lilo, ručně vytvořit nebo vygenerovat config (tady mám výtku; proč prostě sakra neposkytnou nějaký „default“?).
Tohle je zatím celkem bez problému, ale pod odinstalaci update-grub se trochu pokazily hardcoded skripty pro kernel update (které předpokládají, že tam ten grub prostě bude). Naštěstí update symlinků na současný/old kernel v / je mimo update-grub, tudíž stačí jen malý tweak /etc/kernel-img.conf (myslím) a update-grub změnit na lilo (nebo prostě smazat a aktualizovat lilo ručně).
Od té doby mi server bootuje z RAID1 bez problému, update kernelu nesahá na lilo.conf, jen updatuje symlinky (což mi vyhovuje) a já jsem happy. Snad bude LILO žít ještě nějakou dobu, mám rád malé a účelné utility.
Ne, protože (pokud vím) ani filesystem driver nenačítá. Ona ta filosofie a způsob použití je někde jinde – místo řešení, proč instalátor nového kernelu něco pokazil (což, alespoň u grub1, nešlo nějak snadno spolehlivě ověřit) a bát se o boot, je snazší tomu předcházet – pokud „spustím“ lilo binárku, mohu krásně vidět, co se bude bootovat. Jinými slovy se tento seznam netvoří až při bootu, ale předem.
Ohledně smazání image – je takový „rule of thumb“ – zachovávat si vždy alespoň jedno funkční jádro jako fallback. Když už jsme u toho, taky můžu omylem udělat „dd if=/dev/zero of=/dev/hda bs=512 count=1“ na špatném disku a nevšimnout si toho, pak mi ani Grub nepomůže. To stejné, pokud omylem smažu jeho stage 1.5 (nebo – v případě Grub2 – přesunu root LVM partition na trochu jiné místo na fyzickém disku a neupdatuji stage1).
Jednodušše řečeno – stačí mi před shutdownem spustit „lilo“ a hned vidím, co se bude/nebude bootovat při dalším startu (někteří z nás to mají v shutdown skriptech). U grubu nic podobného neznám, používal jsem jen jedničkovou verzi, možná dynamicky generovaný config u Grub2 má nějaké kontrolní skripty (jiné, než [ -f $path_to_image]). Na druhou stranu, nebere tahle závislost na generačních skriptech ten pocit nenutnosti aktualizovat bootloader po změně configu, kvůli kterému kdysi hodně lidí přešlo na Grub? :)
Osobně nejsem odpůrce nových technologií, pokud jdou efektivním směrem. Limitace MBR jsou velké, ale .. filesystem drivery v zavaděči? To je jako filesystem drivery v LVM. Nebo znásilňování webového prohlížeče, aby spouštěl javascriptový OS :)
No ja nepochybujem. Minimalne v ubuntu ma k rucnej editaci konfigurakov grubu nepusti. A to ani pod rootom. Pozeral som na to ako blazon :D, no ked som zistil ako jednoducho sa generuju nastavenia pomocou tych scriptov, tak to bolo fajn. Hlavne pri castych zmenach sa to oplati narozdiel od rucnej editacie.
ALE, cokolvek s oznacenim BETA by som nerval do stabilnych distribucii.
GRUB2 mi robil iste problemy, ktore vsak nedokazem dostatocne odborne a podrobne popisat a zaroven nevyzerat ako idiot :D