[Partitionnement] Partition pour /boot/grub

[Feng]

Slt,

J'me demandais si c'était possible de créer une partition pour /boot/grub , comme ça y'a pas de mélange des kernel et des init ram disk dans le dossier /boot .

ça donnerait donc :

Partition 1 : /boot/grub
Partition 2 : /home
Partition 3 : / (archlinux)
Partition 4 : / (autre distro)

Comme ça peut importe la distribution que tu installe t'es tranquille, et ensuite tu ajoute l'entrée à grub.cfg

Right or wrong ? Et au niveau du grub.cfg ça donnerait quoi ?

Code : Tout sélectionner

menuentry "Arch Linux" --class archlinux --class gnu-linux --class gnu --class os {
        insmod ext2
        set root='(hd0,3)' <=== 3 pour ARCHLINUX
        search --no-floppy --fs-uuid --set 8c1f1c7e-4db0-4664-a28c-9c64405c7259
        echo    Loading Linux vmlinuz26 ...
        linux   /vmlinuz26 root=/dev/disk/by-uuid/8c1f1c7e-4db0-4664-a28c-9c64405c7259 ro  quiet
        echo    Loading initial ramdisk ...
        initrd  /kernel26.img
}

menuentry "Arch Linux" --class ANOTHERDISTRO --class gnu-linux --class gnu --class os {
        insmod ext2
        set root='(hd0,4)'  <=== 4 pour UNE AUTRE DISTRO
        search --no-floppy --fs-uuid --set ANOTHER_UUID
        echo    Loading Linux vmlinuz26 ...
        linux   /IRM_OTHER root=/dev/disk/by-uuid/ANOTHER_UUID  quiet
        echo    Loading initial ramdisk ...
        initrd  /KERNEL_OTHER.img
}

[chipster]

ton sujet stp

[Feng]

Comme ça chef ? (si oui, efface nos messages pour la postérité )

[oktoberfest]

Hello,

je connais que grub1 mais je vais quand même poser la question ... où sont tes noyaux ?
Parce que tu parles d'une partition pour /boot/grub, mais les fichiers qui sont normalement dans /boot (chez moi les noyaux et les initrd) tu les mets où... ?

[FoolEcho]

Et au niveau du grub.cfg

Grub2 donc.

J'me demandais si c'était possible de créer une partition pour /boot/grub

Oui, aucun doute.

Parce que tu parles d'une partition pour /boot/grub, mais les fichiers qui sont normalement dans /boot (chez moi les noyaux et les initrd) tu les mets où... ?

On les trouvera ici:
Partition 3 : / (archlinux)
Partition 4 : / (autre distro)

Ce qui devrait impacter ton code de la façon suivante, car tu n'as plus de partition /boot dédiée,il faut donc la déclarer :

Code : Tout sélectionner

menuentry "Arch Linux" {
        set root='(hd0,3)' <=== 3 pour ARCHLINUX
        linux   /boot/vmlinuz26 root=/dev/disk/by-uuid/8c1f1c7e-4db0-4664-a28c-9c64405c7259 ro  quiet
        initrd  boot/kernel26.img
}

