Lundi soir, je me suis décidé à réinstaller OMA 3.0X, ne sachant comment résoudre ce problème.
Juste après la réinstallation, je pouvais démarrer OMA avec son grub2 dans sa /, via PCLinuxOS par chainage (osprober désactivé)
menuentry 'OpenMandriva (hd1,6)'{
insmod ext2
insmod chain
set root='hd1,msdos6'
chainloader +1}
Je n’ai pas pensé à installer en supplément par lignes de commandes grub2 dans une clef USB comme je le fais de temps en temps. Mais il es probable que OMA aurait démarré de cette manière, car je vois une forte ressemblance entre chainage et MBR-Racine, puisque ces deux procédés passent la main au code contenu dans le PBR (Partition Boot Record).
Ensuite, j’ai lancé la mise à jour via
urpmi --auto-update
Après ce gros travail, OMA mise à jour ne voulait plus démarrer par chaînage. Le grub2 de Mageia avait été écrasé par l’outil Plasma-Boot, et ne démmarait par son gru2-MBR!
Il a fallu actualiser le grub2 de Mageia 5 (sur le même disque) pour la démarrer, donc en utilisant les lignes de grub2 où os-prober est actif.
Je voudrais mettre en évidence deux problèmes dans cette version
—l’outil de Plasma pour la gestion du boot devrait être désactivé, puisqu’il ne mémorise pas les préférences utilisateur. Grub-customizer, bien plus intéressant que l’outil de Plasma, a le même défaut : ne pas mémoiriser les préférences utilisateurs
—OMA a la facheuse habitude d’avoir sa racine aléatoire (/dev/sdc6, /dev/sdb6, ) comme signalé dans un autre sujet
Je vous invite à considérer que ces deux éléments contribuent à aggraver les problèmes en rendant moins prévisibles les paramètres de grub2.
Même en utilisant l’excellent outil “om-control-center”, il n’est pas sûr que les paramètres se conservent
–racine aléatoire
–intervention lors des mises à jour de grub2 de l’outil de Plasma-Boot.J’aimerais que sa section pour le boot soit désactivée
Quand j’avais évoqué la nécessité d’un outil natif de la distribution à la gestion du boot, rugyada m’avait approuvé en mettant “un coeur” sur cette intervention.
Je ne voudrais pas vous offenser en vous disant que je suis passablement agacé par ces problèmes. Ce que je voudrais voir se réaliser
–disposer d’une image ISO stable de préférence où
----l’outil Plasma-Boot est désactivé
—oma-contro-center installé, remplaçant définitivement l’outil de Plasma-Boot
—que la racine soit toujours la même, de préférence identique à celle choisie lors de l’installation. L’essetiel est que ce soit toujours la même. Dans PCLinuxOS elle est différente de celle de l’installation, mais est toujours la même : /dev/sda1 (c’est essentiel pour le module de geston du boot!).
Dans l’attente de vos réponses.
Merci beaucup pour votre aide
PS
Lors de la mise à jour après réinstallation, il y a eu un grand nombre de problèmes liès aux dépendances non satisfaites, liés notamment à la localisation.
J’ai bien aimé “Bienvenue OMA” mis à jour.
Un oubli : pour la / aléatoire, cela se produit évidemment quand il y a au moins deux disques, en bus interne ou sur USB, etc. Est-il possible détablit des règles “udev” persistantes?
Partition / invariable dans
Mageia 5 : identique à celle de l’installation.
PCLinuxOS-2017 : invariable, mais différente lors de l’installation, mais ce n’est pas grave.