Forum

Reprise du message précédent

Si le boot plante avant systemd, il faut passer àu débug de l'initrd, en ajoutant rd.debug=1

Je ne vais pas m'aventurer plus loin dans le hors sujet. Il semble que le comportement soit différent dans Ubuntu et que l'utilisateur ait accès aux informations du système. Je pense que c'est une mauvaise chose. D'autre part, en mode lecture.
Nic80, merci pour la vérification.

Il semble qu'Ubuntu (ou Debian) soit aux prises avec des demandes inutiles de mot de passe de superutilisateur. Linus Torvalds lui-même s'est plaint de ces demandes.

Édité par Visiteur Le 07/03/2024 à 19h55

Le man de journalctl donne la réponse. Si vous appartenez à l'un des groupes suivants : systemd-journal, adm ou wheel, vous avez accès à tous les journaux. Ne pouvant préjuger qu'un utilisateur appartient à l'un de ces groupes, il vaut mieux conseiller de lancer le journal en root.

J’ai démarré mon PC avec la 1ère ligne du menu Grub (noyau 6.6.18) → blocage immédiatement après avoir sélectionné la ligne → petite boule qui sort du chaudron.
Puis j’ai démarré mon PC avec la 2ème ligne du menu (noyau 6.6.14) → root → OK.
J’ai crée un 1er fichier journal avec la commande journalctl --no-hostname -b -1 >journal.txt
Puis j’ai créé un 2ème fichier journal avec la commande journalctl -b -1 >journal.txt
Ces 2 fichiers commencent par localhost kernel: Linux version 6.6.14-desktop-2.mga9

Je crois comprendre que je ne peux rien faire d’autre (je ne sais rien faire d’autre !). Le démarrage avec le noyau 6.6.18 ne s ‘effectuant pas, il n’y a pas de données correspondantes générées ...

Merci à tous de réfléchir pour la résolution du problème.
Je pense clairement qu’un bug a été créé pour la mise jour vers le noyau 6.6.18.
Pour gagner du temps (pour vous et pour moi !), ne suffit-il pas d’attendre la prochaine mise à jour du noyau avec le bug corrigé ?

Bonjour,

Si ne sait pas l' origine du bug,il sera difficile de le corriger

Pour la bulle qui s' affiche, on doit pouvoir ajouter une option à la ligne de commande de grub. Il me semble que ç' est l' option "quiet"

Pour la rajouter, il faut dans le grub selectionner la ligne qui plante puis l' editer (touche 'e') à la fin de la ligne qui commence par linux ajouter quiet et rd.debug=1
Lancer la.ligne modifée en faisant la combinaison ctrl+x

nic80 :

Bonjour,

Si ne sait pas l' origine du bug,il sera difficile de le corriger

Pour la bulle qui s' affiche, on doit pouvoir ajouter une option à la ligne de commande de grub. Il me semble que ç' est l' option "quiet"

Pour la rajouter, il faut dans le grub selectionner la ligne qui plante puis l' editer (touche 'e') à la fin de la ligne qui commence par linux ajouter quiet et rd.debug=1
Lancer la.ligne modifée en faisant la combinaison ctrl+x

Je dirais plutôt qu'il faut retirer "splash quiet" qui existe déjà. Les autres indications sont pertinentes.
Ceci n'affichera pas l'écran bleu, certes sympathique, mais qui masque des informations forts utiles en la circonstance.

Bonjour,

Suis-je vraiment le seul à avoir eu le problème ?
Les personnes qui ont fait des modifications ne peuvent-elles pas réfléchir et trouver le bug ?!

Je veux bien faire des manips pour aider à trouver le bug, mais il faut que vous m’indiquiez précisément comment faire, je ne suis pas expert de Linux ni des lignes de commandes.
J’ai essayé de modifier une commande de démarrage de Grub par la touche « e » mais je n’ai pas réussi à sauvegarder ma modification.
Quand je dis « J’ai démarré mon PC avec la 1ère ligne du menu Grub (noyau 6.6.18) → blocage immédiatement après avoir sélectionné la ligne → petite boule qui sort du chaudron. », ce n’est pas immédiatement anormal, c’est l’écran animé habituel, mais le voyant d’activité du SSD / DD reste éteint, le PC est bloqué. Je dois couper l’alimentation pour le redémarrer.

