Boot : problème critique

Parmi mes essais, j’ai installé un grub2 stable (officiel OMA) pour remplacer une version beta. Pas d’amélioration, ni en intervenant sur les paramètres de ghrub2 via Grub customizer : thème, résolution.
Alors j’ai démarré OMA en runlevel 3 en éditant sa ligne de grub2 lors du démarrageslight_smile:
Exemple :slight_smile:

linux /boot/vmlinuz-4.10.13-desktop-2omv root=UUID=b07445f0-82f2-478b-910f-19fdbe259874 ro audit=0 splash quiet resume=UUID=b05cb77d-3b8e-4017-aa1b-2da4b7785427 3

La racine est bien montée, interfaces réseau activées. Mais en root :slight_smile:

startx

me narre ce poème :slight_smile:

Log file /var/log/Xorg.0.log
Using config directory /etc/X11/Xorg.conf.d
Using system config directory /usr/share/X11/Xorg.conf.d
Fatal server error (EE) no screen found

Quant à décrypter “/var/log/Xorg.0.log” je ne me sens pas vraiment à l’aise!
Je ne suis pas du tout sûr d’avoir démarré OMA par son grub2, même quand elle avait écrasé le grub2 de Mageia 5, car le système installé en premier sur un disque est le système principal de ce disque. Les autres distribs installent grub2 dans leur /.
L’ordi contient trois disques avec chacun son “grub2” dans son MBR :slight_smile:

/dev/sda, XP, contient le “grub2” de MS!
/dev/sdb : contient le grub2 d’openSUSE Tumbleweed
/dev/sdc : contient le grub2 de Mageia 5. Ce disque contient la / d’OMA

Ce qui est primordial est que je puisse démarrer OMA, soit par Tumbleweed, soit par Mageia.
OMA-grub2 semble ne pas apprécier le démarrage par chaïnage (chainloader +1, PCLOS), ni par son propre grub2. J’y vois un peu plus clair depuis les essais en “runlevel 3”. Mais je ne sais pas comment résoudre le problème de démarrage de X Window.

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é) :slight_smile:

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 :slight_smile:

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 :slight_smile:

—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 :slight_smile:

–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 :slight_smile:

–disposer d’une image ISO stable de préférence où :slight_smile:
----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 :slight_smile:
Mageia 5 : identique à celle de l’installation.
PCLinuxOS-2017 : invariable, mais différente lors de l’installation, mais ce n’est pas grave.

Désolé, vous rencontrez des difficultés. Quel est le système de fichiers pour votre installation OpenMandriva?

ext4

Cela devrait être désolé, je n’ai rien à vous aider. Il est peut-être temps pour un rapport de bogue.

Remarque: j’utilise un traducteur et non un francophone.

Cela devrait être désolé, je n’ai rien à vous aider.
Vous êtes désolé, vous ne pouvez pas m’aider.
Thank you for your answer.
Moi aussi je suis désolé.
Please, do you know in an recent ISO contains the buro’tool “om.control.center”, but where Plasma-Boot has been ejected to the ionosphere for example, or more?

SystemSettings>Startup and Shutdown>Grub2 Bootloader

Est-ce ce que vous recherchez?

1 Like

What you mean Plasma-Boot? This?

Or plymouth?

1 Like

While booting : plymouth.
I’ve tried the two themes.
After reinstall but before updating, OMA booted with your beautiful thema.
Now, with the two themas the graphical interface does not run, but virtual consoles are available via CTRL F1, etc.
When connected in this terminal, root partition is mounted and network intefaces up.
If you can answer in French, it’s better for me.
Thanks

Correct.
Je me doutais bien :slight_smile:
No plymouth.

Bonjour,

Ce que j’écris me semble très important.
C’est ma troisième tentative de réinstallation d’OMA 3 pour tester l’environnement de démarrage, avant toutes mises à jour, même du gestionnaire de paquetages. Ce qui m’est très important :slight_smile:

—pendant l’installation : grub2 sur une clef USB (/dev/sdd) : ÇA MARCHE pour démarrer OMA
—dans OMA : "grub2-install --force /dev/sdc6 nécessaire pour PCLinxuxOS-chainloader +1 : ACCEPTÉ
—boot par chainage via PCLinuxOS-chainloader +1 : ÇA MARCHE

J’attire l’attention sur deux points pour jcl notamment :slight_smile:
—Très positif : il est possible de ne pas installer grub2. C’est très utile dans certains cas, par exemple si l’installation de grub2 dans la / pose problème. Dans ma config il sera possible de démarrer OMA par le grub2 os-prober de Mageia. J’ai utilisé cette option il y a quelques années quand grub/grub2 posait problème

—Passablement agaçant aujourd’hui : l’ordre des disques :slight_smile:
—première tentative : installation sur /dev/sdc6 comme dans les précédentes installations. Cette tentative a échoué parce que l’ordinateur avait probablement trop chaud malgré la pose sur le boitier de blocs réfrigérants sortant du congélateur (-20°C)
—deuxième tentative réussie, mais la / est vue comme “/dev/sdb6” au lieu de “/dev/sdc6” comme dans les précédentes installations

Pour conclure “plaisamment” : même si je ne voudrais plus d’OMA, j’aurai toujours de la sympathie pour son “installeur” (comme en anglais “installer”) qui est vraiment très bien construit.

rugyada
Le thème de démarrages réussi par

Boot sur /dev/sdd
PCLinuxOS-chainloader +1

n’est pas celui d’OMA mais plymouth, thème fleuri non testé!

1 Like

Un oubli : avant ces tentatives, je voulais désinstaller grub2 par :slight_smile:

rpm --uninstall grub2.....

option non reconnue!

et

urpme --force grub2-...

refusé, car cela rendra le système instable : j’ai trouvé cela amusant, car il ne pourra pas démarrer. Je l’aurais fait démarrer par le grub2 os-prober de Mageia. S’il ne peut pas démarrer, c’est un des aspects de la stabilité!
Je voulais le désisntaller puis le réinstaller pour observer les changements.
J’ai même essayé :slight_smile:

urpmi --force grub2-2.........

rejeté à cause de problèmes locaux

rugyada,

Bonsoir.
Pour essayer le thème OpenMandriva, je l’ai choisi par grub-customizer. Mais je me suis aperçu en l’utilisant que j’aurais pu le faire sans installer cet outil.
En effet, cela se règle dans slight_smile:

/etc/default/grub

GRUB_THEME="/boot/grub2/themes/OpenMandriva/theme.txt"

Ce qui t’intéresse prioritairement :slight_smile:

—début du boot : thème OpenMandriva
—suite du boot : plymouth
—fin : arrivée sur le thème OpenMandriva

Cet essai de démarrage a été effectué par PCLinuxOS par chainage :

menuentry 'OpenMandriva  (hd1,6)'{
insmod ext2
insmod chain
set root='hd1,msdos6'
chainloader  +1}

Je vais essayer aussi par le grub2 d’OMA installé dans uner clef USB “/dev/sdd”. Il est probable que ce sera identique, vu que le code dans /dev/sdd “passe la main”" au code dans le PBR : /

Je viens d’essayer par le boot sur /dev/sdd : c’est identique. Mais je vais être plus précis pour les deux essais :slight_smile:

—menu de grub2-OMA, donc avec le thème OMA
—suite du processus de démarrage : plymouth
—puis arrivée sur le “greeter” avec le thème OMA

C’est bizarre autant qu’étrange ce passage par “plymouth” : sauf erreur de ma part, il n’y a par de référence à “plymouth” dans “grub.cfg”.
Dernière précision utile : les seules mises à jour installés sont celles du gestionnaire de logiciel.
Abandon des mises à jour du kernel à cause des dépendances non “satisfaisables” kernel header.
Pour le moment, je suis satisfait par les essais avec grub2 : intéressant.

2 Likes

