Kan GRUB indlæse GRUB?

Når jeg har prøvet at installere systemer med dual boot mellem forskellige Linux versioner har et af de største problemer jeg har haft været, at de overskrev hinandens GRUB installationer og ikke var særligt gode til at boote andre Linux installationer.

Derfor har jeg fået den tanke, at jeg gerne vil give hver installation deres eget /boot directory som de helt selv er herre over (og som de andre Linux installationer ikke engang er klar over eksisterer).

Nu er mit problem hvordan jeg får bootet et af de systemer som har et /boot directory, men ingen bootloader. Jeg har derfor overvejet at have en separat GRUB installation, som bliver indlæst af BIOS og lade denne GRUB installation have en menu, som blot giver mulighed for at boote en af den andre GRUB installationer.

Kan det lade sig gøre? Jeg har ikke kunnet finde nogen dokumentation på området. Mine forsøg på at søge efter det har kun ført mig frem til beskrivelse af chainloading, som ikke ser ud til at dække mit behov.

Jeg kender ikke GRUB så godt, men bootloadere som eks. u-boot har ikke noget problem med den slags. De to "loads" kræver dog (sandsynligvis) forskelligt kode. Men da GRUB (sandsynligvis) også understøtter andet end elf images, så burde det ikke være et problem at udskifte din "load_elf"-kommando med en "load_baremetal" i din GRUB.

Og ellers kunne du da eks. installere u-boot som første bootloader.

Men hvis jeg var dig, ville jeg dog nok bare installere de ekstra *nix'er som virtuelle maskiner og så komme videre i dagsordenen. ^^

illishar (2) skrev:

Jeg kender ikke GRUB så godt, men bootloadere som eks. u-boot har ikke noget problem med den slags.

Jeg kender intet til u-boot, så jeg ved ikke om det vil være nemmere at sætte mig ind i u-boot fremfor blot at prøve mig frem med GRUB indtil jeg finder en løsning.

Det lykkedes mig nu at finde frem til følgende:

http://www.gnu.org/software/grub/manual/html_node/Images.html skrev:

This image may be placed at the start of the core image in order to make GRUB look enough like a Linux kernel that it can be booted by LILO

Hvis det resulterende image kan bootes af LILO, så kan det sikkert også bootes af GRUB. Men jeg vil først prøve om core.img kan indlæses direkte som en kerne eller med multiboot.

Et par links mere som giver mig forhåbning om at det kan lykkes:
https://wiki.archlinux.org/index.php/GRUB2#Generate_core.img_alone
http://ubuntuforums.org/archive/index.php/t-1682253.html

Jeg kan ikke lige gennemskue om den grub-install kommando som det første link foreslår er nødvendig, eller om den core.img der genereres som default også vil virke. Og jeg har ikke specielt meget lyst til at køre den kommando, da jeg ikke ved om den resulterer i et system, der ikke kan boote.

Jeg testede

multiboot /boot/grub/core.img
boot

og det bootede den samme GRUB installation igen som ønsket. Så nu må jeg igang med at sætte to uafhængige boot directories op og se om jeg kan boote mellem dem. Noget i retning af:
/boot/grub
/karmic/boot/grub
/lucid/boot/grub
/natty/boot/grub
/precise/boot/grub

Så fik jeg det faktisk til at virke. Indtil videre kun med et klon af min eksisterende Ubuntu Natty installation. Så nu kan jeg dualboote Ubuntu Natty og Ubuntu Natty. Så vil jeg prøve om jeg kan upgrade den ene til Precise.

Det gik ikke helt godt fra kommandolinien:

kasperd@fit:~$ ssh root@elysion-u1
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-15-generic i686)

* Documentation:  https://help.ubuntu.com/

New release 'oneiric' available.
Run 'do-release-upgrade' to upgrade to it.

Last login: Tue May  8 15:12:47 2012 from fit.local
root@elysion-u1:~# do-release-upgrade
Checking for a new ubuntu release
No new release found
root@elysion-u1:~# 

kasperd (6) skrev:

Det gik ikke helt godt fra kommandolinien

Og det var så fordi jeg havde ændret en konfigurationsindstilling gennem det grafiske interface.

Da det grafiske interface tilbød mig at opgradere fra 11.04 til 11.10 men ikke at opgradere til 12.04 havde jeg prøvet at fortælle den, at den kun skulle foreslå opdateringer til LTS udgaver.

Det viser sig at den indstilling er fuldstændig defekt hvis man ikke allerede kører en LTS udgave. I stedet for at tillade opdatering til næste LTS udgave forhindrer den helt at man opdaterer.

Efter jeg ændrede indstilling tilbage lykkedes det mig at opgradere fra 11.04 til 11.10 og derefter kunne jeg opgradere fra 11.10 til 12.04, begge dele med do-release-upgrade kommandoen. Så mangler jeg bare at finde ud af hvordan man installerer en grafisk brugerflade på Ubuntu 12.04, men det har ikke meget med den her tråd at gøre.

Undervejs fandt jeg ud af at det er nemt nok at tilføje et multiboot menupunkt til Ubuntus GRUB installation og få det bevaret på tværs af opgraderinger. Man skulle bare tilføje et par linier til /etc/grub.d/40_custom

set timeout=30

menuentry 'Main menu' {
multiboot /boot/grub/core.img
}

Det var i øvrigt meget praktisk da do-release-upgrade overskrev den bootblock der havde indlæst GRUB fra mit /boot directory. Måske skal jeg bare satse på at bruge multiboot /.../core.img til at skifte mellem hver installations GRUB og så lade være med at have en indledende GRUB installation til at vælge mellem dem.

Ubuntu har stadig ikke support for at starte med et roddirectory der er et subdirectory af en partition, så jeg er stadig nødt til at tilføje 12 linier til /usr/share/initramfs-tools/init for at få den del til at virke. Men nu har jeg en bedre fornemmelse af hvordan det hele virker, så jeg kan lave en bedre patch der automatisk finder ud af hvilket directory den nuværende rod er mountet fra.

kasperd (7) skrev:

Så mangler jeg bare at finde ud af hvordan man installerer en grafisk brugerflade på Ubuntu 12.04

apt-get install gnome-shell

Jeg indser lige, at verden nok er komet videre end grub1, og du derfor nok sidder med grub2. Nedenstående er derfor nok aldeles ubrugelig.



Jeg er lidt træt, så muligvis misforstår jeg hvad der foregår, men for mig ser det ud som om du er i gang med den mest besværlige løsning, pga. den mildt sagt elendige grub dokumentation.
Jeg erindrer dengang jeg morede mig med at multiboote Linux, Windows, Haiku, SkyOS, og Syllable. Tro mig, en grub kunne ikke klare dem alle... Sådan som jeg læser det, så har du valgt IKKE at chainloade dem, men det ville have været den simpleste løsning.
Alle dem der skal have sin egen, får den installeret på deres egen partition (root (hd0,x) + setup (hd0,x)), og en af dem lader du så være master, den sætter du til at boote sit egen system, samt chainloade de andre. Nøglen til success, er at droppe alt om at håndtere grub fra sit OS, men i stedet bruge gøre det i dens egen "shell", når den starter, men inden man loader et OS.
Hvis det har interesse, kan jeg nok forsøge at komme med et mere detaljeret svar, sådan som du plejer at være flink til :-)

BurningShadow (9) skrev:

Sådan som jeg læser det, så har du valgt IKKE at chainloade dem, men det ville have været den simpleste løsning.

Grunden til jeg ville undgå chainloading er at så vil den næste GRUB der bliver indlæst mig bekendt også være afhængig af en blokliste. Og hvis alle GRUB installationerne vil have deres blokliste liggende på nøjagtigt samme område af disken går det galt.

At indlæse den næste core.img med multiboot kommandoen er ikke mere besværligt. Det er faktisk meget nemt når man først ved hvad det er man skal gøre.

BurningShadow (9) skrev:

Alle dem der skal have sin egen, får den installeret på deres egen partition

Så mange partitioner har jeg ikke. Den computer jeg er i gang med nu er fra fabrikken partitioneret med en ext4 partition og en swap partition, og det er alt.

Jeg ser ingen grund til at repartitionere den, for alle de gange jeg har valgt at fordele diskpladsen på en computer på flere partitioner ender det altid med at vise sig, at jeg har brug for pladsen på andre partitioner end der hvor jeg forventede.

I stedet kører jeg alle installationer fra samme partition. På den måde har jeg ikke noget problem med fordeling af diskpladsen.

Flere installationer fra samme partition har været understøttet siden Linux 2.4.

BurningShadow (9) skrev:

Nøglen til success, er at droppe alt om at håndtere grub fra sit OS, men i stedet bruge gøre det i dens egen "shell", når den starter, men inden man loader et OS.

Jeg bruger tit GRUB kommandolinien til at boote et system som jeg har fået ind i en tilstand hvor standardkonfigurationen ikke længere kan bootes. Men at faktisk ændre noget fra GRUB kommandolinien finder jeg til gengæld besværligt, så er det altså nemmere at boote op og lave de ændringer man har brug for. Specielt hvis man bruger software RAID er det vigtigt da GRUB mig bekendt ikke spejler ændringerne, så hvis man ændrer noget direkte fra GRUB vil spejlet ikke længere være synkroniseret.