Forum

Bonjour

Est-ce que certains parmi vous ont un multi-boot avec au moins 2 mageia ?
J'ai comme l'impression que le grub2 généré automatiquement pas mageia ne dirige pas vers la configuration par défaut :
/boot/vmlinuz et /boot/initrd.img mais vers des configuration momentanée comme
/boot/vmlinuz-4.9.35-desktop-1.mga6 et /boot/initrd-4.9.35-desktop-1.mga6.img

Je trouve ceci dommage. Comment pour réparer ce problème sans trop planter grub2 ?

Bonjour,

J'ai toujours chez moi la configuration habituelle, il y a dans /boot une liste de tous les initrd-xxx.img et vmlinuz-xxx de tous les noyaux anciens et actuel.
initrd.img et vmlinuz pointent vers le dernier, initrd-4.14.43-desktop-1.mga6.img et vmlinuz-4.14.43-desktop-1.mga6.
Grub2 ne connait que ces 2 là.

Tu parles pour la partition en cours. Mais, si tu as une autre partition Mageia, vers quel noyau pointe grub2 ?

Bonjour

en ce qui me concerne, j'ai 3 mageia bootables sur mon système :

-mageia5 sur sda1 ext4
-mageia6 testing sur sda3 btrfs
-mageia6 stable sur sdb1 ext4

j'ai 2 MBR, un sur chaque disque, sda (hdd) ou sdb (ssd)
à chaque nouvelle évolution du kernel, je régénère le MBR (par défaut sur sda) et aussi sur sdb par sécurité via le CCM Démarrage Configurer le démarrage;
ça me met chaque fois, la dernière version du kernel, de celle avec laquelle je fais l'opération : si je fais ça avec la testing, ça mettra le dernier kernel sur sda3, sinon, si je fait ça avec la stable, ça mettra le dernier kernel sur sdb1;
nb : je n'utilise plus mageia5 pour cette opération;

récemment, j'ai eu des problèmes d'encombrements (trop de noyaux proposés);
j'ai installé "grub-customizer" dans les deux et j'ai fait du ménage dans /boot/grub2/grug.cfg de chacune;
maintenant, il y a moins de choix, je n'ai gardé que le minimum utile;
mais cela n'a pas fait le ménage dans /boot où il y a toujours tous les fichiers, vmlinuz, initrd, config, symvers et system-map pour tous les kernels;

je ne comprends pas ton problème;

OK.

Ta manip "à chaque nouvelle évolution du kernel, je régénère le MBR" me fait bien penser que par défaut, grub2 n'indique pas les noms par défaut de la versions du noyau en cours.

Il va falloir que je regarde "grub-customizer".

Bonjour,

J'ai (entre autres) deux systèmes Mageia sur la même machine. Des problèmes avec Grub ? Aucun. Pourquoi ? Tout simplement parce que depuis longtemps (depuis Grub2), j'utilise cette astuce de personnalisation de Grub2. Après avoir trouvé les infos sur le web, j'ai d'abord testé en machine virtuelle pour ensuite l'adopter et en sortir le tutoriel.

Ainsi, quel que soit le système secondaire, Grub est toujours à jour et pointe directement vers le dernier noyau à jour (tout en laissant la possibilité de choisir un autre noyau). Pour rappel, avec cette astuce :
* chaque distribution secondaire possède son propre Grub installé dans sa racine root ce qui permet l'accès vers le bon noyau
* du côté de la distribution principale, Grub2 est configuré pour pointer directement vers le Grub2 de la distribution secondaire.

Pas besoin de trafiquer avec grub-customizer. Il suffit juste d'éditer 2 ou 3 fichiers en mode texte sous root. Guère de difficultés.

J'ai du mal à suivre!
le grub2, au démarrage, il fait ce qu'il trouve dans le MBR;
si le MBR n'a pas été mis à jour (d'après les infos qu'il trouve dans /boot/grub2/grub.cfg, via la commande "grub2-install", il proposera toujours la vieille version;
normalement, si tu fais tes mise à jour via le CCM (ou le mgaapplet), c'est fait automatiquement;

sur mon système, j'ai recours souvent à la procédure de régénération du MBR via le CCM, car, en plus, j'ai aussi, une fédora, une débian et une opensuse;
lors de l'installation des ces trois là, j'ai précisé que je ne voulais pas qu'elles écrivent dans le MBR; pour me simplifier la vie, c'est uniquement mageia6 qui est maître du MBR (j'aurai pu faire une autre choix, mais au lieu d'avoir 2 /boot/grub2/grub.cfg à gérer avec "grub-customizer", j'en aurait 5 !
et puis, sur les autres, je ne sais pas si "grub-customizer" existe, j'ai pas cherché;

concernant, débian et opensuse, elles n'évoluent pas beaucoup, donc pas de problème;
mais la fédora, c'est des changements de noyaux plusieurs fois par semaine; chaque fois, il me faut passer par mageia6, le CCM -> démarrage -> configurer le démarrage pour avoir la dernière version;
en général, je le fais coïncider avec une mise à jour de la testing, ou de la stable, pour faire d'une "pierre deux coups".

Bonjour teutates
nos messages ce sont croisés;
pour l'instant, je suis encore avec ma méthode archaïque, car elle marche malgré l'hétérogénéité de mon système : 3 OS sur du ext4, 2 OS en btrfs "à la racine", 1 OS en btrfs dans un "subvolume";

j'ai pas pris le temps de mettre en œuvre ton tutoriel; je ne sais pas ce qu'il donnerait sur du btrfs.

J'avoue que je ne connais pas le résultat avec du BTRFS bien que je ne comprenne pas ce qui génerait. Je souligne que l'astuce citées plus haut ne contient aucune limite en terme de nombre de systèmes secondaires. Et je parle de système et non de distribution puisqu'il est possible de chaîner avec d'autres systèmes d'exploitation non GNU/Linux (tel Windows) (bien que j'aimerais connaitre ce que ca donne avec du FreeBSD).

