Reprise du message précédent :
J’ai l’impression qu’il n’y a plus que moi, ici… Il est parti, Elbarto ?
 
Bon, c’est pour dire que la dernière MAJ de mkinicpio apporte quelques changements à l’usage : de nouveaux hooks lors de la génération des initramfs (au moins [kms] et [consolefont], et des nouveaux aussi dans la liste des potentiellement manquants pour les fallbacks) ; de plus, le pilote vidéo semble désormais chargé juste après systemd, avant le résultat de l’analyse fsck de la partition racine, et non plus à mi-parcours du processus de démarrage des services. Ça se voit surtout si on en est resté au HDD et ça surprend, au début.

o/
j'ai vu aussi cette MAJ et ces nouveaux hooks, pour l'instant je ne l'ai pas encore appliquée, le fichier mkinitcpio.conf.pacnew est toujours en attente
j'avais deja appliqué consolefonts avant, bien mieux visuellement. rajouté lvm2 et déplacé keyboard et keymap avant block et encrypt pour taper mon pass LUKS en azerty.
la nouvelle liste des hooks est aussi écrite différemment
avant: HOOKS="hook1 hook2 hookn"
maintenant: HOOKS=(hook1 hook2 hookn)
j'espere que ca ne casse pas tout et que les 2 sont supportés (faut que je teste dans une vm pour voir..)

bon, testé à l'instant, remplacé l'ancien mkinitcpi.conf par le nouveau
un coup de mkinitcpio -p linux
reboot
et.... planté \o/
ca m'affiche juste "udev 251" blablalba... pis plus rien. normalement ca me demande le pass LUKS à ce moment.
suis bon pour reboot sur une clé usb, mount, chroot, et refaire
 
edit: ouf ! j'ai remis mes hooks comme avant, un coup de mkinitcpio -p linux, reboot, et ca remarche \o/
la seule diff était finalement l'ajout de kms. ptêt l'ordre qui n'allait pas..
ma nouvelle ligne de hooks qui plante mon boot est la suivante:
HOOKS=(base udev autodetect keyboard keymap modconf block encrypt kms consolefont lvm2 resume filesystems fsck)
et maintenant: celle qui marche:
HOOKS=(base udev autodetect keyboard keymap modconf block encrypt consolefont lvm2 resume filesystems fsck)
 
dans le nouveau mkinitcpio.conf.pacnew, kms était juste après modconf, avant keyboard, keymap consolefont et block

Ah, si tu avais modifié mkinitcpio.conf…

Ça passe pour moi avec
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck encrypt)
Je suis chiffré aussi.

bien obligé pour supporter le luks et lvm

ok merci. l'ordre a l'air légèrement différent.. je vais faire quelques essais

edit: quelques essais apres, l'ordre n'importe presque pas, ca boot tant que je ne mets pas kms dans la liste des hooks
dès que j'y mets kms, qu'importe l'ordre, ca affiche juste "udev 251..." puis plus rien.
ptet car j'utilise le paquet nvidia-dkms plutot que nvidia ? ou ptet qu'il faut rajouter nvidia dans MODULES=() ?
bref. tant pis, ca marche bien sans le module nvidia se charge peu apres, et j'ai un desktop qui fonctionne bien.

Ah j'ai pas de nvidia par contre.
Tu as vu ça : https://wiki.archlinux.org/title/Ke [...] mkinitcpio ?

oui j'ai pas mal lu le wiki arch à ce sujet  
pas sur de la différence entre "in-tree modules" et "out-of-tree modules"..
pour essayer, au lieu de mettre kms dans les hooks, j'ai mis les modules nvidia dans MODULES=(), refais l'init ,reboot et ça passe.
Maintenant, je ne vois pas forcément l’intérêt de charger les pilotes graphiques plus tot. ni même de pousser tout le monde à kms dans l'init, vu la reaction ici
De plus l'init me fait habituellement 20M, et la avec les drivers nvidia, 105M  

Pas sûr non plus qu'avoir kms dans l'init soit super utile.
Mais bon, j'essaie de m'écarter aussi peu que possible de la config par défaut en général.
Donc là avec juste encrypt rajouté à la fin de HOOKS ça passe alors je laisse comme ça (je me sers pas non plus de consolefont en fait).

ha, merci, tu me rassures
et oui consolefont n'est en fait utile que si on a besoin de /etc/vconsole.conf, dans lequel j'ai indiqué le keymap à fr (sans quoi à priori, taper le mot de passe LUKS se fait en qwerty)

consolefont est pas nécessaire pour que /etc/vconsole.conf soit pris en compte je pense, car je l'avais pas avant cette màj et j'avais bien le clavier en azerty pour LUKS.
J'avais juste ça /etc/vconsole.conf (que j'ai toujours) :

Ou alors j'ai un autre truc de configuré quelque part qui fait que c'est pris en compte sans consolefont, c'est possible (c'est le genre de trucs qu'on touche pas tous les jours   )

hahaha tu m'as mis le doute..    
D'apres https://wiki.archlinux.org/title/Mkinitcpio (vers le milieu, y'a un tableau avec ce que fait chaque hook), c'est "keymap" qui le permet. alors que consolefont sert plutot à charger des polices spécifiques.

 
in-tree c'est les modules directement fournis par le noyau  
out-of-tree, c'est les modules non-fournis par le noyau (hors de l'arbre des sources) ; souvent des pilotes propriétaires (nvidia notamment) ou pas encore intégrés.

, c'est +/- ce qu'il me semblait.
(d'ou le danger de mettre kms dans les hooks pour tout le monde )

Ça semble raisonnable

Si ca intéresse quelqu'un, il y a un repos avec les paquets compilés en x86-64-v3 -O3 et LTO: https://git.harting.dev/ALHP/ALHP.GO
 
Je n'ai pas (encore) testé. Du meme genre il y a la distrib CachyOS basée sur Arch.

Hello,
 
J'ai installé un PC et pour test j'ai mis Deepin en DE.
J'ai juste un petit pb étrange dont je ne sais pas comment le diag  
Quand le PC démarre, j'arrive à la page de login, logique ... et si je saisis le mdp, il afficher brievement les lignes de boot derrière puis revient sur la page de login où si je resaisis le mdp, là il me logge.
Si je ferme et rouvre la session, ça marche du premier coup.
Il n'y a qu'au boot où je suis obligé de saisir 2 fois le mdp pour que ça me logge.
Une idée ?

Deepin ce n'est pas du Arch, pas vraiment le meilleur topic pour ta question je pense.

Il y a la distribution Deepin (basée sur Ubuntu, je crois), et il y a l’environnement de bureau Deepin. Attention à ne pas confondre.
 
Là, il doit avoir installé le DE Deepin sur une Arch, mais c’est vrai que ce n’est pas forcément un problème propre ni lié à Arch (au sens où ça pourrait sûrement aussi se produire sur une autre distro où Deepin DE est installé). S’il y a un TU Deepin (aussi bien OS que DE), ce serait davantage là que sa demande aurait sa place.

Oooooops, merci de la correction.

J'ai effectivement simplement installé le de deepin sur une arch fresh...

Je vais continuer à chercher pas bloquant non plus juste un peu chiant

Pas d'idée mais il faut que tu regardes les logs.
Commence par les logs de ton DM
Si tu vois rien cherche les logs X (Xorg.0.log) et dans .xsession-errors.
dmesg eventuellement si c'est un crash ça peut te le montrer.
Je donne pas de chemins parce que ça dépend de pleins de choses, cherche où ils sont chez toi.

J' a remarquer qu'il m'est impossible de passer en mode veille a cause de ma logitech pro superlight des qu'il passe en mode veille ausitot le pc redemarre comme si j'avais bouger la souris.  
Au début je pensait a mon adaptateur bluetooth, mais ce n'est pas lui... Quand je débranche le dongle logitech et que je passe en mode veille, le pc reste bien en veille et je reactive le pc avec le clavier, car meme si je rebranche le dongle ca ne fonctionne pas.
 
J'ai aussi un autre soucis et je sais pas si c'est lié a KDE/Wayland avant j'etais sous Gnome. quand le pc sort de veille, il ne redemarre pas correctement le sddm se "fige" je ne peu que bouger la souris
 
une idée ?

test

Dans la série « Ça marchait trop bien, et si on cassait un truc ? » : la dernière MAJ de libmodplug qui empêche la version GTK2 de Double Commander de se lancer !
 

J’ai évidemment créé un rapport de bug, et vu que revenir à la version précédente de libmodplug permettait à nouveau de lancer DC.
 
Un paquet auquel il faut bloquer les MAJ jusqu’à nouvel ordre dans pacman.conf, ça faisait longtemps (et ça me manquait pas !)…
 
EDIT : ah, d’accord, mon signalement a été fermé comme ça, et en plus, par un type plutôt mal luné (« j’ai pas pu reproduire, et vu que ça semble donc venir de ton côté et que t’as pas mis le bon degré de sévérité, je ferme. Va poster sur le forum¹ si tu as toujours un souci »)…
 
¹ Forum où, je le rappelle, j’ai jamais pu m’inscrire à cause de la dernière question du formulaire qui refuse la réponse que je lui donne (et qui est pourtant le résultat de la commande donnée en consigne !).
 
Pfffff…

J'ai installé doublecommander avant MAJ et il se lançait bien, et après mise a jour il se lance toujours bien.

Aussi la différence entre 0.8.9.0-4 et 0.8.9.0-3 ne devrait rien changer. Après va savoir la différence sur la machine qui a compilé le paquet... Ca pourrait jouer en effet.

Pour voir de quoi parlait le mainteneur j'ai aussi essayé en virant libmodplug et doublecommander se lance tout aussi bien, après c'est peut-être optionnel et non pas inutilisé comme il le dit.

Le paquet doublecmd-gtk2, pas doublecmd-qt ?
Tu es sous X ? Sous Wayland ? Je suis sous X.
Pilote vidéo ? J’utilise xf86-video-ati sur les deux PC (parce que les deux sont touchés).
 

Juste un changement d’algo de chiffrement pour l’empaquetage. Donc oui, ça devrait pas avoir d’effet sur autre chose que la conception du paquet, et en tout cas pas le contenu des fichiers inclus dedans, qui ne devraient pas avoir changé, eux.
 

C’est ça, le plus fou : a priori, DC n’a même pas besoin de libmodplug (il est requis par FFMpeg et les codecs Gstreamer, donc je peux pas le virer). Mais DC a une fonction de prévisualisation des fichiers (touche F3, comme dans les autres gestionnaires de fichiers * Commander). C’est peut-être là que ça joue ? Pourtant, le message montre que c’est au moment de générer l’affichage à l’écran du splash screen que ça foire. Ce serait donc lié à X ?
 
Et on est au moins deux à avoir le problème (l’autre serait un Britannique qui utilise FluxBox) :
https://bbs.archlinux.org/viewtopic.php?id=282377 (Oui, j’ai enfin pu créer un compte sur le forum, trop bien !). Mais il dit pas quelle est sa configuration (GPU ? Serveur d’affichage ? Pilote vidéo ?).

gtk2, sous X mais avec amdgpu.

 
Ca a ete compile surement avec d'autres trucs de mis a jour entre temps, donc j'imagine que c'est possible que les fichiers inclus aient changé.
 

Aucune idée la, désolé...

A priori, les GPU de mes ordis sont trop vieux pour accepter amdgpu (Radeon Mobility HD 4530 pour le portable, R7 240 pour le fixe).

qu'est ce que xhost ? (j'ai cherché mais je n'ai pas bien compris )
J'ai taper par hasard, suite a une erreur et j'ai eu la réponse suivante :

Les 2 derniers semble être des serveurs Google, je me demande bien pourquoi ils sont dans cette liste de client autorisés pour je ne sais quoi !?

https://wiki.archlinux.org/title/Xhost

Arch

Fedora

J'ai été curieux, j'ai ça chez moi...  
Logiciel de bureau à distance installé? A tout hasard.

Bug réouvert !
 
Et donc, d’après ce message sur le forum, ce serait en fait ffmpegthumbnailer le vrai coupable.
 
Bon, on avance !

j'avais lu ça, mais j'ai du mal à saisir de quoi il en retourne

J'ai KRDC depuis longtemps et j'ai installé VNCviewer (Real VNC) récemment car KRDC n'est pas génial et fonctionne pas avec un Raspberry Pi.
 

Ta question a éveillé ma curiosité, et une recherche m'a amené là aussi et j'ai eu du mal a saisir aussi.

De ce que j'ai compris, xhost gère et limite les accès au serveur X. D’où ma question sur les bureaux à distance, puisque tu as des ip dans le retour de la commande.
"Le programme xhost est utilisé pour ajouter et supprimer des noms d'hôtes ou des noms d'utilisateurs à la liste autorisée à se connecter au serveur X." Voir ici https://www.commandlinux.com/man-page/man1/xhost.1.html en anglais, c'est ce que j'ai trouvé de plus précis.
Un exemple: https://www.thegeekstuff.com/2010/0 [...] n-display/

OK, c’est bon : libmodplug a été patché !

Non, non, rassurez-vous : cette fois-ci, il n’y a pas (eu) de problème.
 
Mais quand même, faudra me dire pourquoi la mise à jour du paquet btrfs-progs (dont je n’ai absolument aucune utilité, les seuls FS que j’utilise étant soit des ext, soit NTFS, soit FAT32) tient tant que ça à régénérer systématiquement les initramfs, sachant que c’est le seul paquet lié à un FS qui fait ça ! Ça oblige à redémarrer après, c’est d’un péniiible…
 
Le pire, c’est quand ça enchaîne sur une « série de la mort » : btrfs-progs, le(s) noyau(x), device-mapper et systemd, pas forcément dans cet ordre, mais à raison d’un seul par jour → QUATRE jours à la suite où il faut redémarrer après. Quand on est comme moi et qu’on les fait à l’allumage des ordis le matin, ça gonfle vite !

c'est vrai que si tu n'utilise pas btrfs, c'est pas génial..  
c'est pour ça que je fais mes mises à jours juste avant l'extinction de ma machine, et après le boot

 
si tu n'utilises pas btrfs, tu n'installes pas le paquet