Dernières nouvelles pour cette version d’OMA.
Abandonnant la mise à jour par lignes de commandes, j’ai utilisé l’outil graphique du CCM bien plus convivial. Résultats :slight_smile:
—impossible de mettre à jour Firefox vers la version 53
—mise à jour de quelques outils, mais impossible de mettre à jour Dolphion et dépendances
—MISE À JOUR DE GRUB2 : C’EST CETTE MISE À JOUR QUI EMPÈCHE LE REDÉMARRAGE PAR LE GRUB2 D’OMA, BIEN QUE LE CODE GRUB2 DE MAGEIA 5 DANS /dev/sdc AIT ÉTÉ ÉCRASÉ LORS DE LA MISE À JOUR : LE SYSTÈME NE PEUT SE DÉMARRER LUI-MÊME APRÈS.
J’aimerais savoir si quelqu’un a ce genre d’ennuis sur un ordi avec carte mère de 2007/2008 P4M890M7-TE, et plusieurs disques durs.
J’abandonne car c’en est trop et essaye l’ISO LXQt 1090 en cours de téléchargement.

En virtualbox ou en disc dur?

De toute façon en live mode vous verrez ce genre d’écrans, mais pas de soucis. Il suffit simplement de cliquez sur l’élément souhaité… et avoir confiance :smile:

https://discourse-static.openmandriva.org/uploads/default/original/1X/e78cbd13d9edce2728592f9c680e0653297239b9.png

Merci.
Vu la beauté de ta réponse en Français, je me demande quelle est ta langue maternelle : Français ou Italien?
J’installe toujours en dur, car ma config n’est pas flèche :slight_smile:
–deux barrettes de 2 Go = 3,5 Go : limitation chipset
–Dual Core 2 à 2.5 GHz
J’espère que le Français est disponible, car je maîtrise pas l’Anglais, encore moins l’Allemand.

Je vous remercie monsieur :smile:
Italien, mais j’adore la langue Française.

Les langues sont les mêmes que celles de la version Plasma, je crois.

A post was split to a new topic: Les langues et les concepts

Sauf erreur de ma part, lors de l’installation d’OMLx, il est toujours possible de choisir le disque sur lequel sera installé le gestionnaire d’amorçage.
Lors des tests, il est fortement recommandé d’insérer une clé usb avant de démarrer l’installation du système et de la choisir pour installer grub2.
Ainsi les autres versions ne seront pas modifiées. Ensuite, il suffira soit d’ajouter l’entrée OMLx dans le fichier de config d’origine soit de démarrer sur la clé.

Sauf erreur de ma part, lors de l’installation d’OMLx, il est toujours possible de choisir le disque sur lequel sera installé le gestionnaire d’amorçage.

Tout à fait d’accvord jcl, et même de l’installer “nulle part” (super!).

Les problèmes viennent de :slight_smile:

variation de la / quand l’ordi contient plusieurs disques
—pas d’outil natif à OMA, comme dans les versions précédentes et Mandriva

D’où dans ma configuration, lors de mises à jour de grub2, l’éventualité de l’écrasement du MBR de Mageia, et peut-être même de l’écrasement du MBR-XP.
Déjà; si le nommage “udev” de la partition / était constant, cela irait mieux.
En plus de cela, vu que l’outil de Plasma pur paramétrer l’environnement de grub2 impose ses options et ne mémorise pas les choix de l’utilisateur.
Lors de mises à jour du kernel et/ou de grub2, le choix par défaut pour grub2 est /dev/sda, alors que dans Mageia, PCLinuxOS, OMA versions précédents, et les Mandriva où cela est fixé dans le CCM.
C’est pour cela que je trouve vraiment intéressante l’ISO de LXQt publiée par bero, où j’spèrais la présence de l’outil de configuration système de bero.
Avec OMA, vu que la / varie, j’installerai obligatoirement grub2 dans la /, cela étant validé par son UUID.
Si la / est fixe dans Mageia et PCLinuxOS, cela doit être possible pour OMA.
Etant donné que la dernière installation/mise à jour d’OMA a échoué, je vais installer la version 2007-PWP-Mandriva afin de vérifier si Mandriva avait ce problème de variation de la /. Même si c’est grub-legacy, cela n’est pas génant pour la démarrer par grub2 par chainage (os-prober désactivé) où par grub2 avec os-prober activé.

Quant à l’ISO LXQt, il y a un problème lié à la carte graphique, évoqué dans une autre discussion.