Reprise du message précédent :

Ça ressemblait à quoi, d’ailleurs, cette procédure ? Parce que j’ai pas connu cette époque (je n’ai découvert Arch qu’en 2014 ; avant, je la connaissais que de nom). C’était en 2012, c’est ça ?

https://www.archlinux.org/news/syst [...] allations/

Il y avait ces infos :
 
https://bbs.archlinux.org/viewtopic.php?id=147272
 
https://www.archlinux.org/news/fina [...] n-warning/
https://www.archlinux.org/news/syst [...] allations/
https://www.archlinux.org/news/inst [...] s-systemd/
https://www.archlinux.org/news/syst [...] aces-udev/
 

Puisque j'ai mon log (testing) :

 
Et encore si je me souviens bien c'était optionnel au début et il fallait ajouter init=/usr/bin/systemd ou un truc comme ça au boot du kernel pour l'utiliser.
Et c'est resté optionnel longtemps donc c'était pénible pour les packages, certains proposaient des scripts de lancement pour sysv mais pas systemd. La période de transition a servi à upgrader ces packages entre autres.
Ensuite il me semble que ça a été l'inverse, systemd par défaut mais encore possible d'utiliser sysv avec un init= au boot.
Puis c'est devenu le seul init supporté et les scripts bash à la sysv ont été supprimés des packages.
 
Le plus chiant ça a été de se défaire des habitudes du /etc/rc.conf de l'époque qui contenait plein de trucs dont les services activés et passer au management par systemd.
Le rc.conf c'était vu comme le gros attrait d'Arch donc ça râlait beaucoup que ce fichier soit enlevé pour passer aux fichiers "standards" systemd.
En vrai ce rc.conf c'était un gros fourre-tout qui centralisait tout, et fallait gérer les dépendances entre services à la main pour les lancer dans le bon ordre, c'était pas très élégant, même si on s'en sortait bien et c'était pratique.

(Les liens, ça me va aussi)
 
Merci bien, les gens !

rc.conf était fort pratique!

J'ai découvert, grâce à une vidéo de Linus tech Tip sur Linux, qu'il existait un programme qui permet d'utiliser le dongle officiel pour les manettes XBox One sans fil ; ça s'appelle Xow, c'est sur l'AUR et ça fonctionne parfaitement !

En effet, je l'utilise depuis 6 mois je pense. Il manque le support de l'audio, il y avait une branche pour mais le dev l'a viré et va le refaire je ne sais plus trop pourquoi.

Ça faisait longtemps que j’avais plus eu de gros problèmes avec Arch…
 
J’ai fait la mise à jour ce matin vers le noyau 5.7.3 (entre autres), avant d’éteindre parce que j’allais redémarrer sous Windows 10. Au moment de redémarrer Arch, devinez quoi ? Le système se lance avec une lenteur atroce !!! Je peux même pas me connecter avec LightDM : tout est grisé. Il a fallu que je redémarre depuis une console TTY (et là encore, ça a pris du temps).
 
J’ai vérifié : il n’y a aucune erreur dans le processus de démarrage. Systemd marque tout en « OK » bien vert. C’est juste que c’est lent.
Et évidemment, ce problème ne se produit pas en redémarrant sur le noyau LTS, mais ça veut dire que je dois très vite faire corriger ça, car le prochain LTS (le 5.9 ?) connaîtra le même problème si ce n’est pas corrigé dare-dare…
 
Notons enfin que, comme le problème de clocksource mal détectée en août 2018 pour les noyaux 4.18.x, je n’ai ce problème que sur mon Core 2 Duo (P7450), pas sur le Core 2 Quad.
 
Est-ce encore un bug venant du noyau lui-même ou un patch raté du côté d’Arch ? Je vais regarder leur forum, si d’autres ont constaté le même problème (c’était le cas la dernière fois, après tout).
 
EDIT : purée, je peux même pas m‘inscrire sur le forum d‘Arch, car il y a une question de validation à base de ligne de commande, et il accepte pas la réponse car « wrong » !
 
EDIT2 : ah, il se pourrait que le 5.7.4 corrige ce problème, d’après ce commit. J’espère. Vraiment !
 
