Connexion

Forum

Système et matériels » Installation et configuration Démarrage Mageia 7.1 aléatoire en 32bits sur Acer Aspire

Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 09/08/2019 à 15h37
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] Edité par Papoteur Le 06/09/2019 à 13h39
   
Jybz Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 10/10/2018 à 10h26

Messages: 1914

Le 09/08/2019 à 16h05
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.
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1523

Le 11/08/2019 à 10h22
Bonjour,

Citation :
j'arrive à démarrer correctement 1 fois sur 5 à 10


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") ?
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 12/08/2019 à 19h47
Bonjour et merci pour vos réponses.
J'ai essayé d'appliquer ce que vous préconisez:
Jybz :
Supprimer les fichier efi de la partition esp qui ne correspondent plus à aucun OS présent,

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).
Jybz :
Supprimer les partition racine des systèmes qui n'existent plus

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.
Jybz :
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).

Fait, mais ça ne change rien. Par contre # update-grub2 donne:
update-grub2
Mot de passe :
Création du fichier de configuration GRUB…
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
Thème trouvé : /boot/grub2/themes/maggy/theme.txt
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
Image Linux trouvée : /boot/vmlinuz-5.1.14-desktop-1.mga7
Image mémoire initiale trouvée : /boot/initrd-5.1.14-desktop-1.mga7.img
/dev/sdb: open failed: No medium found
/dev/sdb: open failed: No medium found
fait

Je ne sais pas trop d'ou vient ce /dev/sdb qui n'existe pas… Est-ce que le problème viendrait de là ?
Jybz :
Si tu as supprimé des fichier EFI, va dans le bios du PC et supprime les entrées vers ces fichiers EFI.

Ça j'ai pas trouvé, mais c'est un vieux PC, je ne suis pas sûr qu'il y avait EFI à l'époque.
Jybz :
Si ça ne suffit pas, il faudra penser à éditer manuellement les fichiers de grub.

Pas encore essayé non plus.

nic80 :
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") ?

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. Edité par Goalgauth Le 12/08/2019 à 19h50
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1523

Le 12/08/2019 à 20h02
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) Edité par nic80 Le 12/08/2019 à 20h07
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 12/08/2019 à 21h03
nic80 :
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) ?

À 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
/dev/neon-vg/lv_mageia / ext4 noatime,acl 1 1
# Entry for /dev/sda1 :
UUID=465cb2ca-b5cd-45f1-a6bf-046f3c454421 /boot ext4 noatime,acl 1 2
/dev/neon-vg/root /home ext4 noatime,acl 1 2
none /proc proc defaults 0 0
/dev/neon-vg/swap swap swap defaults 0 0


nic80 :
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)

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

Rang

Avatar

Inscrit le : 04/07/2017 à 19h52

Localisation : Gironde

Messages: 413

Le 14/08/2019 à 15h06
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 :hehe: .
   
Papoteur Membre non connecté

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 6804

Le 14/08/2019 à 18h27
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.


Yves
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 16/08/2019 à 14h50
Papoteur :
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é.

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…;)

Papoteur :
- la sortie de fdisk -l /dev/sda pour connaître la table des partitions (ou un équivalent pour le LVM) ?


# fdisk -l /dev/sda
Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : CT1000MX500SSD1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x8da21a8e

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 1499135 1497088 731M 83 Linux
/dev/sda2 1501182 1953523711 1952022530 930,8G 5 Étendue
/dev/sda5 1501184 1953523711 1952022528 930,8G 83 Linux



# pvdisplay
/dev/sdb: open failed: Aucun médium trouvé
--- Physical volume ---
PV Name /dev/mapper/crypt_sda5
VG Name neon-vg
PV Size 930,79 GiB / not usable 2,00 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 238283
Free PE 0
Allocated PE 238283
PV UUID 9c3iXy-h1Up-KDzx-Auzv-savo-In3G-ZsYMuz



# vgdisplay
/dev/sdb: open failed: Aucun médium trouvé
--- Volume group ---
VG Name neon-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 930,79 GiB
PE Size 4,00 MiB
Total PE 238283
Alloc PE / Size 238283 / 930,79 GiB
Free PE / Size 0 / 0
VG UUID PRmmN4-DBvH-nhWq-cOXc-Y7Zx-iVPb-HJB3qJ