Papipio :

Suis-je vraiment le seul à avoir eu le problème ?

Oui.

Papipio :

Les personnes qui ont fait des modifications ne peuvent-elles pas réfléchir et trouver le bug ?!

Non. Je ne vois pas comment vu que l'on ne sait pas grand-chose du problème.
Il y a eu une mise à jour du noyau. Premièrement, ce n'est pas Mageia qui modifie le noyau, mais les développeurs du noyau. Deuxièmement, il y a potentiellement eu des milliers de modifications et chaque PC est différent. Je ne vois pas comment ils pourraient trouver un bug qui est probablement très spécifique.

Papipio :

Je veux bien faire des manips pour aider à trouver le bug, mais il faut que vous m’indiquiez précisément comment faire, je ne suis pas expert de Linux ni des lignes de commandes.

Une manip t'a été indiquée, tu édites l'entrée avec la touche e, tu retires le splash quiet, tu ajoutes rd.debug=1 et tu lances avec [Ctrl]+X. nic80 et papoteur t'avaient déjà tout expliqué.

Merci Yuusha, je vais essayer de faire cette opération.

En utilisant la touche "e" pour éditer la ligne du menu Grub qui fonctionne, j'ai remplacé "6.6.14-desktop-2.mga9" par "6.6.18-desktop-1.mga9" --> mon PC démarre normalement, le noyau en service est bien "6.6.18-desktop-1.mga9".
--> Une idée pour contourner / résoudre le problème en corrigeant définitivement la ligne 1 du menu Grub ?

Pierre

Bonjour,

J’ai essayé de faire la modification comme indiqué (suppression de splash quiet, ajout de rd.debug=1 → Ctrl+X), j’obtiens un écran qui papillote, apparemment des lignes de texte qui défilent très rapidement. Je ne comprends pas clairement ce qu’il faut faire exactement, je n’en suis pas capable …
Je vous propose de laisser tomber mon problème pour le moment …

J’ai « résolu » mon problème en osant modifier le fichier grub.cfg : en modifiant la 2ème ligne du menu grub (Options avancées pour Mageia, qui fonctionne avec le noyau 6.6.14), j’ai remplacé la référence au noyau 6.6.14 par la référence au noyau 6.6.18 : tout fonctionne bien avec le noyau 6.6.18 !

Je verrai si le problème se reproduit avec la prochaine version du noyau diffusée …
Si nécessaire, je réinstallerai Mageia 😢

Pierre

Bonjour,

J’espérais voir mon problème résolu avec la mise à jour vers un nouveau noyau Linux …
Ce matin, a eu lieu la mise à jour vers le noyau 6.6.22. Résultat : mon PC était à nouveau en panne ! Je ne pouvais plus le démarrer par le menu de grub. Le démarrage avec le noyau 6.6.14 que j’avais modifié pour démarrer automatiquement avec le noyau 6.6.18 a été modifié pour effectivement démarrer avec le noyau 6.6.14 !
Je viens de démarrer mon PC en éditant la ligne linux de ce démarrage avec le noyau 6.6.14, en remplaçant 6.6.14 par 6.6.22 → mon PC fonctionne normalement avec le noyau 6.6.22.
Je suis surpris quand vous me dites que personne d’autre n’a ce bug ! Depuis plusieurs années maintenant, j’utilise Mageia, j’effectue les mises à jour et mises à niveau vers une nouvelle version de Mageia en cliquant simplement sur les boutons affichés …
Pourquoi mon PC fonctionnait-il bien jusqu’au noyau 6.6.14 ? Pourquoi maintenant est-il bloqué suite à la mise à jour de grub vers le noyau 6.6.18, puis à nouveau vers le noyau 6.6.22 ?
Une réinstalltion de Mageia (→ galère pour ensuite reconfigurer mon PC … résoudrait-elle mon problème ?
Je ne suis pas du tout expert de Linux et des lignes de commande. Si vous pensez pouvoir / si vous voulez m’indiquer précisément et en détail ce que je dois faire pour me dépanner ou pour trouver la raison du bug (et le résoudre …, je peux essayer …

Dans quelques jours, je vais faire un atelier (3 h de formation) à plusieurs personnes de mon association qui utilisent Mageia (→ mises à jour, mise à niveau vers Mageia 9, configuration) : j’appréhende !

Combien de noyaux sont-ils installés ? S'ils se sont accumulés depuis longtemps il se peut que de la partition de démarrage soit saturée.

Bonjour,

Merci Yves pour ta réponse.
Avec Remove Old Kernels que j'ai découvert dans les outils système, je vois qu'il y a 4 noyaux: 6.5.13-6, 6.6.14-2, 6.6.18-1, 6.6.22-1.
Le noyau 6.6.13 est proposé pour la suppression (en rouge).
Dans quel dossier les noyaux sont-ils enregistrés ?

Si j'utilise la clé USB d'installation de Mageia pour lancer Rescue et régénérer la configuration de Grub, vais-je résoudre mon problème ?

Édité par Papipio Le 29/03/2024 à 06h35

Pourquoi veux-tu le lancer depuis une live si tu arrives à démarrer en modifiant la ligne du grub ? Je pense qu'il faudrait lancer la réparation du GRUB en ligne de commande pour que l'on puisse capturer les éventuels messages d'erreur.

Merci Yuusha pour ta réponse.

J'ai déjà réparé des grub avec la clé USB d'installation de Mageia, je "sais" faire !
Je ne sais pas le faire en ligne de commande !
____

Je viens de modifier grub.cfg en ajoutant comme 1ère ligne du menu la ligne de menu pour le noyau 6.6.14 (le dernier à avoir fonctionné normalement). Pour cette ligne de menu, j'ai modifié la ligne linux pour charger le dernier noyau 6.6.22 --> je peux démarrer mon PC normalement ...

Ci-dessous, la copie de grub.cfg pour les deux 1ères lignes du menu:

menuentry 'Mageia (6.6.22-desktop-1.mga9) 9' --class mageia --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-6.6.14-desktop-2.mga9-advanced-c05f2e14-54b7-4b0f-8287-1c1b13cae035' {
savedefault
load_video
set gfxpayload=auto
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 c05f2e14-54b7-4b0f-8287-1c1b13cae035
else
search --no-floppy --fs-uuid --set=root c05f2e14-54b7-4b0f-8287-1c1b13cae035
fi
echo 'Chargement de Linux 6.6.22-desktop-1.mga9…'
linux /boot/vmlinuz-6.6.22-desktop-1.mga9 root=/dev/sda5 ro splash quiet noiswmd resume=UUID=76ab5f46-23b8-4b56-b68c-56ac682c597b audit=0 vga=791
}
menuentry 'Mageia' --class mageia --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-simple-c05f2e14-54b7-4b0f-8287-1c1b13cae035' {
savedefault
load_video
set gfxpayload=auto
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 c05f2e14-54b7-4b0f-8287-1c1b13cae035
else
search --no-floppy --fs-uuid --set=root c05f2e14-54b7-4b0f-8287-1c1b13cae035
fi
echo 'Chargement de Linux 6.6.22-desktop-1.mga9…'
linux /boot/vmlinuz-6.6.22-desktop-1.mga9 root=UUID=c05f2e14-54b7-4b0f-8287-1c1b13cae035 ro splash quiet noiswmd resume=UUID=76ab5f46-23b8-4b56-b68c-56ac682c597b audit=0 vga=791
echo 'Chargement du disque mémoire initial…'
initrd /boot/initrd-6.6.22-desktop-1.mga9.img
}


Dans la toute 1ère ligne, il reste une trace du noyau 6.6.14 !!! Mais ainsi je peux utiliser mon PC …

Avec la 2ème ligne de menu ‘Mageia’ (initialement la 1ère ligne ; noyau 6.6.22), mon PC se bloque comme il a commencé à le faire après la mise à jour vers le noyau 6.6.14.

Je bidouille ! Car je ne sais pas quoi faire d’autre !!! 😳
Je pense que je ne pourrai pas bidouiller ainsi longtemps ...

Édité par Papipio Le 29/03/2024 à 14h07

Bonjour,
La seule différence notable que je vois est que la deuxième entrée désigne sur la ligne linux la partition racine avec root=UUID=c05f2e14-54b7-4b0f-8287-1c1b13cae035,alors que dans celle qui marche, il y a root=/dev/sda5
C'est assez incompréhensible pour moi puisque la deuxième option devrait être celle qui est à préférer.