Même chose pour chaque nouvel OS (ou tu fais une partition /boot dédiée à chaque distribution en plus de ton /boot/grub commun... toujours pour des soucis de récupération d'OS en cas de pépin -- ça me gène d'avoir /boot compris dans les partitions 3 et 4 sachant qu'il existe un /boot/grub ).

[Feng]

Ok donc c'est précisement comme je le pensais.
Cependant, j'ai un doute sur le fait qu'il y ai besoin de préciser "/boot"
Tu as écris :

Code : Tout sélectionner

linux   /boot/vmlinuz26 root=/dev/disk/by-uuid/8c1f1c7e-4db0-4664-a28c-9c64405c7259 ro  quiet

D'habitude on fait :

Code : Tout sélectionner

linux   /vmlinuz26 root=/dev/disk/by-uuid/8c1f1c7e-4db0-4664-a28c-9c64405c7259 ro  quiet

Or vmlinuz26 est situé dans le dossier /boot et on ne le précise pas.

D'autres pas, comment puis-je changer (quelle procédure) ma configuration pour passer à cette "structure" d'installation ?
Mon partitionnement actuel est le même que celui énoncé plus haut, à ceci près que la première partition est monté sur /boot

Mon hypothèse :

Boot sur un livecd
Changement du fstab pour monter /dev/sda1 sur /boot/grub
Déplacement du répertoire /boot sur /dev/sda3 (je n'ai que archlinux d'installé actuellement <3 )
Déplacement du répetoire /dev/sda3/boot/grub vers /dev/sda1
Modification de grub.cfg pour booter correctement
Reboot


J'vais tester tout de suite, je vous tiens au jus !

[FoolEcho]

Or vmlinuz26 est situé dans le dossier /boot et on ne le précise pas.

Précisément... mais d'habitude le menu.lst ou grub.cfg travaille sur la partition /boot... Or tu travailles sur /boot/grub, donc Grub ne connaît pas /boot et ne trouvera jamais tes images ou noyaux puisque situés sur tes partitions systèmes. Comme je n'étaye pas sans preuve, je te renvoie à la doc, fin de section: http://wiki.archlinux.org/index.php/GRU ... quet_GRUB2

Mon partitionnement actuel est le même que celui énoncé plus haut, à ceci près que la première partition est monté sur /boot

Je ne suis pas certain d'avoir pigé. Tu placeras un /boot commun à tes systèmes d'exploitation sur ta clé ? Côté maintenance, ça va devenir... pas très simple, d'autant que tes noyaux ne seront propres qu'à ton installation interne... donc je ne vois pas trop pourquoi les trimbaler. Trimbaler un OS complet, ok. Trimbaler un /home, ok...
M'enfin, pourquoi pas ? ... ça doit se définir comme le reste, par l'UUID de la clef usb pour être sûr.

[Feng]

Après test, ça ne fonctionne pas.

FoolEcho :

/dev/sda1 => /boot
/dev/sda2 => /home
/dev/sda5 => / (archlinux)
/dev/sda6 => (rien)

Maintenant je veux installer Ubuntu 10.04 sur /dev/sda6, parce qu'on en parle tellement que je veux le tester en conditions réelles.
Si je définie /dev/sda1 à monter sur /boot , ce mongol va écraser mon installation de grub2 , et va foutre son kernel et son IRD dans /boot , et imaginons que j'installe une distribution qui utilise kernel26 comme nom de fichier pour son IRD et vmlinuz26 pour son kernel . Ben ça écrase les fichiers de arch et t'as l'air con

Cela étant, après plein de test (je n'ai pas arrêté les essais depuis l'heure de mon précédement post, pour vous dire si j'ai testé dans tous les sens ...), ce n'est pas possible, car grub-install créé automatiquement le répertoire /boot/grub, or si on veut monter /dev/sda1 sur /boot/grub, il faut que la partition contienne directement le contenu du répertoire. J'ai essayé de passer par un bind après montage sur /mnt, mais la impossible de boot, grub cherche toujours le kernel dans la partition où il est installé.
J'ai fais beaucoup de tests, et me suis pas mal embrouillé l'esprit, il y a donc de forte chance que j'ai loupé quelque chose, si quelqu'un a une vraie solution, je suis preneur, n'hésitez pas à me MP même si vous lisez ce post dans 6 mois.

[FoolEcho]

Après test, ça ne fonctionne pas.

Un peu trop générique comme constat. Qu'as tu testé et comment ?

Si je définie /dev/sda1 à monter sur /boot , ce mongol va écraser mon installation de grub2 , et va foutre son kernel et son IRD dans /boot , et imaginons que j'installe une distribution qui utilise kernel26 comme nom de fichier pour son IRD et vmlinuz26 pour son kernel . Ben ça écrase les fichiers de arch et t'as l'air con

De mémoire (j'avais fait "jadis" une triple installation Windows/Mandriva/Ubuntu)... donc à prendre avec des pincettes... l'installateur d'Ubuntu sautait la Mandriva en faisant son boui-boui dans son coin effectivement. J'avais du adapté les menu.lst (grub1) de Mandriva et Ubuntu, et placé dans le secteur d'amorçage le chargement de celui d'Ubuntu puis chaîner . En même temps, comme je suis parano, j'avais un /boot pour chaque système, comme ça au pire je réinstallais le secteur d'amorçage depuis l'un ou l'autre.

L'un dans l'autre, la gestion de ces différents systèmes te posera des soucis de maintenance. Je vois deux alternatives:
1) ma préférée: un /boot dédié à chaque système que tu ajoutes. Ce n'est pas la place que ça prend. Comme ça tu n'as aucun souci ou inquiètude sur des risques d'écrasement de noyaux. Après il te suffit de chaîner tes systèmes comme tu veux (exactement comme c'est fait pour Windows avec chainloader) et de dire à grub lequel placer dans le secteur d'amorçage (les autres seront placés ailleurs, au plus simple sur la partition propre au boot concerné). L'inconvénient étant d'avoir à retoucher les menus de Grub des autres systèmes selon le besoin (bon après, même Arch n'a pas des mises à jour de noyaux toutes les semaines).
2) à mon avis injouable: un /boot commun. Ce qui oblige effectivement avant toute mise à jour de kernel à conserver l'état du boot précédent... puis remettre les entrées et noyaux qui t'intéressent... ça oblige à scripter à mon avis et à blinder vu que c'est sensible. D'autant que la partition /boot n'est pas trop faite pour être chatouillé trop souvent.

Selon ta définition, je verrais plutôt:
/dev/sda1 => /boot (archlinux) -- à charger dans le MBR via grub-install --à modifier pour chaîner sur boot annexes
/dev/sda2 => /home (commune)
/dev/sda5 => / (archlinux)
/dev/sda6 => (rien)
Donc tu étends ensuite sda6 sur le modèle d'après:
/dev/sda6 => /boot (autre OS) -- non inclu dans le MBR mais sur la partoche sda6 de façon à chaîner depuis grub.cfg de Arch
/dev/sda7 => / (autre OS)

Par contre, je ne sais plus si un /boot passe bien sur des partitions étendues. A voir.

[Feng]

Faut que je réfléchisse à ce qui est optimal.
Chacun son boot j'aime pas trop parce que dans les fait, grub est lié à un système
Boot commun, on connait le pb : écrasement de fichiers...
Cela dit, je vois pas l'intérêt de faire une partition boot, si c'est pour ne pas la partager. Lors d'une mise à jour de kernel (pour arch on est tranquille il garde le même nom) je changerai le grub.cfg pour en profiter, et peut-être que la distro sera doté d'un système de merge comme Ubuntu.

[FoolEcho]

Chacun son boot j'aime pas trop parce que dans les fait, grub est lié à un système

Justement. Si tu as deux systèmes qui n'utilisent pas la même version de Grub, ça pourrait poser problème d'avoir un boot unique.

Après, je ne sais. Déformation professionnelle, je pense comme un développeur objet. Cela me paraît plus simple et maintenable de gèrer des boots indépendants plutôt qu'une partition qui va tout regrouper. D'autant que la faculté d'installer les secteurs d'amorçage où tu veux est l'atout à utiliser, à mon avis.

Ainsi, tu as ton boot principal installé dans le MBR qui chaîne les autres qui eux, sont installés sur tes autres partitions.

D'autant que si dans les faits tu veux supprimer un OS auxiliaire pour une raison ou une autre, c'est plus facile à gèrer par des petits boots séparés.

Argument supplémentaire: je ne vois pas pourquoi tel ou tel système devrait connaître tous les autres (re-déformation objet), ou au moins la façon de les amorcer (kernel, etc) (en dehors du fait qu'il sait comment trouver tel ou tel autre secteur de boot via chaînage ou non, et ça c'est très objet ). Imagine une fausse manip sur l'un de tes systèmes avec ton boot unique... au hasard lorsque tu vas mettre à jour ton noyau ... *paf* accidentellement tu supprimes l'un des autres noyaux. Avec une organisation en plusieurs partitions boot, tu réduis ces risques.

Argument principal: D'ailleurs c'est bien comme ça qu'est géré le double amorçage Windows/Linux: chaînage depuis le Grub installé par Linux dans le MBR sur le chargeur de Windows...

[Feng]

@FoolEcho : moi aussi je pense comme un développeur objet lol, Archlinux et Ubuntu héritent de Boot :p
J'le vois comme ça ^^

[FoolEcho]

Archlinux et Ubuntu héritent de Boot

Pas pour moi. En première approche, ils hériteraient de OS... Boot héritant de Bootloader avec une méthode l'autorisant à charger telle ou telle amorce. Le chargement en question consistant à interroger une OSFactory, laquelle se débrouille pour générer le bon OS... et donc éventuellement ça consiste à interroger un autre Boot en cas de chaînage.
Même si on peut considérer que Boot et OS sont des Executables au niveau interface.

Sur ces considérations qui ne font pas avancer le schmilblick... Evidemment, j'insiste ainsi sur la question de chaîner les amorces et donc de partitions boot séparées... Je trouve ça nettement plus souple que de trifouiller sans arrêt un même boot avec tous les risques que ça implique.

Tiré de la doc d'Ubuntu, justement: http://doc.ubuntu-fr.org/grub#grub_comm ... hainloader
"C’est la façon la plus simple et la plus sûre pour lancer d’autres systèmes Linux car ils restent ainsi indépendants, et ne viendront pas compromettre votre système principal. " (ça n'engage que l'auteur tu me diras... mais je t'ai présenté les arguments qui vont, selon moi, dans ce sens)

Ceci étant dit, je comprends que tu ne veuilles utiliser qu'un Grub commun à tous (j'aime bien utiliser un objet à fond aussi )... mais bon, à mon avis, ça complique très sérieusement la stabilité des systèmes. En plus, j'aime pô réinventer la roue (objet.... objet...).

Après, bon, chacun fait comme il veut. Vive le monde libre.

[oktoberfest]

Hello,

tu peux sans problème avoir une partition de boot pour l'ensemble de tes systèmes. C'est ce que j'ai fait chez moi (enfin plus maintenant, je me suis fixé sur Archlinux et j'y reste).
Toute la subtilité consiste à avoir une partition de boot qui ne soit pas monté sur /boot !

En effet il faut bien voir que quand tu bootes, grub se fiche éperdument que ta partition qui contient ton noyau soit monté sur /boot ou /toto dans ton linux préféré. Ce que tu indiques à grub (via le menu.cfg) c'est une partition et un chemin dans cette partition pour trouver le couple noyau/initrd.

