delais 3 minutes d attente au demarrage
cannot open file fr-latin9.uni
Système et matériels / Installation et configuration

pepit Membre non connecté
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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é?
Édité par pepit Le 09/05/2020 à 17h40
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
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é
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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?
Édité par pepit Le 09/05/2020 à 17h38
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
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é
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
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é
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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.
Édité par pepit Le 09/05/2020 à 16h07
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
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

Édité par nic80 Le 09/05/2020 à 16h18

pepit Membre non connecté
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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.
Édité par pepit Le 09/05/2020 à 16h43
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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?...
Édité par pepit Le 09/05/2020 à 19h33
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
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 ?
Édité par nic80 Le 09/05/2020 à 18h18

pepit Membre non connecté
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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.
Édité par pepit Le 24/05/2020 à 15h10
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
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é
-
- Voir le profil du membre pepit
- Inscrit le : 01/10/2012
- Groupes :
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"?...
Édité par pepit Le 10/05/2020 à 01h06
Mageia7 x86-64 sur Xeon E5 1620v3 sur CM X99-UD4. 4x4go 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é
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
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
[ 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
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


Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
journal :
Une+erreur+de+ce+genre+a+déjà+été+rapportée,+sans+solution+mentionnée+: https://github.com/systemd/systemd/issues/8413
systemd-logind[1012]:+Watching+system+buttons+on+/dev/input/event31+(Microsoft+Natural®+Ergonomic+Keyboard+4000)
Yves
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie