Connexion

Besoin d'aide ? Une question ? Un avis ? Rejoignez nous sur notre salon IRC pour clavarder

Forum

Système et matériels » Installation et configuration 3 minutes d'attente au démarrage "cannot open file fr-latin9.uni"

pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 11h50
Bonjour,
Après avoir installé Mageia7 (pas une maj) j'ai systématiquement ce message et un compteur "UDEV" qui attend 2mn57s pour lancer le reste. Pendant ce temps mon clavier USB ne fonctionne pas.
Une fois KDE lancé tout est normal. J'ai essayé de modifier la disposition du clavier dans le CCM sans succès.

A croire mes recherches il semble que je soit le seul au monde a avoir ce problème! Pas trouvé l'emplacement du fichier manquant ou abîmé? Edité par pepit Le 09/05/2020 à 17h40


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
Yuusha Membre non connecté

Rang

Avatar

Inscrit le : 04/07/2017 à 19h52

Localisation : Gironde

Messages: 668

Le 09/05/2020 à 12h31
Bonjour,

Il semble que quelqu'un est déjà connu ce problème mais il s'était réglé tout seul. Des recherches sur internet semblent indiquer que ce type de fichier provient du paquet kbd. Cependant il n'y a pas de fichier latin9.uni mais des noms approchant. Je tenterai tout de même un
Code BASH :
urpmi kbd

Si cela ne donne rien, il faudrait nous donner le résultat de la commande (en root) :
Code BASH :
journalctl -b
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 13h59
Oui, j'ai trouvé ça ici:
https://forums.mageia.org/en/viewtopic.php?f=15&t=12546

J'essaie tes manips et te tiens au courant...

Code :
[root@wawa ~]# urpmi kbd
Le paquetage kbd-2.0.4-2.mga7.x86_64 est déjà installé
    

Quant à la commande du journal, t'es sur, ça me renvoie un nombre incalculable de ligne et rien sur le problème?
Edité par pepit Le 09/05/2020 à 17h38


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
Yuusha Membre non connecté

Rang

Avatar

Inscrit le : 04/07/2017 à 19h52

Localisation : Gironde

Messages: 668

Le 09/05/2020 à 15h43
pepit :
Quant à la commande du journal, t'es sur, ça me renvoie un nombre incalculable de ligne et rien sur le problème?

Il faudrait essayer de le faire juste après le démarrage pour avoir moins de lignes. Peut-être sans lancer plasma, en passant dans un terminal virtuel avec [Ctrl]+[Alt]+[F3]. On limiterait déjà pas mal de lignes. Ensuite tester un grep latin sur le journal. Dans le style (en root) :
Code BASH :
journalctl -b | grep latin

Si tu vois des erreurs tu peux le rediriger vers un fichier pour le copier ici.
Code BASH :
journalctl -b | grep latin > /home/monUtilisateur/jounal.txt
   
Papoteur Membre non connecté

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 7542

Le 09/05/2020 à 15h48
Bonjour,
Pour obtenir le journal, en root (sinon il manquerait des infos) :
Code BASH :
journalctl -b --no-pager >journal.txt
chown pepit:pepit journal.txt

et tu devrais pouvoir récupérer le fichier journal.txt.
Je ne vois pas de lien entre udev et fr-latin9-uni


Yves
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 15h49
Code :

[root@wawa ~]# journalctl -b | grep latin
mai 09 10:19:49 wawa.pep drakkeyboard[5127]: running: setxkbmap fr -variant latin9 -model microsoft4000 -option compose:rwin -compat
mai 09 10:19:49 wawa.pep drakkeyboard[5127]: running: loadkeys fr-latin9
mai 09 10:19:49 wawa.pep drakkeyboard[5127]: keyboard::write fr_latin9


Bon, je redémarre et je reviens vers vous, mais aucun défaut lié n'apparait (a priori) j'arrive à voir des défauts avec "dmesg", je peut vous poster ceux là si vous voulez.

J'ai aussi un souci avec mon disque SAS, pas reconnu par le système au redémarrage alors que bien pris en compte lors de l'installation. Seul mon SSD "système" est OK, j'ai du enlever l'entrée dans le "fstab" pour ne pas ralentir plus le système en attendant de résoudre le problème du clavier.
Edité par pepit Le 09/05/2020 à 16h07


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 2386

Le 09/05/2020 à 16h08
Bonjour,

Le clavier étant usb, est ce qu' il y a d' autres périphériques usb qui seraient branchés ?

Les rôle d' udev est d' "écouter" les messages noyaux en regard de ce qui est matériel et d' effectuer certaines actions en fonctions des règles définies.

Petite question, quand le clavier usb ( qui peut être branché ultérieurement) est débranché lors du démarrage de la machine, est ce que le délai est toujours aussi long ? Si oui, on peut exclure le fait que cela puisse venir du clavier en lui même mais peut être plus du "hub" usb et des périphériques connectés dessus (cela peut être un périphérique usb connecté physiquement, mais également d' un périphérique interne qui utiliserait le bus usb.

edit: le disque SAS est toujours branché physiquement ? Dans ce cas, rien n' empêche le noyau de le voir (même si l' entrée dans le fstab est commentée ( d' ailleurs il me semble qu' il y a un processus qui vérifie à chaque démarrage si de nouveaux périphériques ont été ajoutés).

edit 2: Dans le post indiqué, il est fait mention d' un défaut de fichier clavier, mais aucunement d' un délai plus long au démarrage, ni d' un blocage d' udev... Comme il s' agit d' un clavier azerty, peut être que si l' auteur du post sur le forum international passe par ici, cela lui rappellera des souvenirs ( d' ailleurs n' utiliserait t' il pas un clavier bépo désormais :siffle: ) ?


Edité par nic80 Le 09/05/2020 à 16h18
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 16h42
Alors le liens avec UDEV, les messages d'erreurs sont imbriqués le voici:
https://drive.google.com/file/d/1GTGzAxcfjugP9661Lsozn-HtMGwFIncn/view?usp=sharing

Si j'ai des accessoires USB? Oui, plusieurs hub déjà dans la CM et 1 externe et à part le clavier, la souri, l'ups, rien d'extraordinaire.
J'ai aussi un clavier de secour sur ps2, en cas de bug sur l'usb (c'est très rare mais ça arrive et c'est pénible).

Le SAS "virtuel" est sur un PCIE et fonctionne avec 4 DD en mode RAID 5 je crois. Edité par pepit Le 09/05/2020 à 16h43


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 16h52
Je le partage comme ca sinon trop gros pour être intégré "pacifiquement" ici!
journalctl:
https://drive.google.com/open?id=1fvFn3vJHw6nUaSyq4fXUd2XuvJq_zlE7

dmesg:
https://drive.google.com/open?id=1NFyekgzyLjW-wk0TXjbYsuCT2LRM3OqW

J'ai redémarré sans clavier USB ni souris = même problème.

Avec mageia6 tout fonctionnait bien à part le serveur d'affichage car montage SLI mal digéré et rien changé à part l'OS (si ça peut aider)!...

Autres détails :
- Il ne s’arrête pas tout seul, il reste bloqué sur: "reached target Reboot".
- Le noyau installé par défaut: "kernel-desktop-5.6.8-1.mga7" Hors il me semble que sous magieia6 celui par défaut était un "server", peut être une piste pour le SAS RAID?...
Edité par pepit Le 09/05/2020 à 19h33


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 2386

Le 09/05/2020 à 18h12
Bonjour,

Le journal udev n' est pas ouvrable ( et tout le monde n' a pas de compte Google...)

Pour ce que j' en ai vu, je me demandes si le problème ne vient pas du volume raid...

En effet, dans le journal (ou dans le dmesg qui est sensiblement le même pour le démarrage), on voit que udev butte sur un worker[670] qui semble très long et à la fin, on voit que c' est le process qui est tué car plus long que 122 secondes et enfin un bon dump du noyau (relatif au volume raid (peut être engendré par l' arrêt du process).