Si ta machine a assez de puissance, tu peux créer une simulation sous VirtualBox. Il suffit de reproduire dans les grandes "lignes" ta machines avec des installations basiques mais en respectant les systèmes de fichiers (Btrfs, Ext3/4 ....) et les modèles d'installations.

En partant de ma machine virtuelle existante avec :
* SDA1 : Windows 10 : NTFS
* SDA2: Mageia 6 : Ext4 -> Système principal donc Grub2 principal sur SDA
* SDA3 : Debian 9 : Ext4
* SDA5 : Fedora 28 : Ext4
* SDB1 : Home : Ext4
* SDC1 : Data Windows : NTFS
* SDD1 : openSUSE Leap 15 : Btfs avec sous-volumes (partition SDD1 de 30 Go)
Echec ! Impossible de démarrer cette openSUSE depuis le Grub2 principal, Grub2 étant paramétré en suivant l'astuce vue plus haut. De plus, ce qui confirme l'échec, SuperGrub ne voit pas non plus le système openSUSE.

Toutefois, il est possible que j'ai fait une erreur lors de l'installation d'openSUSE. Je ne maitrise ni le Btrfs, ni les sous volumes.

A toi de voir, Marc-André

Edit:
J'ai refait 2 fois l'installation d'openSUSE en Btfs puis revérifié mes paramétrages.

Édité par teutates Le 02/06/2018 à 21h56

La leap 15 je sais pas, je suis resté encore avec la 42.3 (drôle de suite dans les numéros de version);
mais chez moi, en dur, out of the box, le grub2 me trouve le bon subvolume sur lequel booter;
mais c'est vrai que btrfs complique tout, aussi bien le boot, que le /ect/fstab, et l'installation;
par là, j'entends le "bon" découpage en différents subvolumes pertinents de sorte que l'ont puissent faire des snapshots pas trop gros et tout de même complets, tel que l'on retrouve une situation cohérente après un "rollback" si cela est nécessaire (en cas de mise à jour ou install foireuse).

pour un desktop en usage normal, c'est peut être superflu;
mais pour une cauldron, ça peut être utile;
d'après ce que j'ai compris, en cas de pépin, il suffit de booter sur un snapshot précédents, et de le valider si c'est Ok, et la dernière mise à jour est juste mise à la poubelle sans autre forme de soucis : on retrouve le système avant la mise à jour!
mais c'est un peu "sioux" à configurer et à installer!
opensuse a fait un gros boulot sur ce system file btrfs, snapper est l'outil indispensable pour gérer les subvolumes!
et il est disponible dans les dépots de mageia6, donc, ça devrait le faire!

Je ne comprends pas trop quel est ton propos, Grub2 via vmlinuz et initrd pointe vers le dernier noyau installé pour chaque instance de Mageia.

Bonjour

Je viens d'utiliser Grub Customizer. Il faut directement ce que je souhaite.

Pour répondre à lebarhon : sur la partition en cours, oui, il pointe sur vmlinuz et initrd.img. Mais, pas pour les autres partitions où j'ai aussi installé des mageia. Et c'est bien le problème que j'ai réparé avec Grub Customizer. Maintenant, mes 3 mageia fonctionnent.

Grub Customizer
Enfin, il permet de faire facilement ce qu'on pouvait faire sans rien installer avec grub1.

Salut Troumad

bien content que grâce à "grub-customizer" tu ais pu retrouver tes mageia;

mais comme le dit lebarhon, je n'ai pas bien saisi tes propos;

chez moi, ça a fonctionné très bien sans cela jusqu'au WE dernier, avec mes 6 OS;
et la cause du problème que j'ai eu, c'était juste une histoire de "trop plein", ou d'encombrement;
et c'est cela que m'a résolu le recours à "grub-customizer" : j'ai pu faire "le ménage", et tout a refonctionné normalement.

question subsidiaire :
sur la fedora, malgré les nombreuses mise à jour, il y a un nombre constant de noyaux;
c'est une propriété de dnf, il y a une vidéo d' Adrien sur YT qui explique l'existence d'une constante dans les fichiers de configuration, pour limiter le nombre;
(si je cherche le lien, je vais perdre le jeton !)
est ce que avec urpmi, il y a ( ou pas ) l'équivalent, pour limiter le nombre de kernel disponibles, ce qui rendrait superflu le recours à "grub-customizer" ?
en effet, chez moi, sur la fedora, à chaque nouveau noyau qui arrive, il supprime automatiquement le plus vieux : pas de ménage à faire!

voilà le lien en question
https://www.youtube.com/watch?v=Q66A7xx9q94