Dotaz: dualboot archlinux a openindiana

[radek]

Ahoj.

Jak nejlépe na dualboot ArchLinux (grub2) a OpenIndiana (grub legacy) ? Nebudou se mi mezi sebou různé verze grubu "tlouct" ???

Díky.

Odpovědi

[2015]

Já bych grub legacy vůbec neinstaloval a nechal grub 2 zavádět oba systémy (jádra).

[Andrej]

Taková možnost zatím neexistuje, bohužel.

[Andrej]

Nemusí se tlouct. Nejlepším řešením je použít chainloading, tj. nechat GRUB 2 jako hlavní bootloader nainstalovaný přímo na úvodních blocích disku a poté nainstalovat fosilní GRUB od OpenIndiany přímo do oddílu (nebo do jednoho z oddílů), kde OpenIndiana bude. Měl by to být primární MBR oddíl. (Jak by to fungovalo s GPT, to jsem nezkoušel.) GRUB 2 pak může mít v menu položku pro chainloading toho fosilního GRUBu, který bude dobře fungovat s OpenIndianou, tj. bude ukazovat seznam dostupných BE a podobně.

Poněkud krkolomný návod je zde. Když jsem já instaloval dual boot ArchLinuxu a OpenIndiany, prostě a jednoduše jsem nainstaloval ArchLinux a jeho GRUB 2 a nechal jsem prázdný oddíl pro OpenIndianu. Při následné instalaci OpenIndiany jsem pak nenechal bootloader zapsat přímo do úvodních stop disku, ale do oddílu (resp. před oddíl, podle toho, jak se to vezme) s OpenIndianou. Stačilo už jen přidat do GRUBu 2 položku pro chainloading a vše bylo vyřešeno. Ani náhodou jsem nemusel provádět nějaké podivné zápisy pomocí dd či něco podobného.

[lertimir]

Takhle jsem pracoval v době fosilniho grubu i s jinými distribucemi. Grub 2 si (většinou) najde správné jádra i u sekundárních distribucí, které ho neovládají a neinstalují. Stary grub tohle neumí a v případě více distribucí bylo třeba ošetřít, co se bude dít, když různé distribuce budou v různých časech aktualizovat svoje jádra. Řešil jsem to primárně tak, že jedna distribuce byla "hlavní", její grub byl v MBR, ostatní distribuce byly "sekundární", každá měla svůj grub ve svém root oddílu a z hlavního grubu jsem ten její volal chainloadingem podobně jako Win. Mělo to tu základní výhodu, že všechny aktualizace jader si sekundární distra ošetřily zcela korektně se svými gruby a případně si ve svých grubech udržovaly i seznamy starších jader, a jednu drobnou nevýhodu, že na sekundární distro se šlo přes dva gruby a člověk si musel uvědomit, kde v které chvili je.

Jinak v současnosti samotný dual boot považuji za fosilní záležitost a naprostou většinu věcí bych řešil virtualizací. V podstatě jedinný důvod, kdy vidím oprávění dual bootu je situace, kdy nutně potřebuji přímý přístup k HW a to mě kromě hráčů her a jejich přistupu ke výkonu grafiky, nic nenapadá, co by požadavek na dual boot dělalo tak nutným.

[Andrej]

V podstatě jedinný důvod, kdy vidím oprávění dual bootu je situace, kdy nutně potřebuji přímý přístup k HW a to mě kromě hráčů her a jejich přistupu ke výkonu grafiky, nic nenapadá, co by požadavek na dual boot dělalo tak nutným.

Jako diplomovou práci jsem implementoval RCU pro kernel (UTS) OpenSolarisu. Takže přístup k hardware sice nebyl (přísně vzato) stoprocentně nutný, ale KVM tehdy v multiprocesorech příliš nevynikal (mírně řečeno) a pro jakékoliv seriózní ověření funkčnosti a praktických výhod toho RCU byl bare metal v podstatě nutností. To by mohl být příklad situace (byť ne úplně obvyklý), kdy virtualizace nevyřeší úplně všechno.

Dual boot se ovšem vůbec nevylučuje s virtualizací. V mém případě to fungovalo následovně: Když jsem nabootoval do ArchLinuxu, sestavil se lineární RAID, který sestával ze souboru (loopbacku) s fiktivním MBR, následovala skutečná partition s OpenSolarisem a na konci byl zase soubor/loopback s další partition (čistě pro formu, aby sedělo číslování disků, pokud si to dobře pamatuju). Takže se OpenSolaris dal spustit normálně v qemu-kvm jako virtuální stroj s přímým přístupem na disk. Při přebootování systému se ovšem dal zvolit ten chainloading na fosilní GRUB a ten samý OpenSolaris z toho samého oddílu se tak dal nabootovat i přímo a bez virtualizace. Jenom se nesmělo zapomenout na touch /reconfigure, kdykoliv bylo potřeba přebootovat OpenSolaris „z virtualizace na opravdový hardware“ nebo naopak. Byla to velmi užitečná konfigurace, protože se dalo pracovat s novějšími vývojovými nástroji a s virtualizací přímo na Linuxu a podle potřeby občas nabootovat Solaris na opravdovém hardwaru, když šlo o benchmarky.

[Andrej]

Ovšem dlužno dodat, že to už je hodně dávno. OpenSolaris je už jen historie. Jenom se divím, že dodnes není pro takovou konfiguraci podpora v nějakém klikátku typu virt-manager, tj. možnost zvolit partition, ze které se má přímo nabootovat virtuální stroj, k té partition vygenerovat a lineárním RAIDem připojit fiktivní MBR nebo GPT a nakopnout z toho virtuální stroj.

[radek]

Moc dík.

Už to běhá, Nechápu, že mne chainloading nenapadl.... Virtualizovat jsem nechtěl, protože potřebuji přímý přístup k HW.