Cependant, je ne vois pas comment le volume raid pourrait être désactivé ( je suppose que c' est lui qui contient les données, non ?) pour voir si ce serait lui le coupable du démarrage lent...

edit: d' ailleurs, il semble que l' interface usb de l' onduleur provoque un timeout ( comme le raid et celui ci sont sur le même bus ( enfin je suppose 0003) , est ce que l' un ne génerait pas l' autre ?). Comme l' onduleur ne communique que par usb, que ce passe t' il si on le débranche pour les tests ? Edité par nic80 Le 09/05/2020 à 18h18
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 09/05/2020 à 21h10
Ah, désolé, c'est ce que j'ai trouvé d'utilisable, je suis surpris qu'il faille un compte Google pour accéder à ces fichiers!?
Il est écrit:
"A start job is running for udev Wait for Complete Device Initialization (5s / 2min 57s)"
parfois inséré entre plusieurs lignes "cannot open file fr-latin9.uni"

Oui, c'est mon disque de données, les systèmes (dual boot) comme indiqué dans ma signature sont sur un SSD.
Je passe par une carte de type serveur SAS dans un slot PCIE.
Il y a 4 disques en raid5 dans la tour.

Je n'avait pas de problème avec mageia6 et pas de problèmes non plus avec windows10.
L'installeur Magéia avais pourtant bien détecté le disque SAS et configuré le "fstab" en conséquence.

Mais tu dois avoir raison, ça semble lié avec mon mégaraid car j'ai fait un essais UPS débranché: pareil.
Puis j'ai essayé avec le noyau "serveur" en mode normal: Encore plus lent.
Ensuite nouvel essais en mode "recovery" et là il y a un paquet de message se rapportant au megaraid se répétant plusieurs fois et le "cannot open file fr-latin9.uni" n'apparait pas.
Edité par pepit Le 24/05/2020 à 15h10


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 2386

Le 09/05/2020 à 22h10
Bonjour,

Je me demande si le fait que ce soit détecté lors de l' installation puis que cela ne fonctionne plus après ne serait pas du à passage d' un noyau 5.1.14 ( qui est le premier noyau utilisé par Mageia 7) à un noyau supérieur au 5.2.

https://bugzilla.kernel.org/show_bug.cgi?id=204761

J' ignore si ce potentiel bug aurait pu être corrigé dans les versions suivantes.
   
pepit Membre non connecté

Rang

Avatar

Inscrit le : 01/10/2012 à 22h44

Localisation : Proche Lyon

Messages: 77

Le 10/05/2020 à 01h00
Si ça peut apporter des éléments de réponses: J'ai fait l'installation en ligne avec une clé USB contenant "mageia-7.1-x86_64-netinstall", il est indiqué à l'intérieur: "Mageia release 7 Fri Jul 12 12:44:09 2019 5.1.14-desktop-1.mga7".

Ca fait plusieurs mois que je l'ai téléchargé pour installer le système sur un autre PC (plus simple) de ma maisonnée, et ça confirme ton hypothèse.

Il est tard, mais demain je ferai des essais avec des noyaux plus anciens que "kernel-desktop-5.6.8-1.mga7" < au "5.2" dans un premier temps.
A moins que ce ne soit qu'une histoire d’appellation "UUID"?... Edité par pepit Le 10/05/2020 à 01h06


Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 2x4go ram, CG 2 x gtx950 SLI, 1 samsung ssd 850 systèmes, 4 sas raid5 de données (3+1secour) début sur Red hat, puis Mandrake 7, Mandriva, en passant par Corel, Suse, Debian, Gentoo, Arch.
   
Yuusha Membre non connecté

Rang

Avatar

Inscrit le : 04/07/2017 à 19h52

Localisation : Gironde

Messages: 668

Le 10/05/2020 à 01h19
En regardant les logs on s'aperçoit qu'il y a bien un problème au niveau de udev et de l'usb :
Caché :
[ 44.467893] usbcore: registered new interface driver usbhid
[ 44.467895] usbhid: USB HID core driver
[ 44.474335] hid-generic 0003:0463:FFFF.0001: hiddev0,hidraw0: USB HID v1.10 Device [EATON Ellipse MAX] on usb-0000:00:14.0-11/input0
[ 44.474532] input: Razer Razer DeathAdder Chroma as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.0/0003:1532:0043.0002/input/input25
[ 44.474673] hid-generic 0003:1532:0043.0002: input,hidraw1: USB HID v1.11 Mouse [Razer Razer DeathAdder Chroma] on usb-0000:00:14.0-12.1/input0
[ 44.475051] input: Razer Razer DeathAdder Chroma Keyboard as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.1/0003:1532:0043.0003/input/input26
[ 44.527023] input: Razer Razer DeathAdder Chroma Consumer Control as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.1/0003:1532:0043.0003/input/input27
[ 44.527141] input: Razer Razer DeathAdder Chroma System Control as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.1/0003:1532:0043.0003/input/input28
[ 44.527236] input: Razer Razer DeathAdder Chroma as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.1/0003:1532:0043.0003/input/input29
[ 44.527324] hid-generic 0003:1532:0043.0003: input,hidraw2: USB HID v1.11 Keyboard [Razer Razer DeathAdder Chroma] on usb-0000:00:14.0-12.1/input1
[ 44.527571] input: Razer Razer DeathAdder Chroma as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.1/2-12.1:1.2/0003:1532:0043.0004/input/input30
[ 44.579000] hid-generic 0003:1532:0043.0004: input,hidraw3: USB HID v1.11 Keyboard [Razer Razer DeathAdder Chroma] on usb-0000:00:14.0-12.1/input2
[ 44.586502] input: Microsoft Natural® Ergonomic Keyboard 4000 as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.2/2-12.2:1.0/0003:045E:00DB.0005/input/input31
[ 44.638140] microsoft 0003:045E:00DB.0005: input,hidraw4: USB HID v1.11 Keyboard [Microsoft Natural® Ergonomic Keyboard 4000] on usb-0000:00:14.0-12.2/input0
[ 44.638684] input: Microsoft Natural® Ergonomic Keyboard 4000 as /devices/pci0000:00/0000:00:14.0/usb2/2-12/2-12.2/2-12.2:1.1/0003:045E:00DB.0006/input/input32
[ 44.689955] microsoft 0003:045E:00DB.0006: input,hidraw5: USB HID v1.11 Device [Microsoft Natural® Ergonomic Keyboard 4000] on usb-0000:00:14.0-12.2/input1
[ 161.501019] device-mapper: uevent: version 1.0.3


Au niveau du journal on observe ces erreurs :
Caché :
mai 09 15:14:01 wawa.pep kernel: microsoft 0003:045E:00DB.0006: input,hidraw5: USB HID v1.11 Device [Microsoft Natural® Ergonomic Keyboard 4000] on usb-0000:00:14.0-12.2/input1
mai 09 15:14:01 wawa.pep systemd-udevd[663]: event31: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
mai 09 15:14:01 wawa.pep systemd-udevd[663]: event31: Failed to call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument
mai 09 15:14:58 wawa.pep systemd-udevd[603]: 0000:03:00.0: Worker [670] processing SEQNUM=5471 is taking a long time
mai 09 15:15:58 wawa.pep systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE

Il y a ici une perte de temps de 57s. mais pas grand chose. Il y a peut-être une accumulation de deux, trois problèmes. Je vois que ton système est complexe : du RAID, du LVM pas mal de périphériques.

Ton idée entre noyau server et desktop est peut-être bonne vu que les options de compilations du noyau doivent être différentes. En tout cas si on trouve les bogues, il serait bon de le signaler car une configuration comme celle-ci est assez rare (ma tour Dell Precision attends depuis plus d'un an de recevoir Mageia :hehe: )
   
Papoteur Membre non connecté

Rang

Avatar

Modérateur Équipe Mageia

Inscrit le : 03/10/2011 à 22h16

Localisation : Metz

Messages: 7542

Le 10/05/2020 à 08h40
Bonjour, En+fait,+c'est+pratiquement+2+minutes+qui+sont+perdues+en+attente+par+udev. le+event31+qui+pose+problème+semble+être+en+lien+avec+un+clavier+Microsoft+:
journal :
systemd-logind[1012]:+Watching+system+buttons+on+/dev/input/event31+(Microsoft+Natural®+Ergonomic+Keyboard+4000)
Une+erreur+de+ce+genre+a+déjà+été+rapportée,+sans+solution+mentionnée+: https://github.com/systemd/systemd/issues/8413


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