# lvdisplay
/dev/sdb: open failed: Aucun médium trouvé
--- Logical volume ---
LV Path /dev/neon-vg/root
LV Name root
VG Name neon-vg
LV UUID dcaj7c-udZ3-7ovK-r5pT-T1Ht-CMYJ-1y5oGT
LV Write Access read/write
LV Creation host, time neon, 2019-01-23 22:05:29 +0100
LV Status available
# open 1
LV Size 908,06 GiB
Current LE 232464
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:3

--- Logical volume ---
LV Path /dev/neon-vg/swap
LV Name swap
VG Name neon-vg
LV UUID HS1X2p-0QKP-ZlRK-TH5f-bLn3-hjUv-UDdrJh
LV Write Access read/write
LV Creation host, time localhost, 2019-07-06 22:48:17 +0200
LV Status available
# open 2
LV Size <3,92 GiB
Current LE 1003
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:2

--- Logical volume ---
LV Path /dev/neon-vg/lv_mageia
LV Name lv_mageia
VG Name neon-vg
LV UUID a7lwLL-piWJ-ofrH-Z2Kg-C6t0-17qP-w9yoQ4
LV Write Access read/write
LV Creation host, time localhost, 2019-07-06 22:49:48 +0200
LV Status available
# open 1
LV Size 18,81 GiB
Current LE 4816
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:1


Papoteur :
- 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).

[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.

Yuusha :
Je pense que le problème vient du LVM chiffré.

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

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 6804

Le 16/08/2019 à 16h49
Citation :
/dev/sdb: open failed: Aucun médium trouvé

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 ?


Yves
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 16/08/2019 à 18h33
Papoteur :
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 :
# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 août 16 18:23 /dev/sdb

Mais il n'apparait pas dans le fstab:
# kwrite /etc/fstab
/dev/neon-vg/lv_mageia / ext4 noatime,acl 1 1
# Entry for /dev/sda1 :
UUID=465cb2ca-b5cd-45f1-a6bf-046f3c454421 /boot ext4 noatime,acl 1 2
/dev/neon-vg/root /home ext4 noatime,acl 1 2
none /proc proc defaults 0 0
/dev/neon-vg/swap swap swap defaults 0 0

Je n'arrive pas à le retirer du volume logique:
# vgreduce neon-vg /dev/sdb
File descriptor 19 (socket:[25945]) leaked on vgreduce invocation. Parent PID 6096: bash
File descriptor 20 (socket:[26502]) leaked on vgreduce invocation. Parent PID 6096: bash
File descriptor 32 (socket:[27194]) leaked on vgreduce invocation. Parent PID 6096: bash
File descriptor 33 (socket:[27195]) leaked on vgreduce invocation. Parent PID 6096: bash
File descriptor 34 (socket:[26498]) leaked on vgreduce invocation. Parent PID 6096: bash
File descriptor 38 (socket:[27682]) leaked on vgreduce invocation. Parent PID 6096: bash
/dev/sdb: open failed: Aucun médium trouvé
Failed to find device for physical volume "/dev/sdb".
Edité par Goalgauth Le 16/08/2019 à 18h35
   
Papoteur Membre non connecté

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 6804

Le 17/08/2019 à 17h39
Bonjour,
La commande
Code BASH :
vgscan

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/


Yves
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 26/08/2019 à 22h39
Bonjour, j'ai essayé vgscan, ça me montre le problème, mais ça ne le corrige pas…
# vgscan
Reading all physical volumes. This may take a while...
/dev/sdb: open failed: Aucun médium trouvé
Found volume group "neon-vg" using metadata type lvm2

J'ai essayé aussi :
# vgreduce neon-vg /dev/sdb
/dev/sdb: open failed: Aucun médium trouvé
Failed to find device for physical volume "/dev/sdb".

Et :
# pvremove /dev/sdb
/dev/sdb: open failed: Aucun médium trouvé
Device /dev/sdb excluded by a filter.
   
Goalgauth Membre non connecté

Rang

Avatar

Inscrit le : 14/11/2016 à 21h53

Messages: 12

Le 06/09/2019 à 11h57
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).
   
Papoteur Membre non connecté

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 6804

Le 06/09/2019 à 17h13
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.


Yves
   
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie