Forum

Bonjour,
j'ai installé Mageia 7.1 (mais j'avais le même problème avec Mageia 7.0) sur un vieux portable (Acer Aspire 2920Z) rééquipé d'un SSD.
Au démarrage, après avoir choisi l'entrée par défaut de grub (Mageia), j'arrive à démarrer correctement 1 fois sur 5 à 10 ! La plupart du temps, au lieu d'avoir le chaudron avec le mot de passe pour déchiffrer la partition, j'ai un texte qui défile en boucle tellement vite que je ne peux le lire. Parfois j'ai un écran noir, parfois j'ai le chaudron mais sans que ça aboutisse à la demande de la clef de déchiffrement (dans ce cas si j'appuie sur une touche pour avoir le mode verbeux, je n'ai qu'un curseur "underscore" qui apparait en haut à gauche.
À un moment j'ai réussi à bloquer le texte qui défile (je ne sais pas trop comment) et le prendre en photo et j'obtiens ceci:

[ 5.217712] Code: 83 ec 1c 65 a1 14 00 00 00 89 …
[ 5.217712] EAX: 00000001 EBX: fffffffc ECX: 00000000 EDX: 000000000
[ 5.217712] ESI: c78c86b6 EDI: fffffffc EBP: eb012b0c ESP: eb012aec
[ 5.217712] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010002
[ 5.217712] ? suspend_devices_and_enter+0x88/0x7a0
[ 5.217712] ? show_regs.cold.13+0x14/0x1a
[ 5.217712] __die+0x81/0xc0
[ 5.217712] no_context+0x10d/0x1b0
[ 5.217712] ? sched_clock+0x8/0x10
[ 5.217712] ? string+0x61/0x90
[ 5.217712] __bad_area_nosemaphore.constprop.28+0x39/0x130
[ 5.217712] bad_a_area_nosemaphore+0xf/0x20
[ 5.217712] do_kern_addr_fault+0x4b/0x90
[ 5.217712] __do_page_fault+031c/0x410
[ 5.217712] ? vprintk_emit+0xe4/0x220
[ 5.217712] do_page_fault+0x20/0xf0
[ 5.217712] do_page_fault+0x20/0xf0
[ 5.217712] ? __do_page_fault+0x410/0x410
[ 5.217712] common_exception+0x11d/0x122
[ 5.217712] EIP: print_modules+0x33/0xa2

Puis ça recommence sur:
[ 5.217712] Code: 83 ec 1c 65 a1 14 00 00 00 89 …

Je ne sais pas si ça peut avoir son importance, mais le SSD est formaté avec une partition boot et une partition en LVM chiffrée (faite avec KDE neon) contenant une racine, un home et un swap (alors que si je me souviens bien kde neon avait une partition racine et home commune que j'ai redimentionnée sans la reformater pour en faire le home). Cela m'a créé quand même une entrée KDE neon dans le grub (quand je cliquait dessus ça me faisait booter sur mageia initialement, maintenant ça bloque en me disant que la partition est vide).

Une question que je me pose c'est est-ce qui ne faut pas reformater le disque au propre ? mais ça m'embête un peu de resynchroniser plus de 800 Go de données avec nextcloud…
Si quelqu'un a autre une idée… merci d'avance.
[Edit papoteurRectification du titre, problème d'accès]

Édité par Papoteur Le 06/09/2019 à 13h39

Ouh là... il faudrait commencer par un gros nettoyage manuel...
Supprimer les fichier efi de la partition esp qui ne correspondent plus à aucun OS présent,
Supprimer les partition racine des systèmes qui n'existent plus
tenter un premier nettoyage de grub avec le CCM → démarrage → démarrage du système.
S'il n'y a aucun autre système que mageia, je propose de décocher l'option pour vérifier que d'autres systèmes sont présent
valider
pour s'assurer du bon résultat, dans une console, on se connecte en root, et on remets à jours grub avec
# update-grub2 (si tu utilises grub2, sinon juste grub si tu n'utilisais que grub).
Si tu as supprimé des fichier EFI, va dans le bios du PC et supprime les entrées vers ces fichiers EFI.

J'espère que ça suffira. Si ça ne suffit pas, il faudra penser à éditer manuellement les fichiers de grub.

Bonjour,



Ca c' est vraiment de l' aléatoire.

Est ce que le démarrage s' effectue de manière différente entre un démarrage normal et un anormal ( sortie de veille/ de l' état "suspend/hibernate") ?

Bonjour et merci pour vos réponses.
J'ai essayé d'appliquer ce que vous préconisez:

Tu veux parler de la partition boot ? j'ai vérifié, rien d'autre que du mageia dedans (de toute façon je l'ai formatée à l'installation).

Fait, mais comme j'ai du me tromper j'ai effacé aussi la partiton /bin de /, le système n'a pas aimé… J'ai du réinstaller Mageia. J'en ai profité pour ne laisser que mon dossier personnel dans /home. Mais ça n'a rien changé. Je n'ai pas reformaté et rechiffré LVM (qui contient tout sauf /boot: /, home, swap). Elle avait été faite sous KDE neon, mais je ne pense pas que le problème vienne de là car ça bloque juste après le grub, avant que ça me demande de déchiffrer la partition. À moins que ce ne soit justement les difficultés d'accès au déchiffrage de la partition avant qu'on me demande la clef. J'avoue que je n'ai pas trop envie de le faire pour éviter d'avoir à remettre tous mes fichiers perso.

Fait, mais ça ne change rien. Par contre # update-grub2 donne:

Je ne sais pas trop d'ou vient ce /dev/sdb qui n'existe pas… Est-ce que le problème viendrait de là ?

Ça j'ai pas trouvé, mais c'est un vieux PC, je ne suis pas sûr qu'il y avait EFI à l'époque.

Pas encore essayé non plus.


Oui c'est pareil entre l'arrêt normal et une sortie d'hibernation (la veille par contre n'a jamais marché sur ce PC quelque soit l'OS).
Par contre, de temps en temps ça bloque aussi après avoir entré ma clef de déchiffrement, mais heureusement pas très souvent.

Édité par Goalgauth Le 12/08/2019 à 19h50

Bonjour,

Est ce que sdb pourrait être une clé usb ou un lecteur cd ou un lecteur de carte qui aurait été enlevée et qui aurait laissé une trace dans un fichier de configuration (/etc/fstab) ?

Aprés mes connaissances sur le chiffrement de partitions sont nulles (donc dans connaitre le processus, ça va être diffficile ! )

Après je doute qu' il y ait confusion uuid...

Est ce que dans le bios/uefi, il y a possibilité de désactiver temporairement les périphériques qui pourraient s' apparenter à un disque (autre que disque qui contient le système bien entendu)

Édité par nic80 Le 12/08/2019 à 20h07

À priori non, c'était probablement la clef usb d'installation, mais elle n'est plus branchée. Il n'y a pas l'air d'avoir de trace dans /etc/fstab



À priori, ce n'est pas possible je ne peux que modifier les priorités d'amorçage.

Bonjour,

Je pense que le problème vient du LVM chiffré. À ma connaissance, peu de gens installent Mageia en LVM (et encore moins en LVM chiffré) et je ne suis pas sûr que la gestion soit parfaite.
Installé une Mageia 7 en LVM est dans ma liste des taches mais je ne sais pas si j'aurai le temps .

Bonjour,
D'après ce rapport de bug, https://bugs.mageia.org/show_bug.cgi?id=24949 la mise à niveau de 6 à 7 d'un système avec LVM nécessite de supprimer manuellement udisks. Mais ce ne sont pas les symptômes décrits ici.
Tu as bien une partition /boot séparée et non chiffrée, donc pas de problème de ce côté.
Peux-tu nous fournir :
- la sortie de fdisk -l /dev/sda pour connaître la table des partitions (ou un équivalent pour le LVM) ?
- le journal d'un démarrage qui échoue (journalctl -xb -1 > journal.txt au démarrage suivant en root, et récupérer le fichier journal.txt).

Le fonctionnement aléatoire me fait penser à un problème de synchronisation, donc à un souci avec systemd.

Effectivement, je n'ai pas accès à une console et je n'ai pas la possibilité d'utiliser ctrl-D (quoique je n'ai pas essayé, mais comme je dois souvent redémarrer de force…











[block][/block]
Journalctl ne semble prendre en compte que les démarrages réussis… j'ai testé également sans option, avec l'option -p err, mais c'est pareil.


Une réinstall sans LVM sera ma prochaine étape si je ne trouve pas d'autre solution…

Ce message à répétition me fait penser à un problème de configuration du LVM. Mais je n'y connais rien. Le LVM a-t-il été configuré initialement lorsqu'il y avait un deuxième disque ?

Je pense que /dev/sdb était la clef usb utilisée pour l'installation, mais c'est étrange qu'il y ait une trace de ça.
Je retrouve une trace en faisant :

Mais il n'apparait pas dans le fstab:

Je n'arrive pas à le retirer du volume logique:

Édité par Goalgauth Le 16/08/2019 à 18h35

Bonjour,
La commande

devrait mettre à jour un cache et faire disparaître l'alerte sur le média non trouvé.
Référence : https://ciphermethod.com/red-hat-5-hdc-open-failed-no-medium-found/

Bonjour, j'ai essayé vgscan, ça me montre le problème, mais ça ne le corrige pas…

J'ai essayé aussi :

Et :

Bonjour,
Voici où j'en suis:
Après avoir bidouillé pour essayer de réduire mon volume chiffré pour réinstaller le système sur l'espace libéré, j'ai fini par tout réinstaller au propre. J'ai tout essayé: avec le CD d'installation plutôt que la clef USB, en partition chiffrée comme non chiffrée, et même (cela ne m'arrive pas souvent) en laissant l'installateur utiliser tout le disque comme il veut. À chaque fois le même problème de démarrage aléatoire, et il y avait toujours le message comme quoi /dev/sdb n'était pas trouvé (même quand l'install était faite à partir du CD).
En dernier recours, j'ai tenté l'install en 64 bits (à partir de la session live sur une clef USB) et là : miracle ça marche !!

C'est donc un problème qui semble spécifique à la version 32 bits et à cet ordinateur (car j'ai fait une install 32 bits à partir de la même image iso sur un autre PC sans souci).
Je modifie mon titre en mettant que c'est pour la version 32 bits, mais je ne pense pas qu'il faille mettre résolu néanmoins. Pensez-vous qu'il fasse faire un rapport de bug ?

Va falloir quand même que je dégotte une petite barrette de RAM supplémentaire car les 2 Go c'est un peu light parfois (quoique le swap sur le SSD, c'est assez confortable).

Content que tu aies trouvé une solution. Tu peux faire le rapport de bogue si le problème est reproductible. Mais il faut dans ce cas être prêt à faire des expériences et des compte-rendu.