Forum debian-fr.org

Bonjour tout le monde!

J'ai voulu essayer grub2 dans le cadre de mon passage en ext4. Mais bon, j'ai eu un peu de mal à le configurer correctement. Vous auriez pas un tuto dans le coin par hasard?

Sur ce, bon week end!

_________________
debian wheezy + xfce ou dwm
mon site : http://yeuxdelibad.net
Aidez debian avec apt-p2p!

Pas de tuto sous la main, mais j'utilise grub2 depuis un moment (je suis en train d'en écrire un pour www.linuxpedia.fr , il sera prêt à la fin du w-e normalement...).

Quel est ton problème de configuration précisément ?

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

précisément, je ne pourrais pas te dire là, ça remonte à quelque semaine, et je l'ai finalement retiré.
J'avais surtout du mal à me faire avec la nouvelle syntaxe. Est-on obligé d'utiliser l'UUID des partitions? Puis comment remplacer grub par grub2 pour de bon?
Enfin, si tu fais un tuto je ferais partie de tes lecteurs!

_________________
debian wheezy + xfce ou dwm
mon site : http://yeuxdelibad.net
Aidez debian avec apt-p2p!

Lorsque tu installes grub2 il n'est pas activé par défaut, une entrée est ajoutée à ton menu.lst "chainload into..." pour tester que tout fonctionne, si ça plante tu retombes sur grub "vieux". Pour effectuer la bascule définitivement c'est "upgrade-from-grub-legacy" en root.