EDIT3 : hmm, je dirais que ça sent bon, ça ! D’autres personnes ont aussi des problèmes avec ce 5.7.3, et même les devs sur la mailing-list de Kernel.org ont identifié le souci (incluant celui du ralentissement incroyable du système, allant jusqu’à être 21 fois (!) plus lent que la normale !) :
https://bugzilla.kernel.org/show_bug.cgi?id=208221
 
Je vois que le 5.7.4 (qui corrige tout ça) est enfin disponible dans Core : je vais voir si ça résout les soucis de mon PC (ce serait cool).
 
EDIT4 : noyau 5.7.4 dispo sur mon miroir vers 17h30, installé et redémarré dessus il y a une vingtaine de minutes → tout est OK ! Ça fait plaisir de voir que c’est réglé !

 
Merci pour ton retour qui explique une des raisons qui m'ont poussé à abandonner cette distrib. Ce genre d'erreur qui t'empêchent d'utiliser ton pc alors que tu en as besoin au quotidient. Problèmes que tu ne rencontres pas sur une debian par exemple où tout est testé en amont et rien n'est implémenté tant que ce n'est pas stable, ça ne veut pas dire qu'il n'y a pas de bug qu'on soit bien d'accord. J'ai mieux comprit pourquoi ce genre de distrib en rolling release était finalement si peu courante parmis le parc des utilisateurs Linux. On ne devrait pas être un expert en dépannage informatique ou un dev pour l'utiliser hors d'un cadre pro et encore je pense que c'est même pas efficace non plus dans ce cas car j'ai du mal à voir comment ça pourrait être exploité en production.
 
Ma conclusion est que c'est uniquement réservé à une niche d'utilisateur, aux bidouilleurs au fond de leur garage et à ceux qui ont le temps et la volonté de passer des heures à comprendre pourquoi ça bug. J'ai presque envie de dire que son intérêt est éducatif pour un niveau avancé dans un but de compréhension de linux.

 
Encore une fois ça varie en fonction des utilisateurs hein.
 
Je n'ai jamais eu ce genre de problème (sauf quand c'était de ma faute, mais je l'avais cherché), un petit coup de yay et mon OS se met à jour ainsi que tout ses packages.
Aucune volonté de retourner sur une debian-like pour ma part.

En meme temps si Arch avait plus d'utilisateurs de testing, core serait plus stable et on verrait moins souvent ce genre de soucis.
Aussi, si tous les utilisateurs de distributions types rolling release passaient sur des distributions stables, je ne suis pas convaincu que les utilisateurs actuels de ces distributions seraient si heureux.

J'utilise Arch depuis 2 ou 3 ans -> pas le moindre souci.
 
Sur un autre PC j'ai essayé à nouveau Manjaro ( donc du Arch en plus "user friendly" ) et la version Gnome Shell me fait une compilation de grand n'importe quoi depuis hier après midi.
Cette même Manjaro remplaçait Ubuntu Mate qui lui aussi déconnait plein tube sur ce même PC ( donc encore une distribution grand public )
 
Bref, je commence à me demander si Arch ne devient pas la distribution user friendly chez moi    
 
Ou alors ce sont les autres qui font de la merde ?  

Plus sérieusement je pense que c'est le matériel qui fait tout    
Si c'est mal supporté sous Linux cela ne pourra que partir en cacahuète  

C’est effectivement rageant, mais il y a quand même un avantage à ce qu’Arch soit la première à faire les frais de certaines MAJ foireuses : elles sont d’autant plus rapidement détectables et faciles à corriger, car il n’y aura pas à remonter très loin pour retrouver le commit fautif. Et comme ça aura été corrigé tout de suite (encore que le bug des 4.18 a mis près d’un mois à l’être…), le bug ne se propagera pas aux autres distributions, surtout les fixed qui tournent généralement aux noyaux LTS.
 

Non, mais Arch, c’est pas la distro de M. et Mme Toulemonde, on est d’accord. Au contraire, avec elle, tu es censé savoir à quoi t’attendre, notamment au fait qu’il pourra arriver que, de temps en temps (plus souvent si tu te mets en testing, mais là, tu es un bêta-testeur, pas un utilisateur classique), tu auras un petit grain de sable qui enrayera la mécanique.
 
