Reprise du message précédent :
Sauf que c’est Logitech qui leur fait leurs claviers.

Possible, mais, j'ai un modèle de 2001 là.

Un peu comme moi, le truc est totalement increvable.

Le clavier du MB marche plus depuis qu'y a eu de la bière dessus  

Ah, toi aussi  
Sinon, Arch Linux tourne bien dessus ? Aucun problème hardware ?

Pour l'instant c'est pas génial: j'arrive pas à activer soit DHCPD soit NetworkManager.. si je le fais ça freeze au boot.

Le réseau fonctionnait lors de l'install ?
Si oui, essaie avec netctl, c'est ce qui y est utilisé

J'ai le même problème avec netct
J'ai configuré un simple profil ethernet ip statique et ça fonctionne j'ai internet. Sauf que quand je l'active et que je reboot j'obtiens des messages du genre
"watchdog BUG soft lockup - CPU stuck"
"task jbd2/sda2-8:200 blocked for more than 120 seconds".

On dirait que dès que j'active une connection au réseau / à internet, je ne parviens plus à booter.

Edit: après pas mal de recherche ce thread correspond exactement à mon problème:
https://bbs.archlinux.org/viewtopic.php?id=233962

Noyau 4.20 qui déboule    
 
Archlinux ne plantera pas en 2018 chez moi  

Yep ! Installé ce matin sur mes deux machines sous Arch : RAS, ça tourne bien, pas de souci au redémarrage.

Trit' :

sur ton PC à base de CPU core 2 as-tu un message d'erreur au boot de ce type ? :

ça arrive de façon aléatoire au boot, malgré le message d'erreur le démarrage va jusqu'au bout, j'ai pas encore testé le nouveau noyau 4.20,

j'ai ouvert un rapport de bug sur le site du noyau linux, ça semble avoir un rapport avec "loadkeys" et peut-être à cause de ce patch d’août dernier :
https://bugzilla.kernel.org/show_bug.cgi?id=202111
https://lkml.org/lkml/2018/8/22/584

Non, aucun problème de ce type. Mais je vérifierai plus tard : là, l’ordi est éteint et débranché pour la nuit, donc j’ai même pas accès au journal de dmesg (et rien de tel sur le Core 2 Quad).

ça apparait de manière très discrète, sans conséquence sur le boot,
et si tu as configuré grub pour un "silent boot" alors tu ne verras pas le message,
 
à noter que sur archlinux il y avait déjà ce bug en 2017 :
https://bugs.archlinux.org/task/54311

J’ai rien configuré : GRUB se paramètre comme ça par défaut à l’installation. Et je m’amuse pas à trafiquer le fichier grub.cfg, juste pour avoir la plâtrée de lignes « OK » de systemd au démarrage et à l’arrêt. Mais ça devrait quand même apparaître dans le log de dmesg, non ?

(Il a juste fallu que je reforce l’usage de la clocksource hpet sur le C2Duo, sur une maj 4.19.x, il y a peut-être un mois et demi, parce que ça se rebloquait, cette fois après la ligne « Chargement de Linux linux »…)

Noyau 4.20.0 pour la nouvelle année !

Il fait quoi celui ci? Efface le disque dur, plante irrémédiablement l'OS ou flingue la MBR?
Hisvin, 2 PC perdu, 4 mois sans Linux parce que, du jour au lendemain, Arch n'a plus voulu s'installer sur des M2.  
Vive Windows qui efface avec style /mesdocuments.
Bon, dès que je rentre, je retentes si j'ai la motivation.

Pour l’avoir installé hier matin : rien de tout ça.
 
↓
 

J’aurais même un bug sur le PC de mon père qui serait corrigé avec ce noyau : avec le 4.19, étrangement, il refusait de s’allumer tant qu’on n’avait pas débranché le câble Ethernet (ça fait toujours bizarre de voir la machine faire de l’auto-allumage dès qu’on enlève le câble RJ-45…). Faut dire que la machine était reliée à la box via CPL, et j’avais noté que les LED du boîtier ne s’éteignaient plus à l’arrêt de l’ordi. Là, une fois le 4.20.0 installé, la LED du CPL s’éteint bien, et le PC s’allume sans problème. Apparemment, le processus d’extinction du noyau 4.19.x avait un problème (pas de souci pour redémarrer, cela dit), parce que je crois pas à un souci matériel qui se résoudrait du jour au lendemain, juste après une MAJ, sachant qu’une fois allumée, la machine fonctionne parfaitement.

en fait il ne faut pas toucher au fichier grub.cfg, mais modifier le fichier /etc/default/grub, tu recherches cette ligne :

pour la remplacer par ça :

tu peux aussi mettre pour cette ligne des options pour le noyau au lieu d'une chaine vide, l'idée c'est de supprimer l'option "quiet",
puis tu lances la commande pour que le fichier grub.cfg soit mis à jour :

ça permet d'avoir un démarrage et un arrêt de type "verbose", où rien n'est caché à l'utilisateur, contrairement aux systèmes windows qui se contentent d'afficher un gif animé de type sablier au démarrage et à l'arrêt (spéciale dédicace à windows 10, je l'ai virtualisé avec qemu et j'ai presque le temps de faire un café vu le temps qu'il met à démarrer et à s'arrêter )

 
Vu que c'est impossible de booter en activant l'ethernet j'ai désactivé tous les services réseau et j'ai paramétré lightdm pour faire un netctl start au démarrage

si vous utilisez plasma/kde et l'éditeur kate/kwrite pouvez-vous me dire si vous avez le même problème quand vous essayez d'imprimer avec kate/kwrite ?  
 
https://forum.hardware.fr/hfr/OSAlt [...] m#t1428037

 
Hello,
Ca faisait un bail que je n'étais plus venu sur le forum ...
Bref, j'utilise arch avec la même version de kate que toi et je viens d'imprimer un doc sans soucis
 
Mon imprimante est une HP Deskjet F4100

J'ai toujours pas résolu ce problème d'impression, qui ne se produit qu'avec kate et kwrite,

j'ai tenté en me connectant à plasma avec un nouvel utilisateur, pour repartir avec une configuration vierge pour kde et kate, mais ça ne résout pas le problème,
peut-être qu'il y a une histoire de cache pour cups dans /var/cache et que cups tente de réutiliser un cache corrompu quand il veut imprimer quelque chose issue du logiciel kate ?

J'ai enfin installé en guise de test une vieille version de kate (version 16.12) : le bug est toujours présent,

okular (lecteur pdf par défaut de kde) n'a pas ce souci d'impression, et pourtant il utilise la même boite de dialogue d'impression issue de kde, donc le mystère reste total.

un forumeur anglais m'a mis sur une bonne piste, celle de des paramètres régionaux, notamment la variable d'environnement LC_NUMERIC,

chez moi c'est réglé sur "fr_FR.UTF-8" :

or avec les applications Qt5 cela génère un mauvais fichier postscript/pdf quand on veut imprimer, la virgule est utilisée à la place du point dans le balisage PDF ce qui entraine une erreur avec cups (d'où l'absence d'impression, uniquement avec les applications Qt5) ,

le mauvais pdf (la virgule est utilisée pour les nombres au lieu du point) :

le bon pdf, généré par les applications gtk :

un forumeur anglais m'a donné un moyen de contournement :

et là je peux enfin imprimer avec les applications Qt5

Tiens, en voyant les locales, j'aurais une question ;
 
J'avais entrepris lors de ma dernière install de tuner mon pacman.conf de manière à n'installer que les locales FR et et EN lors de l'installation des packages.
Cela ce fait "à priori" en rajoutant ces lignes de code :
 

(c'est directement tiré du wiki : https://wiki.archlinux.fr/pacman#Em [...] e_locales)
 
 
Le problème c'est qu'avec ces lignes au fil du temps et des mises à jours mon Arch devient totalement anglophone...    
Par déduction je doit bien faire une erreur quelque part au niveau de la syntaxe qui fait que les locales FR ne sont pas installées j'imagine mais je ne trouve pas l'erreur...
 
une idée ?  
 
(on est d'accord que c'est quelque chose qui est loin d'être indispensable mais plutôt que virer bêtement ces modifs j'aurais aimer comprendre et fixer l'erreur maintenant que j'ai mis les mains dedans   )

on dirait que la première ligne interdit d'extraire toutes les locales

ça semble entrer en contradiction avec le reste des règles, peut-être qu'il faut supprimer cette première ligne,

sinon les développeurs de Qt5 ont répondu à mon rapport de bug et ont crée un patch qui devrait résoudre le problème :

https://codereview.qt-project.org/#/c/249357/

https://codereview.qt-project.org/# [...] g/qpdf.cpp

Sortie de systemd 240 en version stable.
 
Sans être mauvaise langue, je ne pensais pas que ça arriverait un jour : on est que les versions 239.x depuis si longtemps (juin, d’après les archives des paquets, soit plus de 6 mois), même si on a eu des versions intermédiaires entretemps… Première fois, depuis août 2014 où j’ai découvert Arch, que je vois une telle stagnation dans les mises à jour de systemd ! Remarquez, pour moi, tant que ça marche, je souhaite pas plus !

Justement, c'est lui le responsable de cette attente de 2 minutes à l'extinction ?
 

 
Désolé pour la qualité de la photo    
 
C'est la première fois que je vois une telle attente avec Archlinux ( alors que sur Ubuntu Mate c'est assez courant comme souci, mais avec une attente de 1m30 )

J'ai ce truc une fois par mois depuis plusieurs mois.

C'est très aléatoire.

Ok merci    
Moi c'est la première fois.
C'est un PC de bureau donc ce n'est pas gênant de toute façon  

idem pour moi, (moins souvent)

Le réglage par défaut est de 90 secondes (1 mn 30). Mais j’ai changé system.conf pour qu’il force l’arrêt après 20 secondes (comme sous Windows). Ça l’empêche effectivement pas de traîner plus que ça, parfois. C’est heureusement très rare, mais je vois pas pourquoi, une fois sur plein, il se met à traîner des pieds pour arrêter les services et éteindre la machine.
 
Donc, oui : ça me l’a fait sur mes deux PC ce matin, quand j’ai fait les MAJ, mais j’ai pas eu l’occasion de voir si ça allait être systématique ou si c’était juste un effet de bord d’avoir mis systemd à jour entre le démarrage et l’arrêt (je préférerais cette dernière option…). Si jamais ça devait être systématique, je pense que ça ne devrait pas tarder à être corrigé, vu qu’il aura immanquablement été signalé.

Super, mon archlinux ne boot plus  

Pour être précis : mon système est chiffré via un LVM sur LUKS, et lors du boot il me demande mon mot de passe pour déchiffrer les partitions.
Depuis ce matin, je ne peux plus taper le mot de passe. Lors du prompt, on dirait que mon clavier n'est plus reconnu, il ne se passe absolument rien quand je tape, pas même un « mot de passe erronné » après avoir appuyé sur entrée.

Intuitivement je me suis dit que ça venait de l'initcpio (j'ai eu une MàJ hier), avec le hook "keyboard" non lancé avant le hook "encryption", mais j'ai exactement le même problème avec l'initframfs de fallback & l'initframfs LTS…

Vous auriez des pistes ? Je désespère un peu pour être honnête
(Et en plus je suis coincé jusqu'à midi sans accès à un autre ordi pour créer une clé USB bootable, la seule chose à laquelle j'ai accès c'est la ligne de commande grub)

Bon, j'ai lancé mon Linux en skippant l'étape de déchiffrement. J'ai accès à un « emergency shell » vu que je n'ai pas de filesystem, et je confirme, les entrées clavier ne sont pas reconnues  

Peut-être un mod grub qui n'est pas lancé ?

il faut prévoir un mode de secours pour parer à cette éventualité du "pacman -Syu" qui crée des bugs et qui empêche le système de démarrer (paquets bogués, les utilisateurs testing qui n'ont pas remonté le bug),

perso je conseille trois filets de sécurité :

- ajouter une ligne "mode recovery" dans ton grub,
ça permet de démarrer en mode minimal avec un linux de base, en ligne de commande, sans la tonne de services et pas de GUI, dans la plupart des cas ça donne la possibilité de downgrader le paquet responsable du bug

- créer une clé USB de boot contenant l'installateur archlinux, non pas pour réinstaller archlinux, mais pour pouvoir démarrer en ligne de commande sur un linux de base, et ainsi faire un chroot sur ton installation actuelle, pour downgrader le paquet responsable du bug
https://wiki.archlinux.fr/chroot

- ajouter dans grub un noyau "linux-custom" issu d'une version précédente, afin de démarrer dessus si on pense que les soucis viennent du noyau linux récent, en complément on peut aussi ajouter le noyau linux-lts
 
voir aussi cette faq sur les problèmes lvm :
https://wiki.archlinux.org/index.ph [...] leshooting

le wiki sur dm-crypt :
https://wiki.archlinux.org/index.ph [...] ire_system

si tu as un autre clavier (port PS/2 plutôt que USB) : essaie de le brancher pour voir si ça permet de contourner le problème de non reconnaissance du clavier

Justement, j'ai un 2e noyeau pour parer à ça (le LTS) mais le problème est là quand même avec

J'ai une clé d'install mais elle est chez moi, donc elle ne m'aide pas pour l'instant

Par contre, clairement ajouter un Linux minimal est une bonne idée à laquelle je n'avais pas pensé.
Je verrai une fois que ce sera résolu à créer une partition non-chiffrée contenant ce Linux minimal

Dans tous les cas, je vais refaire une clé live-system cet après-midi pour corriger ça.

Et en tout cas, j'ai testé avec un clavier externe mais c'est pareil que le clavier interne : fonctionne dans le grub, mais pas après
(Clavier USB, j'ai pas de PS/2, c'est un laptop)

reste la possibilité de se connecter à ton portable en ssh depuis un autre PC, si le service y est installé et configuré, ça pourrait contourner le problème du clavier
 

prudence en tout cas avec systemd 240, beaucoup de bugs de boot impossible et de clavier non reconnu :
 
https://bugs.archlinux.org/task/613 [...] &sort=desc
https://bugs.archlinux.org/task/613 [...] &sort=desc
https://bugs.archlinux.org/task/61324
https://bbs.archlinux.org/viewtopic.php?id=243297
https://forums.gentoo.org/viewtopic [...] art-0.html
 
et d'autres bugs :
https://bugs.archlinux.org/task/613 [...] &sort=desc
https://bugs.archlinux.org/task/613 [...] &sort=desc
https://bugs.archlinux.org/task/613 [...] &sort=desc
 
 
le plus simple serait de rester à la version 239 pour systemd en attendant la correction de ces bugs, en ajoutant un "--ignore systemd --ignore libsystemd --ignore lib32-systemd --ignore systemd-sysvcompat" après le "pacman -Syu"

J'ai piqué le PC d'un collègue pour me faire une clé de boot, j'arrive à me reconnecter sur la machine  

Maintenant plus qu'à trouver d'où viens le problème…
J'ai vérifié les hooks dans mkinitcpio.conf, j'ai bien "keyboard" avant "encrypt" donc ça devrais être bon, par contre lors de la MàJ d'hier (merci les logs pacman), "keyboard" était build après "encrypt". Peut-être une piste là  

Visiblement j'avais 2 fois le hook "keyboard" dans mkinitcpio.conf (bizarre)
J'ai suivi le manuel et j'ai fini par déplacer "keyboard" avant "autodetect", et les claviers externes sont détectés et peuvent être utilisés pour mettre le mot de passe LUKS  

Par contre, le clavier interne est toujours non utilisable en early userspace, c'est probable que ça vienne de systemd 240, je vais creuser tes liens elbarto

EDIT: visiblement ça serait lié à udev 240, les symptômes sont strictement les mêmes que sur le premier lien : https://bugs.archlinux.org/task/613 [...] &sort=desc (le hardware doit être quasiment identique aussi, vu que mon laptop est un dell precision, assez proche du dell XPS de l'auteur du lien)

Pour arrêter de spammer : C'était bien dû à systemd-240. J'ai downgradé en 239 et le clavier interne fonctionne de nouveau.
 
Je peux arrêter de spammer le topic maintenant

Merci pour ta remonté, je ne sais pas si je m'en serais sorti