Les fichiers de conf sont dans /etc/default/grub et /etc/grub.d/* (ainsi que des modèles de personnalisation "templates") , le remplaçant du menu.lst s'appelle /boot/grub/grub.cfg.
La numérotation des disques change: grub "vieux" (hd0,0) = grub2 (hd0,1) ; donc les disques toujours numérotés à partir de zéro, les partitions à partir de 1.

Pour le reste, grub2 sait charger des modules (raid, lvm...) et rendre disponibles les volumes correspondant dès le menu, et un tas d'autres choses assez pratiques...

Tu n'es pas obligé d'utiliser les UUID, d'ailleurs tu peux désactiver leur usage dans /etc/default/grub :

GRUB_DISABLE_LINUX_UUID=true

Tu peux utiliser des labels dans le grub.cfg, mais la version de grub2 dispo chez Debian ne les supporte pas par défaut lors de la génération du grub.cfg (il faut que je vérifie ça après la dernière mise à jour de ce matin).
Pour régénérer le grub.cfg après modification c'est "update-grub2" ou "grub-mkconfig" avec les versions de Squeeze et au-dessus. Tu peux utiliser la notation "udev", par exemple chez moi "root=/dev/md0" (volume raid).

Enfin le paquet "os-prober" détecte tout seul comme un grand les autres systèmes d'exploitation installés.


Pour la suite, il faudra lire le tuto... (et contribuer après tes tests !)

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Eh bien merci, c'est un très bon début déja! je crois que je vais refaire le test de grub2 dans un avenir très proche!
Merci encore pour les précisions!

_________________
debian wheezy + xfce ou dwm
mon site : http://yeuxdelibad.net
Aidez debian avec apt-p2p!

j'ai refais les manips. je n'ai pas de soucis cette fois ci. j'ai réédité à la main, et je n'avais pas le message d'erreur de la dernière fois.
Ensuite, j'ai installé le paquet os-prober, et il suffit d'un update-grub2 et tout va tout seul!
Me reste plus qu'à peaufiner pour préciser le système de fichier et ainsi que la résolution de boot à la main (parce que j'aime bien savoir ce que je fais!)!
Merci encore pour ton mini-tuto

_________________
debian wheezy + xfce ou dwm
mon site : http://yeuxdelibad.net
Aidez debian avec apt-p2p!

La présentation est déjà pas mal avancée ici :

http://www.linuxpedia.fr/doku.php/expert/grub2

Commentaires, critiques et contributions bienvenus.

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

magnifique ça c'est un tuto
il est allé directement dans mes marque-pages
merci

_________________
amd64 x2 dual core 4200+ , ram 2 Gio ,nvidia N210
Wheezy gnome-shell 3.4-2 kernel 3.2.0-4
Antergos gnome-shell 3.8-1 kernel 3.9.2-ARCH

Salut,

En 1er lieu merci pour cet article.



Stage 1 pour Grub-legacy correspond au boot.img de Grub2, soit les 448 octets installés sur le MBR ou le BS d'une partition. C'est évidemment trop peu pour intégrer un shell lequel se trouve donc forcément ailleurs (/boot/grub/ ?).

woah, super complet! peut-être à mettre ici? :

http://wiki.debian.org/

_________________
debian wheezy + xfce ou dwm
mon site : http://yeuxdelibad.net
Aidez debian avec apt-p2p!

Tu as parfaitement raison, en fait ça concerne le core.img qui peut être situé dans /boot/grub, ou implanté ailleurs comme entre le secteur d'amorçage et le début de la première partition. Je vais parler de tout ça plus tard. Grub2 a supprimé le stage 1.5 de grub, je vais reformuler ça autrement.

Merci pour la lecture attentive !

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Donc core.img correspondrait en quelque sorte à stage 2 qui sur la majorité des systèmes¹ s'installe en partie sur les 63 secteurs suivant le MBR et l'autre partie dans /boot/grub/ ? Une des différences serai que core.img peut lui tenir entièrement dans cet espace libre ?

¹ Ceux dont le partitionnement du disque a été fait en arrondissant la limite des partitions aux limites de cylindre et ayant donc un espace libre après le MBR.

Tout bien réfléchit, et après avoir testé sur un système, le "rescue shell" se trouve forcément dans le stage 1, car même si l'adressage de la partition racine (qui contient /boot/grub dans le cas testé) n'est pas détecté (et même si le volume raid qui la porte n'est pas assemblé, y compris si j'efface /boot/grub !), et avec core.img et boot.img dans /boot/grub, le "rescue shell" est disponible.

Concernant le core.img, sur mes systèmes il fait 28K, je n'ai pas encore essayé de le mettre entre le mbr et la première partition sur un système déjà installé, mais ça ne va pas tarder... J'attends de pouvoir faire des tests plus complets pour ajouter une partie sur ces fantaisies au tuto.

Le problème c'est que Grub2 est horriblement mal documenté (surtout en Français), et même lorsque la documentation existe elle est parfois déjà périmée... J'ai découvert la trace de certaines options en parcourant les journaux des changements sur les dépôts de développement, et dans des rapports de bogues... c'est en partie ce qui a motivé la présentation.

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Pour approfondir un peu, et illustrer ce que dit le wiki de Grub2, (à savoir que grub2 a rendu non nécessaire le stage 1.5 de grub), voici un dump du mbr, et de la zone de compatibilité dos, sur un disque avec grub "legacy" installé, puis sur un disque avec Grub2 (avec core.img implanté dans /boot/grub):

Disque grub "legacy", MBR:



Secteur de compatibilité dos (utilisé par le stage 1.5):



Disque avec Grub2, MBR:



Zone de compatibilité DOS:



La zone de compatibilité DOS est entièrement libre, c'est là que peut être implanté le core.img. Si on fait ce choix le fonctionnement de Grub2 ressemble alors à celui de grub "legacy", avec une sorte de stage 1.5 en dehors du système de fichiers, mais ça n'est pas obligatoire. Le boot.img (situé sur le MBR) contient déjà suffisamment d'informations pour aller chercher le core.img sur le système de fichiers (même dans le cas d'une racine "/" sur un raid.).

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Salut,


Il ne l'était déjà pas avec Grub-Legacy.



Là tu as fait une erreur dans la commande : tu as affiché le 64ème secteur du disque, donc le BS de sdc1 (sur lequel un stage 1 a été installé ).
La commande dd bs=512 count=1 if=/dev/sdc1 | od -Ax -tx1z -v te donnera le même résultat.

Pour voir stage1.5 il faut utiliser cette commande (à adapter bien sûr) :


(count=17 est normalement suffisant mais il vaut mieux garder count=62 pour la suite...)

Ce qui donne (je n'ai gardé que les parties intéressantes) :


Il serait intéressant de voir ce que donne cette commande pour Grub2, je soupçonne fortement que core.img y ait été installé sans préavis...

Au vue de tout cela :


Je le répète, c'est impossible de par la taille du MBR, j'ai d'ailleurs parcouru les sources de Grub2, et en particulier /boot/i386/pc/boot.S (aka boot.img avant compilation) sans trouver trace d'un quelconque shell. Mais on va le trouver

Voici comment je vois la procédure :

1) Une machine virtuelle avec un système + Grub2 installé + vérification du fonctionnement et de la zone située entre le MBR et le BS de la 1er partition.
2) Suppression complète des fichiers relatifs à Grub2 (avec shred pour qu'il n'y ai plus de trace de ceux-ci). Il serait très intéressant ici de supprimer les fichiers un à un (en particulier concernant les fichiers importants comme core.img et de faire un essai de démarrage du système entre).
3) Suppression avec dd des 62 secteurs suivant le MBR.

À ce stade s'il on tombe encore sur le shell de Grub au démarrage c'est qu'il se trouve sur le stage1 (aka boot.img) du MBR, et s'il l'on tombait dessus avant 3) mais pas après c'est qu'il se trouvait dans le core.img de la zone de compatibilité DOS (1ère fois que je vois ce terme mais c'est de loin celui qui me parai le plus sensé)

À l'occase je ferai cette expérience.


Ça c'est clair...

PS. Je viens de voir que tu avais modifié la partie de l'article en question, cela me parai beaucoup plus juste ainsi.

Donc c'est juste du marketing de Grub2 ! Ou disons que ça reflète plus une différence de fonctionnement qu'une différence d'implantation du code




Merci de la correction, je découvre la vivisection de disque à coup de "dd" à l'occasion de ce sujet.

En utilisant la bonne commande on constate que Grub2 implante par défaut (en tout cas pour la version des paquets Debian) plus de code que grub "legacy", et répartis différemment.

Pour grub "legacy" j'ai du code sur les 320 premiers octets, puis du 496 au 7536 ème, et enfin du 31'789 au 32'160 ème.

Pour grub2, c'est pareil sur les 320 premiers (code différent), puis du 496 au 28'048 éme.

Ce que je ne saisie pas encore, c'est si le core.img est implanté de manière monolithique d'office sur le secteur de compatibilité DOS (vue l'espace occupé c'est probable), et s'il contient le module spécifique au type de boot (exp: diskboot.img, lnxboot.img), ou si seul diskboot.img (ou pxeboot.img ou autre en fonction du système) est implanté d'office, et appel core.img sur /boot/grub (ou ailleurs).
Ce qui est certain c'est qu'en plus du "rescue shell" un certain nombre de modules sont déjà chargé dès le première partie du boot (mais cette première partie excède le MBR). Un "lsmod" dans le "rescue shell" donne "_chain, biosdisk, raid (système sur raid), pc, ext2, fshelp (plus de 24'000 octets à eux tous), alors qu'à ce stade /boot/grub est encore inaccessible (variables "prefix" et "root" fausses).

Ce qu'il faudrait c'est pouvoir décompacter ou monter les images (core.img, boot.img, diskboot.img...) pour en examiner le contenu. Le problème c'est que lors de mes (brefs) tests je n'ai pas trouvé leur format, les habituels gunzip et cpio ne donnent rien, pourtant grub-common a une dépendance sur zlib avec Debian et liblzo avec Ubuntu. (montés en ramfs peut-être...).




Paraît intéressant, et assez long ! J'ai une machine virtuelle dispo où grub2 est installé, reste à trouver le temps...


Pour Thuban, je fais des tutos sur LinuxPedia parce que j'en avais un peu marre de jongler entre plusieurs forums destinés à différentes distributions (ou à la même !), et que je "connais" (virtuellement) certains des membres fondateurs. Si quelqu'un veut le mettre ailleurs ça n'est pas un problème, il faut juste voir quelle est la licence adoptée par LinuxPedia.
À l'inverse il y a plusieurs wiki propres à une distribution particulière qui "fusionnent" leurs wiki avec linuxpedia (je ne sais pas comment ça se passe en pratique).
J'aime bien l'idée d'une ressource francophone centralisée, type wikipediafr (pas spécifique) et QuebecOS, sur gnu-linux. Pas forcément une encyclopédie exhaustive, mais un "portail" avec des liens vers des wiki plus spécifiques si besoin.

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

À la vue des résultats je le crois aussi.
Cela dit stage1.5 à quand même l'avantage d'accélérer le démarrage de Grub, de ce que j'ai pu constater, sans lui, il y a un délai de plusieurs secondes entre le chargement de Grub et l'apparition de la liste des noyaux/OS. Maintenant je n'ai fait l'expérience que sur une machine alors je ne sais pas si l'on peut généraliser cette affirmation...



OK, je serai quand même curieux de voir le résultat



Je me demande aussi. Par contre, à mon avis, s'il y a une zone de compatibilité DOS sur le disque et de la même façon que pour stage1.5 il sera installé d'office.



Dans un 1er temps le point 2) peut se faire en une seule fois, du coup cela peut être assez rapide.

Je voudrais bien mettre le résultat ici, mais je n'ai pas trouvé de "codebox" sur le forum, ni aucune "boîte" avec des barres de défilement... Quand à joindre un fichier j'ai des erreurs "extension .txt non autorisée", ou "extension non autorisée"...

Si vous connaissez un service gratuit où je puisse coller 2000 lignes... J'ai le résultat sur une Debian Squeeze "en dur" sur raid (pas en vm), et une Ubuntu Hardy en vm sur raid également.

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Il y a bien un service qui permet de partager du texte mais j'ai oublié le nom...
Sinon tu peux mettre seulement ce qui est humainement compréhensible.

Celui de la Debian Squeeze : http://rafb.net/p/Zg66sv67.html

Celui de Ubuntu Hardy : http://rafb.net/p/y3smv890.html

C'est valable 24 heures sur "nopaste".

J'ai tout mis car la variable "humainement compréhensible" n'était pas définie dans ton message précédent: $HUMAIN='[ma grand mère-linus torvald]', ça fait un large intervalle !

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Salut, je suis un peu votre discution sur grub 2, j'ai eu envie d'essayer, mais ca merdouille dès l'installation :\.



J'ai pas le chainage de grub2 qui se fait dans /boot/grub/menu.lst.

Vous l'avez installer sous lenny, ou directement la version de la SID?

Merci

Salut,

j'utilisais déjà grub2 quand Lenny était Testing, maintenant j'utilise la version Squeeze.

Vu ta sortie de aptitude tu n'iras nul part temps que l'erreur de configuration ne sera pas résolue, il y a un script post-install qui plante visiblement. Essaye quand même un:



mais à mon avis il y a un bug avec un script, dans ce cas il faut faire un rapport (s'il n'existe pas déjà) et utiliser la version testing/sid.

Tu n'as pas vraiment besoin de "grub2", c'est juste un paquet vide qui sert à lier les autres paquets nécessaires, l'important c'est "grup-pc", "grub-common", et éventuellement "os-prober" (détection automatique des autres systèmes installés).

_________________
Mais il n'a même pas de signature lui... n'importe quoi !

Ok, ca me sort que le paquet est cassé:

bon j'ai désinstaller les paquets grub2 et grub-pc, et réinstaller, c'est passé sans problème, j'ai rebooter et démarrer grub legacy et relancer grub2 depuis la sans problème. J'ai donc fait un upgrade-from-grub-legacy ensuite confiant et rebooter. Et la c'est le drame ...

message d'erreur

[code]
grub Loading stage 1.5
grub loading, please wait ...
error 15
[code]

J'ai tous pété mdrr

Une idée pour restaurer, j'ai essayer avec livecd, mais c'est encore grub 1 qui est dessus

Non, pleins. Le net est truffé de docs à ce sujet mais je te conseillerai d'utiliser Super Grub Disk pour démarrer ton système et réinstaller Grub (y compris sur le MBR) ou retenter Grub-pc car d'après le message d'erreur il y a encore du grub-legacy sur les 1er secteurs de ton disque.

@idiotein
Merci pour les liens, c'est encore moins bavard que stage1.5...