Et encore, j’estime avoir eu de la chance, car j’avais le noyau LTS installé à côté et prêt à servir. Si jamais je l’avais pas eu (comme à l’époque du bug du 4.18), vu comment l’OS était purement inutilisable, tellement il était lent (d’autres avaient aussi rapporté un dysfonctionnement de wpa-supplicant, et je me connecte justement en Wi-Fi avec…), et que j’avais pas l’autre ordi qui n’a pas eu ce souci, j’aurais été mal, je te le dis. J’aurais pu m’en sortir avec un live et faire la MAJ en chroot, cela dit, mais voilà, quoi.
 

S’il n’y a plus que des utilisateurs de fixed, les éventuels bugs de ce type ne seraient détectés qu’au moment de la migration vers la version suivante de la distribution, laquelle installerait donc une version du noyau embarquant ce bug que personne n’aura eu l’occasion de détecter avant, et les conséquences auraient été autrement plus… conséquentes. Au moins, on a justement évité que les utilisateurs de Debian ne se retrouvent avec une brique inutilisable à la sortie de Bullseye, et qu’il faudrait alors remonter des mois, voire des années en arrière dans les commits pour retrouver celui qui cause ce genre de bug.
 
Je grossis un peu le trait (il y aurait sûrement des gens pour faire des tests, quand même), mais l’idée est là : ce serait beaucoup plus difficile de détecter et corriger rapidement ce type de bugs.
 
 
Ah, dans mon cas, c’est clairement le matos (en l’occurrence, le CPU). J’ai de la chance de ne pas être le seul à encore utiliser un double-cœur des années 2000…

Exactement!
 
Et bien entendu pareil pour les utilisateurs de core <-> ceux de testing pour Arch.

J'aime beaucoup Arch, et je l'utilise quotidiennement dans une VM sur le Windows du boulot depuis 5 ans (en cas de grosse mise à jour je fais un snapshot avant que je restore s'il y a un problème).

Maintenant j'hésite à changer mon laptop perso (un MacBook vieillissant) pour partir sur du full Linux et donc Arch, mais ça me fait toujours un poil peur ce genre de soucis.

Ah, de base, installer Linux sur un ordi qui n’a pas été spécifiquement conçu dans le but de le faire tourner, ce sera toujours risqué (comme le rappellait Timo, il y a 5 ans). Surtout sur des configurations hyper récentes, pour lesquelles le noyau ne dispose pas encore de pilotes (quoique l’inverse peut aussi être vrai : début 2018, les CPU Ryzen ne pouvaient tourner que sur un noyau 4.15 minimum ; exit donc Debian et autres Ubuntu sur ces configs, tant que celles-ci n’avaient pas un noyau ≥ 4.15).
Et forcément, sur une VM qui émule du matos plutôt générique, ça aura rarement tendance à être sujet à de tels aléas.
 
Après, faut aussi voir que ce genre de bug grave, ça n’arrive en moyenne qu’une fois par an, rarement plus. Et jusqu’ici, il y a toujours eu moyen de contourner (parfois en réinstallant la version antérieure d’un paquet et en bloquant ses mises à jour), le temps que le correctif arrive, ce qui ne prend généralement que quelques jours au pire. Windows 10 et ses mises à niveau semestrielles cause parfois plus de soucis et plus souvent ; et pourtant, on parle de machines conçues pour lui (même s’il faut se rappeler que ça n’affecte là aussi que peu de gens en réalité).
 
Donc, je peux juste te dire que tu peux toujours tenter le coup et voir si Arch tourne bien sur du vrai matos, sachant que je conseille quand même d’avoir un GPU AMD et, si jamais tu as une imprimante, celles de marque HP sont les plus faciles à faire fonctionner (même le scanner des multifonctions), car tout est inclus dans CUPS pour elles.

+ 1 pour les imprimantes HP
Mon Epson ne fonctionne pas sans ce paquet AUR par exemple.
 
https://aur.archlinux.org/packages/ [...] nter-escpr

 
C'est la merde de mon côté, plus de mise en veille depuis mon upgrade sur un 3700x... ça fonctionne encore sur Windows, donc à priori le matos ne serait pas en cause.
 
Quelqu'un a déjà eu un problème similaire sur du Ryzen ?
Les logs ne me disent rien, quand je mets en veille ça éteint l'écran, puis ça revient sur sddm en freeze total, obligé de redémarrer l'engin manuellement...
 

Perso je n'utilise jamais le mode de mise en veille, je préfère éteindre directement le PC, si tu as un SSD le démarrage est ultra-rapide, ce qui retire de l’intérêt au mode "mise en veille",

sur un vieux PC (carte mère gigabyte à socket 775, CPU intel core 2 quad) seul le mode de mise en veille classique (PC qui reste alimenté pour les barettes mémoires) fonctionne, l'autre mode de mise en veille (profond, qui enregistre un cliché de la mémoire sur un gros fichier sur le disque dur) n'a jamais marché sous linux avec ce PC (il redemarre de manière classique au lieu d'utiliser les infos du fichier),

si ça marche sous windows c'est peut-être parce que microsoft utilise un gros hack pour contourner les bugs liés au firmware, aux pilotes, aux standards mal respectés par les fabricants de périphériques (ACPI, UEFI etc...), et qu'ils coopérent avec les fabricants de matériel.

Le mieux c'est de ne pas utiliser les modes de mise en veille, c'est mieux d'éteindre (pour l'écologie, la facture d'énergie, l'autonomie de la batterie) directement le PC quand tu n'en a plus besoin, ou éventuellement d'éteindre que l'écran (une option pour que l'écran s'éteigne automatiquement après 10 minutes d'inactivité).

Certains n'éteignent jamais leur PC, ils laissent tourner 24h/24 (juste l'écran qui est éteint), le surcoût d'une dizaine d'euros sur la facture d'électricité leur étant supportable.

et l'intérêt d'un pc portable ? Eteindre le pc portable ou non c'est une excuse bidon ou ne pas avoir résussi à le configurer.  
Perso je mets en veille hybride qui se met automatiquement en hibernation donc, ça consomme 0 Watt : 0 Volt, 0 Ampère  surtout sur un pc portable récent qui consomme 2.8W en idle par rapport à une vieille tour donc l'écologie elle a bon dos. Et puis c'est quand même une fonctionnalité attendue par beaucoup ... Tu peux reouvrir mon espace de travail express.  
Ca reste ton point de vue il n'est pas tout partagé par tous !

Un pc portable avec un SSD qui démarre en moins de 10 secondes : normalement tu ne t'embêtes plus avec les histoires de mise en veille,

à moins de vouloir laisser des logiciels ouverts, jamais fermés, pour les retrouver dans le même état à chaque sortie de mise en veille, là ça peut se comprendre de vouloir continuer à mettre en veille.

Méfiance quand même : même si le mode de mise en veille fonctionne en apparence il se peut que les pilotes à la sortie de mise en veille fonctionnent dans un mode moins fiable, qu'il y ait des warnings, messages d'erreurs dans dmesg, je l'ai remarqué sur d'autres PC, des messages un peu anxiogènes dans dmesg, un pilote nvidia qui se met à déconner dans certains cas en mode multi-écran après la sortie de mise en veille, ou une longue session de plusieurs jours,

pour retrouver une stabilité de la session on est alors obligé de rebooter la machine (je le remarque sur ubuntu au boulot).

Dans dmesg est-ce que vous avez parfois ce message ? :

J'ai remarqué cette ligne depuis une récente mise à jour.

non, pas vu.

Ça parlait de rolling release, et bien ça fait depuis ~2012 que je suis sous Arch, ma première distrib GNU/Linux « à plein temps » et j'ai rarement eut des soucis ; pas plus que sous Windaube. Mais...  

Ça fait peut-être un mois que je n'avais pas branché un disque dur USB sur mon laptop et Gnome Files ne veut plus le monter. C'est une partition NTFS, et quand je

, j'ai :

Pourtant j'ai toujours ça dans /etc/fstab, pas touché :

Et la dernière mise à jour de ntfs-3g date de février, et ça fonctionnait après ça.
Les groups auxquels mon user appartient :

C'est uniquement avec du NTFS en direct, avec une clé USB en FAT32, ça fonctionne, et avec une partition NTFS dans un container Veracrypt aussi. Ça vient sûrement d'une mise à jour de quelque chose, car je n'ai pas touché à la config (sauf install de docker, mais je ne vois pas le rapport).
Il y a une mention dans le wiki : Allowing user to mount, mais je ne comprends pas trop le « Rebuild the package using ABS » surtout que c'est une solution discutée. Et le paquet AUR ntfs-3g-fuse, ne met pas en confiance : pas de mise à jour depuis 2017 et le maintainer a mis : « I will disown the packageI will disown the package ».

Il faudrait donner un peu plus de précisions, c'est pas clair,

ton disque dur il est dans un boitier externe USB, et tu le connectes en USB à ton PC portable ?
ou c'est un disque dur interne SATA au format 2.5 pouces que tu as installé dans ton portable ?

si c'est un disque dur dans un boitier USB alors tu n'as rien à faire de particulier, le disque doit être monté automatiquement si tu as installé les paquets officiels (surtout pas de paquets AUR) qui montent automatiquement les périphériques amovibles tels que les disques dur USB, les clés USB, le type de partition sera automatiquement détecté, du 100% plug and play si ton système est bien configuré (mais je n'utilise pas gnome, mais kde/plasma).

J'ai des partitions NTFS dans les quelques disques dur internes montés dans mon PC, ça marche toujours, pas de problèmes particulier, c'est Ok aussi avec un disque USB contenant une partition NTFS.

La commande mount utilisée depuis une console doit se faire soit avec le compte root, soit avec un utilisateur à qui on a donné des droits pour le faire, normalement dans l'utilisation quotidienne d'un PC on ne doit pas avoir besoin de taper la commande mount, c'est le système qui doit monter automatiquement les partitions (au boot du PC si c'est un disque dur interne via /etc/fstab ou systemd, ou automatiquement si c'est une clé USB, un périphérique amovible),

dans mon fichier /etc/fstab c'est configuré de cette manière pour les partitions NTFS un truc plus simple que ton exemple :

important : le "UUID" doit correspondre à l'UUID de la partition NTFS présente sur le disque dur, il y a des utilitaires pour le connaitre, ou utiliser le programme gparted-live cd pour avoir des infos sur la partition.

C'est un disque connecté en USB, et ça fonctionnait très bien, automatiquement, sans recours à la commande mount jusqu'à hier.

Le souci vient peut-être de la fonctionnalité automount de gnome, de son navigateur de fichiers, si tu ne vois pas de petite fenêtre automatique indiquant "périphérique amovible détectée, voulez-vous monter la partition ?"  quand tu insères une clé USB, un disque dur USB.
Normalement ça doit être automatique (comme sous windows et MacOS), tu branches un truc et hop le système configure le montage du disque, de la clé USB à ta place, avec une icône "périphérique amovible" qui apparait parfois à coté de l'horloge.

Teste aussi ce disque dur USB sur un autre système d'exploitation, au cas où c'est en fait le boitier USB  du disque qui commence à merder (problème d'alimentation, connecteur USB usé, d'où la non-détection).

Regarde enfin dans les fichiers log (dmesg, journalctl), pour voir s'il y a des messages d'erreurs, de diagnostic.

Avais-tu installé gvfs, qui est justement un utilitaire s’occupant de monter automatiquement les volumes amovibles ?
 
De mon côté, sous XFCE, aucun problème pour monter mes disques externes USB (formatés en NTFS et en GPT, tant qu’à faire) ou autres cartes SD et clefs USB. Faut dire que, vu que j’en branche tous les jours, je me serais vite rendu compte s’il y avait eu un dysfonctionnement (comme tout à l’heure, en redémarrant Arch après la MAJ hebdo de Windows 10 : Wi-Fi non fonctionnel ; heureusement, un redémarrage a suffi pour tout rétablir, mais j’ai eu peur, vu qu’il y avait eu une MAJ de dhcpd ce matin… Faut arrêter de me faire des frayeurs comme ça ! ).

Pas d'erreurs avec `dmesg`. Avec `journalctl` :

Sauf que avec un autre disque formaté en NTFS, mais dans un autre boitier USB et sans ligne dans le fstab, pas d'erreur :

J'ai donc switcher le boitier, mais toujours pareil sans les erreurs SMART :

  Je vais commenter mon fstab pour voir (mais obligé de redémarrer pour que ce soit pris en compte ?)

gvfs n'est pas installé, mais tout fonctionnait sans soucis jusqu'à maintenant, et c'est vraiment qu'avec ce disque que ça ne fonctionne pas visiblement.

Le point de montage "/media/musique" possède quels droits utilisateurs ?
Tu as accès à ce dossier ?

Est-ce que la partition NTFS a des erreurs ?
Peut-être que dans le passé tu avais débranché le disque dur USB alors qu'il y avait encore une opération d'écriture, ce qui aurait corrompu la partition ?

Les erreurs ne viennent pas par magie, il y a peut-être eu un truc anormal qui s'est passé récemment, une manipulation inhabituelle, un incident (coupure de courant) qui a peut-être endommagé la partition ntfs.
Le disque dur NTFS provient d'une installation windows ? (ancien disque système windows retiré d'un PC, puis mis dans un boitier USB)
Ou bien ce n'est qu'une partition de données NTFS sans fichiers windows dedans ?

Essaie cette solution :
https://wiki.archlinux.org/index.ph [...] ilesystems

Teste aussi le disque dur USB sous windows, pour voir si le problème se reproduit.

Autre solution : récupérer les données utiles via un linux live-cd ou un windows qui n'aurait pas de souci à monter ton disque dur, puis formater le disque vers le système de fichiers ext4.

Cette ligne est bizarre :

tu étais en train de taper la commande "mount" en étant non root ?
La commande mount s'utilise avec "sudo" ou sous le compte root.

Vérifie bien que ton fichier /etc/fstab est correct, et que tu as bien suivi le wiki ntfs d'archlinux, ainsi que la fiche liée à gnome (s'il manque un paquet).

775

Oui, je suis le propriétaire, et il est sur mon groupe utilisateur

Bonne question

Maintenant que tu le dis, il me semble que l'autre jour, le disque était branché, mon laptop s'est mis en veille, et j'ai tout débranché pour déplacer le laptop.

C'est un disque acheté vierge, formaté en NTFS avec gparted, pas de fichiers Win là-dedans
 

Je vais aller faire ça.
 

Je ne me souviens plus si c'est en essayant de le monter sans sudo ou via Gnome Files.

Un coup de

a fait le job. Merci pour l'aide  
 
edit : du coup, le soucis n'était pas Archlinux mais l'utilisateur ; donc je maintiens que Archlinux c'est fiable/stable  

Pareil quand il m’arrive qu’un disque USB se démonte tout seul (ça m’arrivait avec un câble visiblement défectueux) et que dmesg râlait à chaque fois que je le rebranchais. Il fallait que je passe un « chkdsk /f » dessus depuis un Windows pour que tout aille mieux (surtout qu’il me disait qu’aucune erreur n’avait été trouvée, alors même qu’il m’avait balancé une notification « ce lecteur rencontre des problèmes, blablabla » après l’avoir branché…). Ensuite, plus personne ne râlait : ni Windows, ni dmesg !
 
Depuis, je veille bien à ne jamais débrancher un disque ou une clef comme un sauvage, même si c’est censé être OK depuis longtemps sous Windows car ce dernier a désactivé par défaut le cache en écriture depuis au moins Vista, voire XP.

Je déconnecte proprement 99% du temps, mais là j'ai dû zapper. Je le saurai à l'avenir.

Bon… On est d’accord qu’il faut y aller à coup de « sudo pacman -Syu --overwrite /usr/share/fonts/misc/fonts.alias » ? Parce que le site officiel ne dit rien, mais comme c’est la méthode habituellement préconisée dans ce genre de cas…

Je n'ai pas eu besoin de faire cela perso.

En général je préconise un Qo avant histoire de ne pas faire sauter quelque chose.

Non, mais vous allez rire : le bug était connu, il a même été corrigé il y a plusieurs heures, mais cette correction ne s’était pas encore propagée au miroir que j’utilise lorsque j’ai fait mon « time yay » quotidien (pourtant, celui-ci commence bien par faire une resynchro des dépôts avant de donner la liste des paquets à mettre à jour)…

Là, j’en ai refait un, et j’ai bien eu le message me disant que les paquets étaient en conflit et il m’a proposé de remplacer l’ancien par le nouveau. Tout s’est passé sans encombres.

La méthode la plus propre :

- regarder à quel paquet appartient ce fichier, via la commande :

- une fois connu le nom du paquet :
essayer de le désinstaller, surtout si c'est un paquet orphelin, dont on se sert jamais, un paquet venant du dépôt AUR

- refaire ensuite la mise à jour (pacman -Syu)