C'est officiel, le lanceur GRUB (GRand Unified Bootloader) vient de passer en version 2.00. C'est Vladimir « φ-coder/phcoder » Serbinenko qui l'a annoncé sur la mailing list. Ce passage est principalement symbolique. En effet, beaucoup l'utilisent depuis longtemps et les développeurs recommandaient de toute façon GRUB 2 bêta par rapport à GRUB legacy. Espérons que ce changement incitera encore plus de distributions (et donc de personnes) à l'utiliser par défaut.
Pour rappel (merci Wikipedia), GRUB « s'exécute à la mise sous tension de l'ordinateur, après les séquences de contrôle interne et avant le système d'exploitation proprement dit, puisque son rôle est justement d'en organiser le chargement. Lorsque le micro-ordinateur héberge plusieurs systèmes (on parle alors de multi-amorçage), il permet à l'utilisateur de choisir quel système démarrer. »
Cette version inclut un thème graphique officiel, nommé starfield. Le menu a été réorganisé en sous-menus.
NdM : merci à myou pour son journal.
Aller plus loin
- Journal à l'origine de la dépêche (645 clics)
- GRUB 2.00 released (1288 clics)
- GNU GRUB (874 clics)
# Un peu long
Posté par droide (site web personnel) . Évalué à 5.
Je viens d'y passer depuis deux jours, quand il m'a été proposé en mise à jour et il est graphiquement plus sympa mais je le trouve plus lent par contre…
# Bonne nouvelle
Posté par Tetsumaki . Évalué à 2.
Il est en testing depuis le 28/06/2012 sous Archlinux.
Actuellement en rc1 en extra, il devrait pas tarder à arriver en release sur ce dépôt.
Je l'utilise depuis pas mal de temps, il permet de boot sur des partitions GPT avec un bios (paquet grub2-bios)
Le bios disparaissant au profit d'uefi petit à petit (paquet grub2-efi à utiliser dans ce cas).
C'est à la base la raison qui m'avait poussé à utiliser grub2.
En tout cas c'est bien qu'il soit enfin en version 2.00.
[^] # Re: Bonne nouvelle
Posté par Xaapyks . Évalué à 8.
J'ai migré mon installation de Arch vers une config UEFI qui boote sur du GPT hier. (A partir d'une config GRUB1 / MBR)
Quelle prise de tête !
J'y suis arrivé, mais non sans peine !
Quel bordel de devoir gérer cette partition FAT pour l'UEFI ! Et ces commandes à rallonge de grub-install pour générer le shell ou programme EFI… (je ne sais plus trop le terme)
Efibootmgr m'a menti en plus, semble-t-il, après avoir enregistré mon ESP FAT32 auprès de l'UEFI, il m'a donné une liste des endroits ou il va chercher à booter et leur ordre, et bien il semblait que mon nouvel ESP pour Arch était premier, mais mon EFI ne boote pas dessus par défaut…
Donc pour démarrer je dois aller dans l'EFI et manuellement choisir la bonne partition.
Alors je suis d'accord que grub1 et les MBR n'étaient pas parfaits mais franchement là c'est pire, je ne vois aucune avancée par rapport à avant !
L'UEFI : quelle galère :o !!
# Et par rapport aux autres lanceur ?
Posté par Argon . Évalué à 9.
Par rapport à syslinux, quelle sont les avantages/inconvénients de Grub2 ? J'ai un peu laissé tombé grub2 à cause de sa nouvelle façon d'être configuré et sa relative lenteur sur ma machine. (c'est une vraie question).
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Et par rapport aux autres lanceur ?
Posté par ariasuni . Évalué à 3.
Utilisateur de Syslinux depuis moins de 6 mois, je me pose la même question. Je trouve surtout qu'il est simple et facile à configurer. J'ai lu aussi que le développement était plus actif, étant aussi le bootloader que l'on utilise pour les live-CD/USB.
(Enfin la version 2.00, c'est pas trop tôt !)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et par rapport aux autres lanceur ?
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
Syslinux ne supporte pas ReiserFS, par exemple…
[^] # Re: Et par rapport aux autres lanceur ?
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Ah ouais, ça tue comme fonctionnalité!
[^] # Re: Et par rapport aux autres lanceur ?
Posté par dguihal . Évalué à 1.
Si j'en crois une rapide lecture de http://www.syslinux.org/wiki/index.php/The_Syslinux_Project je ne vois pas comment faire un dual boot Windows/linux avec syslinux a part éventuellement en créant un C: en FAT …
[^] # Re: Et par rapport aux autres lanceur ?
Posté par dguihal . Évalué à 3.
Bon je m'auto reponds apparement on peut faire du chainloading, donc j'ai rien dit /o\ cf : https://wiki.archlinux.org/index.php/Syslinux#Chainloading
[^] # Re: Et par rapport aux autres lanceur ?
Posté par Sclarckone . Évalué à 4.
Grub2 supporte LVM, RAID et UEFI (comme précisé dans le commentaire précédent). Certes, tout le monde n'en a pas l'utilité mais je ne crois pas que Syslinux sache le faire…
# load bios acpi dsdt table
Posté par rzr (site web personnel) . Évalué à 1.
avez vous reussi a overider les tables DSDT avant de charger le kernel , is semble que ca soit le cas ?
un package debian est egalement bienvenus …
A suivre
http:/rzr.online.fr/q/grub
gpg:0x467094BC
[^] # Re: load bios acpi dsdt table
Posté par zyphos . Évalué à 2.
C'était déjà possible avec le grub2 actuel:
http://blog.michael.kuron-germany.de/2011/03/patching-dsdt-in-recent-linux-kernels-without-recompiling/
# menu.lst
Posté par Joël Thieffry (site web personnel) . Évalué à 10.
Actuellement je fonctionne avec un grub legacy installé manuellement sur sa propre partition ext2, hors OS. Lors des mises à jour du noyau, je modifie manuellement le fichier
menu.lst, je n'ai rien d'autre à faire, ça a toujours fonctionné.Je suis gêné par le nouveau mode de paramétrage. L'équivalent du fichier
menu.lsten v2 estgrub.cfg, mais il ne fait pas le modifier directement; il faut obligatoirement passer par les fichiers stockés dansgrub.d, puis lancer un script qui va agglomérer le tout dansgrub.cfg. Hors je n'ai pas grub sur mes OS (en fait ils installent le bootloader qu'ils veulent, je ne l'utilise pas). Dois-je passer par un live CD comme GNU GRand Unified Bootloader pour valider mes modifications ?A mon avis, on perd y la simplicité de modification qui caractérise Unix. Je crois que je vais rester encore un peu en grub legacy.
[^] # Re: menu.lst
Posté par monsieurw . Évalué à 3.
Bonjour
Je me pose exactement la même question : je n'utilise pas 50 OS sur mon PC principal, mais j'ai une Ubuntu + Parted Magic pour d'éventuelles réparations sur une partition /boot quasi-indépendante de la distribution , et la manière de gérer les choses avec Grub 2 m'embête. Il faudrait probablement se plonger dans la doc pour mettre en place un boot équivalent, mais je n'ai jamais pris le temps de m'y plonger.
Si quelqu'un a déjà fait ça et à une doc concise sur le sujet, tout lien est le bienvenu. Sinon, j'essaierais de faire une doc là-dessus, mais ça ne sera pas pour tout de suite :)
Bonne journée à tous !
Unk
[^] # Re: menu.lst
Posté par Paul Chavent (site web personnel) . Évalué à 4.
J'aime bien ce passage dans la doc :)
[^] # Re: menu.lst
Posté par lelent . Évalué à 2.
C'est ce que je fais depuis le début de GRUB2, c'est le plus simple, et ça permet d'avoir un menu démarrage pas trop moche.
Evidemment, c'est à refaire à chaque maj du noyau, mais bon, 30 secondes avec nano…
[^] # Re: menu.lst
Posté par Frédéric COIFFIER . Évalué à 6.
J'y suis passé la semaine dernière sur Gentoo et j'ai un peu le même sentiment : je n'ai pas eu de problème mais je n'ai vraiment pas le sentiment de maitriser et ça me parait tout sauf simple (déjà que les histoires de hdX,X de grub legacy me semblaient compliquées).
Et je ne comprends pas ce besoin d'avoir la configuration sous forme de script avec ces horripilants
x:if [ x$feature_platform_search_hint = xy ]; thenPourquoi ne pas avoir utilisé un vrai langage de script existant ?
[^] # Re: menu.lst
Posté par Paul Chavent (site web personnel) . Évalué à 1.
Ces x sont courant dans les scripts shell. Je ne suis pas du tout familier avec Gentoo, mais quand je cherche des exemples de scripts shell, je tombe régulièrement sur des scripts issus de Gentoo (ils sont d'ailleurs bien écrit je trouve). Du coup, je pense que le shell est assez répandu pour être compris pas le plus grand nombre de sys admin.
[^] # Re: menu.lst
Posté par Gabin . Évalué à -3.
Il montre surtout les lacunes du scripteur.
[^] # Re: menu.lst
Posté par Xaapyks . Évalué à 7.
La seule utilité que je vois c'est pallier aux cas ou la variable de gauche serait vide et entrainerait un test syntaxiquement incorrect. Ce qui est normalement résolu par des guillemets pour sécuriser la variable…
Je pense que c'est historique.
[^] # Re: menu.lst
Posté par Spyhawk . Évalué à 3. Dernière modification le 05 juillet 2012 à 10:04.
D'après ce que j'en ai vu, a part plus d'architecture et plus de systeme de fichiers (Reiserfs, JSF, …), Grub 2 a le support EFI alors que ca doit être encore en développement chez syslinux (ça l'était encore en Avril).
L'inutile complexité de Grub 2 et le fait que Grub-legacy ne soit plus supporté m'ont fait switcher vers Syslinux il y a déjà un petit moment. Aucun regret, et du moment où tes besoins sont limités à ext4/btrfs, je ne peux que chaudement te le recommander.
[^] # Re: menu.lst
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 7.
Tout dépend de la distribution que tu utilises.
Le fichier grub.cfg est le seul fichier de configuration lu par grub2.
Après, pour certaines raisons, l'équipe de grub a permit de mettre en place un ensemble de fichier de config (buildtime) qui permettent de générer le fichier de config (runtime).
C'est une option. Ce n'est pas automatique…sur les bonnes distributions.
Pour (re-)générer le fichier de configuration runtime grub.cfg si besoin, il faut lancer grub-mkconfig, qui va lire les fichiers de config buildtime et faire son mic-mac. Ce n'est pas forcément hyper simple à hacker pour ceux habitués à grub1, lilo, etc.
Soit, ben ne lancez pas grub-mkconfig, ignorez ces fichiers buildtime, et modifiez directement grub.cfg, comme avant.
Ah mais nooon… ça marche pas, parce que vous utilisez une distrib de merde, qui s'amuse à exécuter, à votre insu, grub-mkconfig à chaque mise à jour du noyau, de l'initrd ou d'un composant proche du noyau.
Mais il faut bien faire la différence entre une distribution qui a fait le choix de rendre obligatoire le passage par grub-mkconfig, et le fait que grub2 aie permit d'utiliser grub-mkconfig si on veut.
J'utilise Salix, basée et compatible avec Slackware, j'utilise grub2 (des fois LILO aussi sur certaines machines où j'ai pas pensé à changer), et je n'ai pas besoin de me faire chier avec les fichiers de config buildtime. Sur mon propre PC, ça me va, donc j'ai lancé grub-mkconfig, et j'ai mon fichier grub.cfg généré ; sur un serveur je ne le lance pas, et j'ai modifié directement le fichier grub.cfg.
J'imagine que sous Arch, ça doit être la même chose, grub-mkconfig n'est pas lancé implicitement lors d'une mise à jour de paquet.
Doit y avoir aussi d'autres distrib qui font ça correctement ou qui permettent d'activer ou pas l'utilisation automatique de grub-mkconfig. Après y'a les autres…
[^] # Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Sylvain Blandel . Évalué à 3.
Obligatoirement, obligatoirement, … il reste possible de modifier manuellement le fichier
grub.cfg😊 (même si ce n'est pas conseillé, je suis d'accord).Toutefois, votre distribution peut vous embêter en réalisant automatiquement des
grub-mkconfigqui modifient le fichiergrub.cfgà votre insu. Un palliatif à ce problème estde changer de distribution pour passer à Archlinuxd'utiliser le fichier/etc/grub.d/40_custom. En effet, lors d'ungrub-mkconfig, le contenu du fichier40_customest recopié tel quel dansgrub.cfg, sans modification.Vous pouvez donc écrire une entrée personnalisé dans
40_custom, elle sera intégrée telle quelle dansgrub.cfg. Pour écrire votre entrée personnalisée, inspirez-vous de celles créées automatiquement.Voici le contenu du fichier
/etc/grub.d/40_customchez moi :Vos entrées personnalisées seront affichées par Grub après les entrées auto-générées. Pour qu'une de vos entrées personnalisées soit sélectionnée par défaut, réglez correctement le paramètre
GRUB_DEFAULTdans le fichier/etc/default/grub.Une dernière chose : pour régénérer manuellement le
grub.cfg, la commande exacte est :grub-mkconfig -o /boot/grub/grub.cfg
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 5.
J'aime assez l'idée de configurer un générateur de configuration pour un gestionnaire de démarrage…
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 3.
Voyons syslinux:
Total: 11 lignes contre 33 (sans les commentaires) à fonctionnalité identiques.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 05 juillet 2012 à 15:31.
Ouais sauf que non, justement.
Là il a copié-collé un truc généré et l'a adapté.
Si tu veux comparer à fonctionnalité égales (donc en supposant que ces partitions sont pas sur du GPT mais du MS-DOS), ça donne :
Ce qui fait 10 lignes. Alors faudrait ptre un peu comparer des choses identiques.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 4.
C'est justement là que je voulais en venir: la config' de syslinux n'est ni plus compliquée ni plus longue quel que soit le système de fichier considéré. Le seul boulot qui incombe au chargeur de démarrage est de charger le noyau et de lui passer les arguments qu'on lui demande. Le niveau de complexité de Grub2, quand on le ramène à ça est inutilement élevé.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6.
Ce serait bien de lire le tout et pas de répondre à côté de la plaquer, merci.
Les lignes de syslinux et de grub2 font exactement la même chose : afficher une ligne de menu, charger le noyau, charger l'initrd, booter.
Les lignes qui ont été ajoutés par Sylvain sont inutiles au boot. Sauf évidemment le module pour gérer ses partitions GPT…ce que ne peut pas faire syslinux pour le moment (mais je ne doute pas qu'il finisse par les gérer).
Les lignes ajoutées, permettent de charger une carte de clavier bépo (inutile pour sélectionner la ligne de boot, utile uniquement s'il veut modifier un truc à la volé dans grub2, chose impossible avec syslinux), de dire à grub2 de ne pas changer de résolution au moment de charger le noyau (c'est sympa, mais pas indispensable), charge le module gzio (je ne sais pas pourquoi il charge ce module), charge le module de gestion de partitions GPT, charge le module de gestion d'ext1/2/3/4 (mais ça me semble inutile, je pense qu'il est déjà chargé).
La ligne avec le search permet de définir la variable "root" (permettant de donner la partition sur laquelle démarrer) en cherchant la partoche par UUID, inutile puisqu'on a déjà défini la variable root.
Ensuite y'a deux "echo" qui servent à rien.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 1.
J'admets ne pas avoir argumenté avec un exemple pertinent. Ça m'arrive. Toutefois mon avis n'a pas changé sur le sujet et ton argumentation ne m'a pas convaincu. Tu peux lire mes autres commentaires autour de celui-ci, si ce n'est déjà fait. Le fait est que Grub2 est complexe, trop complexe pour les besoins envisagés et surtout pour une distribution à grande échelle.
Pour l'exemple: je voulais savoir comment générer un fichier keymap pour gérer mon clavier Azerty avec Syslinux. (Oui, parce que jusqu'alors je tapais le nom du menu pour lancer un OS…) J'ai cherché quelques jours et tout ce que je trouvais était des références vers les fichiers Keymap de Lilo. Ne voulant pas installer Lilo pour ces seules tables, je me suis demandé s'il n'était pas plus simple de gérer mon menu de démarrage en mode graphique, où les seules les touches de navigation sont utiles. J'ai donc ajouté à la conf une ligne pour le papier peint, un ligne par menu pour l'étiquette et c'est tout. Problème résolu en trois lignes de conf'.
C'est ce genre de raisonnement que j'apprécie particulièrement; je ne parle pas du mien mais de la manière d'aborder un problème et de le résoudre. Alors qu'il est probablement utile de supporter certaines fonctionnalités, s'il existe un moyen plus court de s'en passer pour arriver au même résultat, ces fonctionnalités supplémentaires seront de facto inutiles.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Mais encore une fois, je ne vois pas la différence avec grub1 ou grub2 sur ton exemple.
Si tu veux résoudre le même problème avec grub2, tu vas dans la doc, qui va te donner les même genre de commandes que celles de syslinux/extlinux, et tu vas te retrouver à taper à peu près la même chose.
Grub2 permet plus de chose que syslinux, celà ne veut pas dire qu'il est complexe de l'utiliser.
Je voudrais juste préciser que je n'ai rien contre syslinux, au contraire, j'aime bien aussi ce bootloader qui est également clair et bien fonctionnel. En fait, je l'utilise sur USB pour chainloader vers du grub2, car l'installation de syslinux dans le MBR est plus simple (pour la plupart des gens et clés USB en fat32) qu'avec un grub2.
Par contre, je trouve qu'on regarde souvent l'utilisation d'un soft, intégré dans cette merde d'Ubuntu, au lieu d'évaluer le soft lui-même. À mon avis, ici c'est le même problème. grub2 est évalué via l'intégration pourrie d'Ubuntu (je vais me faire moinsser pour dire ça, mais bon…)
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Sylvain Blandel . Évalué à 2.
Le problème initial n'a pas été résolu, mais contourné. En effet, le clavier azerty n'est toujours pas reconnu par Syslinux, seules les touches de navigation le sont (je suis d'accord, c'est probablement plus pratique de lancer l'OS en utilisant les touches de navigation qu'en tapant son nom).
Il y a un truc utile avec Grub, c'est la possibilité de booter dans le système de fichier de l'initramfs. On obtient un shell minimal, il est possible de monter ses partitions et d'y modifier des fichiers. Cela permet d'accéder en lecture/écriture à une partition racine qui refuse de démarrer, c'est l'équivalent du live-CD de secours ! 😊
J'ignore si les autres chargeurs de démarrage proposent cette fonctionnalité, je n'ai pas cherché. En tout cas, c'est rudement pratique !
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 2.
Non, le problème initial a bien été résolu. Le problème lié au clavier n'était que secondaire. Le vrai problème ici était de pouvoir lancer un OS quel que soit le clavier. Avoir un clavier AZERTY ne devient un problème que lorsqu'on désire taper le nom du menu.
Dans tout ceci, ce que je veux démontrer, c'est que la manière de raisonner influe sur ce qu'on considère comme un problème voire le problème à résoudre. Simplifier les choses en amont est une façon de résoudre des problèmes épineux mais secondaires. C'est là-dessus que tout mon raisonnement se base depuis le début.
C'est sans doute utile et pratique mais un chargeur de démarrage n'est pas, AMHA, le bon outil. Je me sers de Qemu ou, à la limite, d'un chroot pour ça, par exemple. Et j'ai toujours avec moi une clé USB avec une partition dédiée aux diagnostics avec une distribution installée en mode Live.
De même, je n'accueille pas avec joie qu'un chargeur de démarrage modifie le contenu d'un disque ou d'un fichier. Mais bon, ça ne concerne que moi et je suis sans doute parano à l'extrême…
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par zebra3 . Évalué à 3. Dernière modification le 06 juillet 2012 à 16:09.
Mais avant ça, tu dois de toute façon passer par un chargeur de démarrage pour avoir un système de secours, non ? Donc ça fait bien partie de son rôle :-)
Sauf que ce n'est pas le chargeur de démarrage qui modifie quoi que ce soit, c'est toi, au travers des outils qu'il offre.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par FantastIX . Évalué à 1.
Bien vu. Mais, si on coupe les cheveux en quatre, le chargeur de démarrage en question n'intervient que pour faire démarrer le système de secours, qui me permettra de visiter l'initrd sans altérer mon système. Dans le cas de Qemu, idem, sauf que je n'ai pas besoin de faire redémarrer mon système.
D'ailleurs à quoi sert de démarrer dans un initrd si on ne dispose pas des outils pour le modifier? Car ces outils font partie du système auquel l'initrd appartient, non? Je suis peut-être complètement hermétique (ça m'arrive aussi) mais je ne mesure pas la pertinence d'une telle fonctionnalité, que je classerais dans les arguments purement marketing… s'il y avait des intérêts commerciaux en jeu. Autre explication, possible aussi: je n'ai rien compris à l'histoire.
'Mettons. Dans ce cas syslinux ne les intègre pas, ce qui ne modifie en rien mon argumentation sur le principe de base.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Sylvain Blandel . Évalué à 1.
Je n'ai pas été clair concernant le « boot dans l'initramfs » ! :-)
En fait, tout se passe en mémoire vive.
Le chargeur de démarrage charge le noyau, puis décompresse l'initramfs en mémoire vive, et lance le système d'exploitation ainsi constitué (l'initramfs décompressée joue le rôle de partition racine). Tout se passe dans la RAM, il n'y a aucune écriture sur le disque. Le principe est identique à un live-CD : un système d'exploitation éphémère, lancé uniquement en mémoire vive, et qui n'écrit pas sur le disque.
Une fois que ce système d'exploitation est lancé, l'utilisateur peut s'il le souhaite monter une partition de son disque dur en lecture/écriture afin d'intervenir dessus.
Le « boot dans l'initramfs » est un outil de diagnostic et de réparation, pareillement à la clé USB que tu utilises. Avec, peut-être, un avantage : le noyau de ce système de secours est le noyau utilisé habituellement par le système à secourir. Il supporte donc exactement le même matériel, les mêmes périphériques, les mêmes technologies. Cela facilite les interventions.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Sylvain Blandel . Évalué à 4.
Non, ce n'est pas le chargeur de démarrage qui modifie le contenu d'un disque ou d'un fichier. Le chargeur de démarrage lance un système d'exploitation, point. Une fois le système d'exploitation lancé, le chargeur de démarrage n'agit plus.
Dans le cas du « boot dans l'initramfs », le chargeur de démarrage lance le noyau linux (que tu lui indique) associé à une partition racine particulière : l'archive initramfs décompressée. Une fois ce système d'exploitation lancé, le chargeur de démarrage n'agit plus, et ton ordinateur est fonctionnel. Évidemment, les fonctionnalités de l'OS ne dépendent absolument pas du chargeur de démarrage utilisé, mais du noyau et du contenu de l'initramfs.
Et, comme le dit Zebra3, c'est l'utilisateur qui choisit de modifier des fichiers, certainement pas le chargeur de démarrage.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
FantastIX :
Sylvain Blandel :
Il me semble tout de même qu'il peut être amené à modifier le fs, comme par exemple enregistrer le dernier choix sélectionné dans
/boot/grub/grubenv. Cela ne marche d'ailleurs qu'avec un certain nombre restreints de fs (les ext* par exemple), et uniquement dans les partitions bios, Grub2 ne gère lvm et raid qu'en lecture seule.Ce fonctionnement (grub en écriture) n'est pas du tout le fonctionnement par défaut, au contraire ! C'est une possibilité, mais il y a un peu de chemin à faire pour activer ce fonctionnement, ce n'est pas la norme.
Sur Debian il y a le fichier
/etc/default/grubdans lequel il faut mettre à jour une variable :Pour que grub ne choisisse pas la première entrée mais celle de
grubenv.Ensuite il faut ajouter une variable qui n'est pas si évidente à trouver (certains ralent parce qu'elle est mal ou pas documentée, mais FantastIX sera de ceux qui comprendront le mieux pourquoi).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
En effet. Mais le FS est toujours accédé en lecture seule. C'est simplement que ce fichier est accéder en mode bloc en écriture, le système de fichier n'est pas modifié.
En effet, le fichier grubenv doit avoir déjà une taille défini à l'avance et doit être contiguë.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
ah oui, en effet…
La possibilité d'écriture est donc vraiment très limitée et vraiment exceptionnelle !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Pour etre précis, la fonctionnalité offerte par grub ici c'est l'édition live de l'entrée de démarrage, et
dans ce cas des parametres fournis au kernel.
Le 'break=y' dont il est fait mention sur le lien est une fonctionnalitée offerte par l'initramfs de archlinux.
[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Sylvain Blandel . Évalué à 1.
Moi non plus. :-)
Pour créer mes entrées personnalisées, j'ai adapté les entrées auto-générées. Lorsque ça a fonctionné, je n'ai pas fait l'effort de comprendre chaque paramètre. Bref, il y a certainement des paramètres redondants ou inutiles car je suis trop fainéant pour optimiser mes entrées personnalisées. 😄
Pour cette entrée-là, la partition
/bootest sur la partition racine.Sur une autre installation où ces deux partitions sont distinctes, la ligne
searchindique l'UUID de la partition/boot, tandis que la lignelinuxindique l'UUID de la partition racine.[^] # Re: Des entrées personnalisées, et qui ne sont pas modifiées par grub-mkconfig.
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Ah oui, j'avais pas pensé au cas où /boot serait une autre partoche. Dans ce cas, en effet le search prend son sens.
Merci de l'explication.
[^] # Re: menu.lst
Posté par FantastIX . Évalué à 0.
Exactement. Je suis horrifié par le degré de complexité de Grub2 pour la [non] pertinence (AMHA) de ses nouvelles fonctionnalités.
Démarrage en résolution native…? M'en tape, le noyau ou X va le faire plus tard. Ça me sert à quoi un menu de démarrage en 1920x1080 qui comprend trois lignes si ma carte nVidia n'est déjà pas foutue de m'afficher plus que 1280x1024 en mode framebuffer?
Support de partitions XFS, ReiserFS, LVM? Hmmm… J'ai toujours tapé mon noyau et mon initrd sur une partition distincte en ext[23]. Il y a assez de systèmes de fichiers supportés pour se permettre une petite partition distincte. Et puis qui a envie d'un /boot en LVM? Sûr, c'est attirant. Mais est-ce vraiment utile?
Je me suis arrêté à ces deux points, j'ai laissé tomber tout de suite. Je ne suis pas prêt de lâcher syslinux avec son menu en mode graphique 640x480. De toutes façons, ça fait perpète que je n'utilise plus Grub au profit du premier, incomparablement plus facile à appréhender et à maîtriser.
[^] # Re: menu.lst
Posté par Marotte ⛧ . Évalué à 5.
Je te réponds, mais aussi à tous ceux qui chougnent sur la complexité de GRUB 2, parce que je me fais chier dans une chambre d'hôtel, il pleut et en plus j'adore donner mon avis.
La génération automatique du grub.cfg c'est bien (oui je suis très feignant, j'assume), ça évite de se palucher l'édition d'un fichier, avec tous les risques d'erreurs que cela comporte, à la mise à jour du noyau ou gros changement du système.
Alors considérant, comme cela a été dit plus haut, que :
Il y a /etc/grub.d/40_custom.cfg, et même un 41_custom.cfg qui sourcerait un éventuel custom.cfg sur Debian, on peut personnaliser de manière permanente.
On peut s'en passer, il doit y avoir un moyen de configurer les gestionnaires de packages pour qu'il n'exécute pas grub-mkconfig ou update-grub automatiquement.
Mais aussi que GRUB se veut un chargeur de démarrage avec un max de poil autour, il est par exemple capable de monter des partitions, aller lire et écrire dedans. C'est un peu normal qu'il se dote de fonctionnalités un peu évoluées.
Pour métaphorer je dirais que GRUB est aux chargeurs de démarrage ce que Emacs est aux éditeurs de textes…
Vive GRUB 2 !
[^] # Re: menu.lst
Posté par Argon . Évalué à 5.
Grub 2 semble plus complet que syslinux sur le support des système de fichier ou sur le support dur RAID et c'est très bien. Néanmoins je trouve que les développeurs en font un peu trop et on perdu de vu ce qu'est un bootloader, simplicité, rapidité et légèreté.
Il y a la fonction automatique de Grub2 où l'utilisateur ne configure pas le fichier principal de Grub. Quand je commence à lire /etc/default/grub, /etc/grub.d/40_custom.cfg sans parler des autres script du répertoire (que l'on ne modifie pas en général je te l'accorde), je commencer à trouver que cela fait beaucoup pour un bootloader.
Tu parles de génération automatique certes c'est bien mais si tu veux modifier quand même ton grub.cfg pour adapter 2, 3 petites choses à la dernière minutes tu te retrouves devant fichier qui ressemble plus à un script bash plutôt qu'à un fichier de configuration. Je viens de faire le test avec une Archlinux, le grub.cfg est juste illisible. On est très loin d'une lecture clair de syslinux ou du grub_legacy et je trouve ça bien dommage.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: menu.lst
Posté par FantastIX . Évalué à 2.
Lopin de moi l'idée de dénigrer le travail qui a été fait mais la seule existence d'un générateur de configuration pour un programme (dont les besoin sont aussi simples que ceux d'un chargeur de démarrage) est déjà un aveu de sur-complexité. Alors que je ne tiquerais pas devant un générateur de config pour, disons, Nagios, ça me fait sursauter pour un truc aussi élémentaire et universel qu'un bootloader.
[^] # Re: menu.lst
Posté par FantastIX . Évalué à 2.
Loin*, pas lopin* :(
[^] # Re: menu.lst
Posté par Marotte ⛧ . Évalué à 7.
Un chargeur de démarrage pour un OS donné (par exemple LILO) c'est simple. GRUB se veut le chargeur de démarrage universel, capable de booter n'importe quel OS existant ou amené à exister. Forcément c'est pas aussi simple et un générateur de configuration n'est pas une idée saugrenue.
Sans compter que pour le desktop de Madame Michu, ne pas avoir à éditer un fichier de conf (même via une GUI) quand le noyau ou l'initrd sont mis à jour, c'est appréciable. On va me dire oui mais la mise à jour pourrait mettre grub.cfg à jour en même temps, oui mais là du coup c'est Kevin Michu qui va pester car sa modification perso a été écrasée ou bien le système lui demande s'il faut installer le nouveau grub.cfg ou garder l'ancien, ou fusionner…
[^] # Re: menu.lst
Posté par FantastIX . Évalué à 1.
En effet. Mais les chargeurs que je connais (même si je n'en ai essayé que deux) le font aussi, n'est-ce pas? Je veux dire syslinux (également à coup de modules, p. ex. chain.c32) et Grub. Et je préfère de loin l'approche de syslinux. Question de point de vue, sans doute.
C'est un argument qui est valable pour n'importe quel logiciel et ça n'en fait certainement pas un argument en faveur de Grub2 seul. Le fait est que plus un logiciel est compliqué, plus c'est un casse-tête pour celui qui dépanne en cas de pépin. Et quel que soit le logiciel, ce n'est pas Madame Michu qui se dépannera elle-même.
Ensuite, la mise à jour d'une configuration de démarrage, critique s'il en est, doit être aussi simple que possible afin d'éviter que toute modification faite par l'utilisateur devienne la source d'une panne. Encore une fois, le concept de syslinux est imparable. Sauf si le gestionnaire de la distribution (yast, apt, yum…) s'en mêle de manière inappropriée, une mise à jour n'affectera pas le démarrage car tout se trouve dans /boot.
Maintenant, je n'ai pas encore vu de distribution prenant en charge autre chose que Lilo ou Grub[2]. Mais je n'ai pas cherché beaucoup non plus. J'avoue :D .
Bref, ce que je veux dire est que syslinux (par exemple) est conçu de manière à ne pas avoir à se préoccuper d'un fichier de configuration éventuellement modifié (à moins de le faire exprès). De plus, la complexité de Grub2 appelle visiblement un système de gestion de la configuration, ce qui amène un niveau de complexité supplémentaire en raison de l'outil qui va gérer la configuration du bouzin… On ajoute un maillon à une chaîne qui se doit être la plus courte possible.
[^] # Re: menu.lst
Posté par Argon . Évalué à 2.
Archlinux (iso version 2012) propose comme chargeur de démarrage grub_legacy, grub2 et syslinux. Mais en général la plupart des distributions réservent syslinux à leur CDROM d'installation ou LiveCD.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: menu.lst
Posté par FantastIX . Évalué à 2.
Merci pour cette info. Ce n'est pas la première fois qu'on me vante les atouts de Arch; ta remarque m'en donne un de plus.
[^] # Re: menu.lst
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 06 juillet 2012 à 19:33.
Si tu kiffes l'édition de fichiers texte à la papa pour la configuration, tu vas adorer Archlinux !
Je l'ai un peu utilisée et je dois dire que c'est bien une très bonne ditribution. Je la range au coté de Slackware et Gentoo pour le coté didactique qu'apporte le fait que la distribution fasse le minimum de choix par défaut et laisse l'utilisateur choisir, il n'y a pas de wrapper/automatisation à tout va.
Concernant SYSLINUX je me permet un copier/coller du Wikipedia anglophone :
Donc certes ça permet un peu plus que booter un seul OS, ça permet le chainloading, tout comme LILO d'ailleurs. Cependant si je ne m'abuse ça ne permet pas, sur un système qui ne démarrerait plus de lui même, de lancer GRUB, aller éditer les fichiers qui vont bien et ainsi permettre au système de démarrer. Alors oui c'est sûr, on va me dire : "Pour ça on peut booter sur un live CD"… Et là je ne sais plus quoi dire ;)
Aller si, dernier argument. Avec GRUB 2, sur un ordinateur qui ne démarre plus (à cause de son chargeur de démarrage) et dont ont a aucune information, on peut farfouiller dans les partitions, les systèmes de fichier, et ainsi booter directement le système présent sur cette machine.
Merci pour votre attention. Vous pouvez disposer.
[^] # Re : menu.lst
Posté par claudex . Évalué à 4.
Personnellement, j'ai bien plus appris avec Gentoo qu'avec Archlinux, et le fait qu'il n'y ait pas les symboles de débogages sous Archlinux n'est vraiment pas pratique.
Si tu n'as pas accès physiquement au serveur, mais uniquement au travers d'une (émulation de) console série, ça peut être pratique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Lenteur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Je vois des commentaires qui parlent de la lenteur du bootloader. Vous démarrez votre ordinateur combien de fois par minutes pour que la lenteur soit gênante ? Le bootloader mettrait quinze secondes que je m'en ficherais toujours pas mal…
[^] # Re: Lenteur
Posté par Frédéric COIFFIER . Évalué à 10.
Finalement, Ubuntu et Fedora essaient de faire démarrer Linux en moins de 5s uniquement pour compenser le temps que l'on passe désormais sous le bootloader…
[^] # Re: Lenteur
Posté par ckyl . Évalué à 9.
On peut aller plus loin que ton commentaire. Tes applications tu les démarres combien de fois par jour ? Firefox mettrait 2 minutes à s'ouvrir que tu t'en ficherais pas mal ?
Pouvoir booter rapidement c'est du confort et c'est pratique.
[^] # Re: Lenteur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
Je le démarre zéro (il tourne déjà) à deux fois (j'ai installé un plugin qui demande redémarrage, ou il a planté). Donc, ouais, sur une journée de 8 à 10 heures, c'est toujours négligeable. Le navigateur et le bootloader d'une machine de bureau ne sont pas du tout des logiciel critiques en terme de temps de démarrage. D'autant que j'imagine que la lenteur de grub 2 est loin d'être de l'ordre de la dizaine de secondes.
Pouvoir booter rapidement, c'est du confort, et c'est surtout une frivolité négligeable comparé au reste de "l'user experience". Mon téléphone met plus d'une minute à démarrer, ça ne m'a jamais posé de problème. Il redémarre une fois par mois, suffit de le faire quand t'as pas besoin de téléphoner. Le démarrage du PC, c'est pareil: je peux le faire en même temps que je prépare mon café, enlève mes vêtements, range mon bureau, etc… i.e., avant d'avoir une quelconque activité sur l'ordi.
[^] # Re: Lenteur
Posté par ckyl . Évalué à 7.
Et tu es trop egocentrique pour te dire que y'a peut être des gens qui n'ont pas les mêmes usages que toi et qui apprécient de rester le moins de temps possible comme des cons après avoir appuyé sur le bouton ?
Ca va de la machine que tu démarres quand quelqu'un t'appelles pour avoir une info, à ceux qui sont obligés de rebooter plusieurs fois par jours en passant par ceux qui attendant que leur média center soit pret. Et bien sur les milliers d'autres cas d'utilisation dont je n'ai pas idée.
Alors oui ca peut te paraitre une futilité, ou ca ne peut te servir à rien. Mais pourquoi passer du temps à attendre pour rien ? J'ai des ordis qui ne redémarrent jamais d'autres que j'allume quand j'en ai besoin, pas 5 minutes avant par je ne sais quel miracle.
[^] # Re: Lenteur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
En pratique, la lenteur insupportable de grub 2, c'est quoi ? 2 minutes ? 5 minutes ?
Je reste persuadé que les moules qui ont commenté « c'est trop lent » ne sont pas des gens pour qui 5 secondes de plus ou de moins à des conséquences qu'on saurait noter. Je veux bien faire des concessions s'il s'agit du système de secours d'un avion de ligne, mais même si grub met 10 secondes (ce que je ne crois pas), l'impact réel sur la vie d'une moule qui reboote plusieurs fois par jour ou bien est au téléphone est certainement négligeable.
Je suis même sûr que grub 2 met moins de temps à faire son travail que l'emacs à la configuration bien chargée d'un certain nombre de gens que je connais met à démarrer…
[^] # Re: Lenteur
Posté par ckyl . Évalué à 3.
J'utilise pas grub2 donc aucune idée du facteur. Maintenant en dehors du taff je dois attendre entre 2 et 6x par jour qu'une machine démarre. Plus c'est rapide moins ca me gonfle faut pas chercher plus loin. Y'avait de net progres ces derniers temps ca serait dommage de revenir en arrière.
Ca s'applique à n'importe quelle action que tu fais; informatique ou pas. Devoir laisser préchauffer ta voiture 1 minutes avant de tourner la clé ca va pas changer ta vie non plus. Pourtant t'es content que ca dure 0 à 5s.
[^] # Re: Lenteur
Posté par B16F4RV4RD1N . Évalué à 2.
ok on est d'accord : on s'en fout de passer 15" de plus pour booter un ordinateur. Mais en ce cas, pourquoi les distrib veulent faire passer au forceps systemd sous prétexte que ça fera gagner du temps au démarrage ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Lenteur
Posté par Guillaume Chanaud (site web personnel) . Évalué à 2.
Pour faire des beaux graphiques bootchart et pouvoir se la péter en disant que notre os enterre les autres au démarrage, c'est une raison suffisante non :D ?
Je ne trouve pas ça très critique non plus, pour mon utilisation en tout cas, par contre sur des systèmes embarqués/légers ça l'est plus.
[^] # Re: Lenteur
Posté par claudex . Évalué à 7.
Ce n'est pas du tout le prétexte utilisé, c'en est un parmi d'autres et uniquement par rapport aux init classiques, mais d'autres ont déjà un init par dépendance (upstart, le truc de Debian dans Squeeze, openrc…) qui ne doit pas être loin d'offrir les mêmes performances.
Par contre, systemd veut rendre l'écriture des fichiers de configuration plus simple, tirer parti des fonctionnalités offertes par Linux (comme les cgroups) et améliorer (du point de vue des développeurs de systemd) les fonctionnalités offertes par un init (démarrage des services à la demande, gestion des services qui plantent…)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lenteur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Je pense qu'il faut prendre en compte l'ordre de grandeur.
Démarrer n0% plus vite pour n entre 1 et 9, c'est intéressant ; démarrer 0.0n% plus lentement, c'est négligeable. Alors, justement, se plaindre de perdre des pouillèmes quand on gagne tant, ça me fait lever les yeux au ciel.
[^] # Re: Lenteur
Posté par Patrick Nicolas . Évalué à 2.
Je démarre mon PC 2 ou 3 fois par jour, mais je ne vois pas de raison pour qu'il soit plus lent que nécessaire pour démarrer.
Le problème est surtout que je ne vois plus l'intérêt de GRUB, donc si il prend 5s à se lancer, ce sont 5s de trop.
# Secure Boot
Posté par Megagolgoth . Évalué à 2.
Avec l'arrivé (forcé) du Secure Boot, ça ne va pas beaucoup aider GRUB à se generaliser…
# Grub sert-il encore ?
Posté par Patrick Nicolas . Évalué à 6.
Depuis quelques temps l'UEFI se généralise, les implémentations sont certes bugguées (l'un ignore l'ordre de boot en dehors des entrées par défaut, l'autre refuse de lire les sous-répertoires) mais je trouve le système bien plus propre que GRUB et consorts :
Une interface est définie pour manipuler les entrés de démarrage
La partition contenant les chargeurs de démarrage est standardisée, quel que soit le nombre de systèmes d'exploitation installés
Il est même possible de choisir sur quel OS démarrer sans passer par l'interface graphique du firmware
Les chargeurs de démarrage traditionnels au contraire sont à l'intérieur de l'OS, ce qui rend la cohabitation plus difficile, ils essaient de lire tous les types de partitions existants, ce qui n'est pas forcément nécessaire. On ne peut pas d'un côté reprocher à l'UEFI d'inclure des pilotes pour tout le matériel et de l'autre côté se réjouir de pouvoir lire du btrfs compressé avec des sous-volumes dans un chargeur de démarrage !
Tout ça pour dire que je suis passé de GRUB legacy au boot EFI (EFI stub dans le kernel, et le sélecteur du firmware pour choisir le noyau à charger), il m'a fallu un script bash de 10 lignes pour installer les sources et modifier les entrées EFI correctement. Le démarrage est légèrement plus rapide, la maintenance est plus simple et j'ai un clignotement de moins de l'écran dans la séquence de démarrage.
[^] # Re: Grub sert-il encore ?
Posté par Paul Chavent (site web personnel) . Évalué à 2.
Tu pourrais nous recommander un howto qui explique ce genre de manip ?
[^] # Re: Grub sert-il encore ?
Posté par Patrick Nicolas . Évalué à 2.
J'ai principalement suivi ce qui est décrit sur http://www.rodsbooks.com/efi-bootloaders/index.html
Ce n'est pas vraiment un howto direct, mais il y a les informations suffisantes pour faire ce qu'on veut.
# Grub2 + script pour rebooter sous un autre OS !
Posté par Kytrix . Évalué à 2.
Grâce aux nouvelles fonctionnalités de Grub2 permettant de choisir l'os qui sera utilisé au prochain boot (et seulement celui ci), je m'étais fait un petit script pour rebooter sous Windows en 1 click (commande grub, reboot propre)
C'est bien pratique quand on veut profiter du reboot pour aller boire un coup ^
qui ne s'est jamais retrouvé sur le mauvais OS après un reboot ? ;)
[^] # Re: Grub2 + script pour rebooter sous un autre OS !
Posté par ElectronLibre63 . Évalué à 10.
Je n'ai qu'un (bon) OS sur ma machine, je ne peux donc pas rebooter sur le mauvais ! :)
[^] # Re: Grub2 + script pour rebooter sous un autre OS !
Posté par Kytrix . Évalué à 0.
j'attendais cette réponse :D
mais bon wine je ne peux plus, donc j'ai un 7 juste pour jouer !
mais qui sait, si steam arrive d'ici la fin de l'année ^
[^] # Re: Grub2 + script pour rebooter sous un autre OS !
Posté par yellowiscool . Évalué à 3.
Moi j'ai une console. Ça boot plus vite, et c'est moins pénible à administrer qu'un windows.
Après, je peux comprendre que l'on préfère jouer sur PC, c'était juste pour faire une remarque gratuite.
Envoyé depuis mon lapin.
[^] # Re: Grub2 + script pour rebooter sous un autre OS !
Posté par manuel . Évalué à 0. Dernière modification le 06 juillet 2012 à 13:49.
Ca marche très bien avec grub-lecacy ou lilo, sur ma distrib j'ai un script en perl, rebootin pour ca.
# (i|g)pxe rulez
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
bah le tout est de booter avec la carte réseau comme ca plus de problème de secteur d amorçage.
ipxe gère les menus, il peut de mettre en option rom et être résidant dans la rom de le carte réseau.
dans la rom que mon met dans la carte on peut aussi mettre un scripte de boot embarqué.
il peut prendre sa conf via http (ou autre)
et tout comme grub ou efi il y a un shell de commande.
http://ipxe.org/
PS:
quand vous dite que grub2 est lent, ça veut dire quoi ? +20 minutes ou +5 secondes?.
car moi un boot de PC avec 5 secondes de plus après que le P.O.S.T en ai pris 20 je m en fou royalement.
cela di je suis plus pour grub legacy car le fait de refaire grub-siou-plait-régénère-la-conf ça me rappel lilo en au siècle dernier.
[^] # Re: (i|g)pxe rulez
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Lit plus haut, j'ai indiqué que ce besoin de regénérer la conf n'est pas un problème de grub, mais un problème de distribution à la con.
Sinon grub sait booter en PXE également.
[^] # Re: (i|g)pxe rulez
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
j ai bien vu, mais ce n est pas le problème
et oui grub sais booter en pxe, mais je croyait qu on parlais de boot local ici.
mais pour ipxe je parlais de boot sans le réseau, tout en local dans la rom
par contre pour la doc faut se gratter sévère sur le site ils renvoient vers ubuntu ou lfs, pas sérieux ça surtout qu après on se tape des page de gnu info. le gnu rulez c est bien mais ça a ses limites.
mais ne te méprend pas je ne crache pas sur grub2, et je suis plutôt content de lui dans l ensemble. surtout que le fait qu il passe d 1.98 a 2.0, c est purement cosmétique à mon avis.
ce que j aime dans grub/grub2/ipxe c est le shell, le fait que je peux stopper et faire un boot en ligne de commande, tout comme efi d ailleurs, mais sans dédier une partition à cela.
[^] # Re: (i|g)pxe rulez
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
La doc est là, et elle est très bien je trouve. Je vois où tu vois que la doc est sur Ubuntu ?
Booter en utilisant la ROM de la carte réseau, c'est pas con. Je vois pas trop pourquoi grub2 ne pourrait pas le faire. Tout dépend de la taille de l'espace mémoire disponible. Après il manque ptre à grub2 la commande pour installer grub core.img dans cette mémoire, à la différence de ipxe.
[^] # Re: (i|g)pxe rulez
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
iPXE n'est pas un chargeur de démarrage. C'est une implémentation libre d'une pile PXE. Elle peut être utilisée pour démarrer un chargeur de démarrage en PXE, par exemple un PXELINUX ou un GRUB.
[^] # Re: (i|g)pxe rulez
Posté par Mareo . Évalué à 4. Dernière modification le 05 juillet 2012 à 15:31.
Non, iPXE est un vrai bootloader à part entière : il est capable de charger un kernel ou un initramfs et de booter dessus, et il ne fait pas que du PXE (dhcp puis tftp ou tftpm) mais gère tout un tas d'autres protocoles : HTTP, FTP, FCoE, iSCSI et très prochainement NFS, je suis en train de travailler dessus en ce moment.
La seule différence avec un bootloader classique est qu'il n'est pas capable de lire sur un block device, il est cependant capable de lire le permier secteur de premier disque local pour en extraire le MBR et l'executer (et donc généralement passer la main à un autre bootloader). Ça se fait avec la commande :
[^] # Re: (i|g)pxe rulez
Posté par SauronDeMordor (site web personnel) . Évalué à 0.
yep ce petit truc m a changé la vie par rapport a grub-net.
ça a été gpxe au début, puis ipxe car gpxe ne bouge plus.
et c est effectivement un vrai system d amorçage. mainbteant on a les menus aussi, un peu rudimentaire ,ausi c est très bien quand même et bien plus rapide de comboot avec syslinux. Le seul bémol c est que l on peut pas éditer une ligne
# Intérêt ?
Posté par woprandi . Évalué à 1.
J'ai lu en diagonal les commentaires mais je ne saisis pas l'intérêt de grub 2 comparé à grub legacy :P
[^] # Re: Intérêt ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 7.
Effectivement ce n'est pas spécifié dans la dépêche.
En gros, ce qu'on peut noter comme différences (qui peuvent n'avoir aucun intérêt pour toi) :
- le "stage 1.5" est devenu obligatoire pour booter, permet plus de chose (une console de secours est toujours disponible), et contient un ensemble de fonctionnalités variables (préciser à la compilation). Son nouveau nom est core.img
- le "stage 2" n'existe plus, et c'est juste des modules que l'on charge au besoin. Ces modules peuvent définir un driver de système de fichiers, un interpréteur de commande (parser) ou un ensemble de commandes.
- gettext et utf-8 qui permettent d'avoir une traduction des menus (pour les trucs qui nécessitent des vrais menus, genre un liveCD, ou un truc type SystemRescueCD).
- des possibilités de chainloading dans tous les sens, qui permettent une intégration de ou vers grub2 simplifiée.
- la gestion de nouveaux types de systèmes de fichiers, de table de partition, de BIOS/EFI, d'architecture.
- un vrai shell disponible au boot, qui permet de faire un tas de modifications si on a un problème de boot, ou pour booter quelque chose d'exotique ou inhabituel.
- langage de script shell évolué qui permet de faire des scripts plus simple et plus manitenable (utile aux distributions principalement).
- une gestion des thèmes améliorée.
[^] # Re: Intérêt ?
Posté par Anthony Jaguenaud . Évalué à 2.
Et un retour en arrière concernant la config. Ce qui m’avait fait choisir grub par rapport à LILO, c’est que le moindre changement de config nécessitait de réexécuter lilo, alors que grub permet de juste modifier un fichier texte, simple, facile à faire d’un live CD.
Maintenant, il faut la même version de grub sur le live CD, ou chroot ta distrib pour lancer le grub-write-config-on-the-disk-because-i-cannot-read-config-file-with-fs-drivers, en espérant ne pas avoir de soucis entre un live cd 32b et un grub 64b sur ta distrib.
[^] # Re: Intérêt ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6.
Je vais répondre simplement : non c'est faux.
Comme indiqué plusieurs fois plus haut, le fichier de config de grub2 c'est grub.cfg, tu l'édites avec un éditeur de texte, celui que tu veux, et basta. Et le fichier n'est en aucun cas différent entre un 32 ou 64 bits (grub2 tourne en mode émulation 32 bits sur un processeur 64 bits de toute façon, et sur un seul processeur/core, pour info).
Je le répète, mais le grub-mkconfig n'est pas nécessaire du tout pour changer un truc dans la config de grub2, donc pas besoin de chrooter ou je ne sais quoi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.