Ce que j'avais fait à l'époque c'était :
- sur sda1, un répertoire par os (/arch, /ubuntu, /ubuntu-x64, /lfs ...) et dedans je retrouve à chaque le noyau/initrd qui va bien (ainsi qu'un répertoire old).
- sur sda1, un répertoire /grub avec un menu.lst confectionné à la main qui me permet de booter sur mes différents os (plus des entrés pour booter sur des vieux noyaux stockés dans /arch/old, /ubuntu/old...)
- des partitions (ou dans mon cas des volumes LVM mais c'est pareil) avec mon archlinux, mon ubuntu 32 bits, mon ubuntu 64 bits, mon lfs... Chaque partition contient un répertoire /boot qui n'est pas monté.

A chaque mise à jour d'un système (ex : archlinux), les fichiers à jour se trouvent dans le /boot. Ensuite à la main je monte ma partition sda1 (par ex dans /media/boot) et je copie les fichiers de /boot vers /media/boot/arch. Auparavant j'ai copié le couple noyau/initrd de /media/boot/arch vers /media/boot/arch/old.

De cette façon tu as :
- une partition de boot unique -> Un seul menu grub pour choisir tous tes os
- des systèmes cloisonnés qui ne vont rien toucher dans la partition de boot, que ce soit le noyau, l'initrd ou le menu.lst.
- un contrôle total sur ta partition de boot. C'est à toi de copier dedans les noyaux qui t'intéressent.

L'inconvénient c'est que à chaque ajout d'os / mise à jour de noyau, tu as des manipulations à faire, mais au moins c'est toi qui fait les manip, pas un script automatique qui va toucher ce que tu ne veux pas.

[FoolEcho]

L'inconvénient c'est que à chaque ajout d'os / mise à jour de noyau, tu as des manipulations à faire

Je suis d'accord avec l'ensemble de ta façon de faire et ton constat, c'est faisable et ça marche... donc...

mais au moins c'est toi qui fait les manip, pas un script automatique

... c'est bien pourquoi je trouve que le chaînage des différentes amorces de chaque système (et donc plusieurs /boot ) a le gros avantage de ne pas avoir à retoucher quelque fichier que ce soit à chaque mise à jour de quelque kernel que ce soit. Dans cette optique, on a la panacée: ni intervention de soi-même, ni d'un système automatique (... mais rien n'empêche alors de monter/démonter les partitions au besoin à ta convenance). Je trouve l'esthétique et l'efficacité de l'ensemble plus adéquat (ok, avec le bémol de plusieurs booltloader... mais ça me paraît vraiment mineur, tous les systèmes n'utilisent pas Grub en plus).

J'aime pas avoir à mettre les mains dans le cambouis quand il n'y a pas nécessité.

Là où à mon avis ta solution n'est pas franchement viable c'est si tu ne pars pas d'un système vierge... Prenons un exemple concret: mon système actuel est en double amorçage Seven/ArchLinux. Le MBR s'amorce sur le Grub de Arch avec donc les entrées de Arch et le chaînage vers Seven.
Mettons que je me rajoute une partition pour installer un OS supplémentaire pour le tester en situation réelle (pas de virtualisation donc): je me fais de la place, j'installe le système sur ma/mes nouvelle(s) partition(s) avec son boot et tout le reste, et j'installe son amorce sur cette même partition. Puis je modifie le menu.lst (j'suis sous grub1, mais peu importe) de ArchLinux qui constitue mon amorce principale pour ajouter l'entrée de l'amorce de mon nouveau système et c'est tout.
Le truc le plus beau à mon sens: je change de système auxiliaire, tout ce que j'ai à faire, c'est à prendre garde à installer la nouvelle amorce sur cette même partition... Puis, j'ai quoi à faire côté menu.lst de Arch ? RIEN. STRICTEMENT RIEN. Car le chaînage reste valable. C'est pas beau, ça ?

[oktoberfest]

Je suis d'accord avec toi.

C'est au moins l'avantage de linux : chacun peut tordre son système pour qu'il fasse ce que l'administrateur a envie, et pas ce que le développeur de l'os a envie

Ensuite tout dépend de ce que chacun souhaite.
- Avec ma solution on a des manipulations à faire, mais un seul menu grub.
- Avec ta solution on a plusieurs menus de boot, mais de de manipulations particulières.

Il n'y a pas de bonne ou de meilleure méthode. La 'bonne' méthode est la méthode qui convient, qui fonctionne, qu'on comprend et qu'on arrive à dépanner en cas de problème !

[FoolEcho]

La 'bonne' méthode est la méthode qui convient, qui fonctionne, qu'on comprend et qu'on arrive à dépanner en cas de problème !

+1. Faut comprendre ce qu'on fait et pourquoi on le fait selon ce qu'on veut.

Allez, deux petits bémols à la méthode du chaînage quand même:
- si je veux du double chaînage je suis aussi "obligé" de modifier les configurations des systèmes annexes (qui souvent ne reconnaissent pas les autres systèmes installés d'emblée en dehors de Windows)
- ça me fait également plus de menu/sous-menu au boot.

[oktoberfest]

Dans le cadre de l'auto-flagellation, à mon tour de sortir deux inconvénients :
- si on fait un mauvais copier/coller on fout le bronx dans ces os
- et franchement, une fois ArchLinux installé... pourquoi installer d'autres distros

[Feng]

Le montage d'une partition dédiée à /boot/grub aurait concilié les deux : la sécurité de chacun son /boot, avec la simplicité d'un seul prompt.

@oktoberfest :

[FoolEcho]

Néanmoins, je ne vois pas ce qui t'empêche de faire ton /boot/grub.
Tu es sûr qu'en spécifiant sur les lignes linux et initrd avec la syntaxe /boot + KERNEL.img root=UUID_KERNEL_DISK tu n'arrives à rien ?

Code : Tout sélectionner

menuentry "Arch Linux" {
        set root='BOOT_ROOT' #par conséquent sda1 / 'hd0,0' dans ton exemple ?  mais est-ce vraiment utile en définitive ? o_O
        linux   /boot/vmlinuz26 root=DISK_BY_UUID_FOR_MY_DISTRIBUTION ro  quiet #donc sda5 (hd0,4) pour Archlinux pour toi 
        initrd  /boot/kernel26.img
}

Note que j'avais oublié un '/' sur le initrd de l'un de mes premiers posts... ce qui ne devait pas aider...
Alors maintenant, évidemment, le problème est que /boot est à cheval sur plusieurs partitions... donc en fait je ne sais pas si le premier set root est correct du coup... voire même utile parce que le menu.lst ou grub.conf a déjà été chargé par ton MBR et je ne vois pas son utilité par la suite...

A tester et voir où ça coince au cas où grâce à des "échos" ?