Reprise du message précédent :
l'intérêt c'est que si le premier de la liste ne réponds pas, n'est pas/plus accessible, n'existe plus etc... cela va essayer le 2eme ainsi de suite.

l'inconvénient de mettre plusieurs miroirs c'est que tu ne sauras jamais si un miroir est défectueux (au cas où ça basculerait de manière silencieuse vers un autre miroir sans afficher de warnings dans la console ?),
j'ai toujours mis qu'un seul miroir, quand le miroir a un problème pacman affiche un message d'erreur, et dans ce cas j'utilise un autre miroir, en modifiant le fichier /etc/mirrorlist, un miroir qui ne répond pas c'est très rare chez moi, peut-être une fois tous les deux ans,

j'ai un core 2 quad Q9650 et je n'ai pas eu de problèmes après un redémarrage, le temps de démarrage m'a semblé normal, mais j'ai redémarré qu'une seule fois, j'ai un disque dur classique, pas de ssd,

dans dmesg j'ai aussi des random : xxxx :

ça semble être une fonction "générateur de nombres aléatoires" appelée par le noyau linux, cette fonction appelle une instruction "RDRAND" supportée matériellement par des CPU pas trop vieux type intel ivy bridge, si le CPU ne la supporte pas alors elle est sans doute exécutée de manière logicielle

https://en.wikipedia.org/wiki/RdRand

https://github.com/linuxkit/linuxkit/issues/3096

sur ce forum les liens habillés par des balises url ont l'inconvénient d'être peu visibles,  car l’œil humain n'est pas très bon pour distinguer le bleu foncé du noir sur des polices de caractères de petite taille derrière un fond blanc/gris, surtout si on est un peu loin de l'écran et que celui n'est pas très contrasté,

le mieux est donc de poster directement ton lien, sans t'embêter avec les balises url, il sera rendu automatiquement cliquable par le forum

J’ai pas de problèmes non plus avec le Core 2 Duo de mon portable, qui date pourtant de la même époque…
 

OK, mais donc ? Je fais quoi, concrètement ?

Ca me parait bien ce balancement moi.
Ca tente sur un miroir ca foire puis ca passe sur l'autre.
Je vois le soucis mais je ne m'en occupe jamais a dire vrai.

Quand un mirroir ne répond plus, pacman affiche un message (probablement le même que quand tu n'as pas plusieurs mirroirs) avant de tester le mirroir suivant.

 
Heu j'ai pas suivi, quel est le problème ? Perso mon clavier est bien en français sous Plasma Wayland...

Le problème, c’est qu’avec Wayland, la commande « setxkbmap » ne sert à rien. Et ils voudraient savoir comment on peut donc fixer la disposition de clavier depuis le Terminal avec un DE sous Wayland, sans passer par le module en GUI du DE (parce que tous n’en ont pas, ai-je cru comprendre ?).

 
Parce que les GUI ont des IHM toutes différents qui ne sont pas forcément stable avec le temps alors que la CLI l'est. De toute manière si le truc était bien packagé il y'aurait un synchro de clavier par défaut entre GDM, Wayland, et les consoles  (CTRL+AL FX) ce qui conviendrait à 99% des utilisateurs.
 
D'ailleurs si je reste avec Wayland va falloir que je fixe mon layout pour GDM.

en général une GUI n'est qu'un habillage, un intermédiaire entre l'utilisateur et une bibliothèque (ou l'utilitaire cli), pour lui éviter de taper une ligne de commande,
exemple : une GUI pour compresser en h264 des fichiers vidéos, il y aura une belle interface en Qt ou gtk et derrière quand l'utilisateur clique sur "valider" ça va appeler soit une bibliothèque, soit un utilitaire cli,

donc peut-être que pour la configuration clavier ça appelle au bout du compte la même bibliothèque en rapport avec xkb, quelque soit l'environnement de bureau, si ça ne marche pas ou mal alors il faut ouvrir un rapport de bug,

je précise que je n'utilise pas wayland, ni gnome

La solution est simple : utiliser le bureau Mate.
Pas encore de Wayland dispo comme ça c'est réglé  

bonne question

déjà voir si en downgradant le noyau à la version n-1 le problème disparaît, pour être certain que c'est bien le noyau, et pas un souci matériel qui se serait produit pile après le "pacman -Syu" (alim, disque dur, partition, barrettes ram, carte PCI qui a du mal à se réveiller à froid au boot)

une fois que tu es certain que c'est le noyau linux alors il y a plusieurs options :

1) sortir l'artillerie lourde en faisant un git-bisect pour trouver le commit qui a introduit le bug, et remonter l'info aux développeurs du paquet,
ça fait souvent peur quand on a jamais fait de git-bisect, mais une fois la technique bien en main ça facilite grandement les choses pour la résolution du bug,

avec le PKGBUILD du noyau et des options particulières passées à makepkg (pour permettre de créer un paquet avec des sources basées sur un répertoire physique, plutôt que de partir sur des sources en zip/tar.xz) tu peux te créer un paquet linux, l'installer, puis dire à git si le commit testé résout le bug ou pas, il te proposera ensuite une nouvelle révision à tester, au bout d'un moment tu finiras par tomber sur le commit qui a introduit le bug,
en utilisant ccache avec makepkg et un maximum de coeurs de ton CPU tu peux accélérer grandement la compilation,

2) trouver un moyen de contourner le bug, via une option à passer au noyau qui désactive la fonctionnalité qui te crée ce bug, ou  changer quelque chose dans la configuration matériel du PC (difficile si c'est un portable)

après la guerre des bureaux, la guerre des serveurs graphiques

 
 
A la base, c'est Anonymouse qui demandait comment configurer le clavier en Francais sous Wayland + Gnome mais je suis aussi preneur de la solution pour Wayland + KDE vue que j'ai jamais réussi à trouver non plus une commande, l'emplacement du fichier de conf ou le réglages via l'interface l'

Bon, donc en vous lisant j'ai voulu essayer wayland (avec plasma). Sur ma machine (desktop, carte graphique intel intégrée), j'ai plein de petits problèmes garphiques (fenêtres mal placées, morceau de la fenêtre qui disparaît...). En particulier, sous kmail, la zone où le message doit s'afficher reste noire (aucune idée pourquoi).
Bref, de mon côté, je vais attendre encore un peu

Le temps de boot avec Arch ça envoie quand même du pâté    
 
PC portable avec Intel Pentium P6200 @ 2.13GHz, disque dur en 5400 tr/min et 3 Go de ram :

 
PC fixe avec Intel Core i3-3225 @ 3.30GHz, disque dur en 7200tr/min et 4 Go de ram :

 
PC portable avec Intel Celeron N3350 @ 1.10GHz, SSD et 4 Go de ram :

 
Je vous laisse trouver le PC qui boote sous Arch  

Le problème c'est que souvent les éléments de lenteur critique dans la chaîne c'est ces putains de BIOS/EFI    
Ex: laptop de 2018 (I5/16Gb/SSD) : sur les 13,5secs le BIOS (cf: firmware) en à pris 10...
 

 
(bios à jour, finement configurer, aucuns périphériques externe branchés, boot en efistub, etc...)

Mon dernier chrono avec le Celeron est en Boot EFI, et j'ai même le secure Boot encore activé ( je ne sais pas si cela joue dans la lenteur ) Les 2 premiers ne sont pas en EFI.
 
Pour ceux qui n'avait pas trouvé, c'est celui du milieu qui est sous Arch, et les 2 autres au dessus et en dessous sous Ubuntu 18.10.
La différence dans le temps de démarrage du kernel est impressionnante ( même si l'Intel Core i3 doit aider je pense )

Hello les archers,
J'ai un soucis avec mon raid 5 (mdadm avec 4 disques de 750Go)
Ce week-end, mon raid ne démarre plus, je le démonte, je tente un resync.
Le resync est en cours à la vitesse extraordinaire de 120-170Ko/s

 
Si tout se passe bien, fin du resync dans 50 jours
 
J'ai vérifier les fichiers /proc/sys/dev/raid/speed_limit_max et speed_limit_min qui sont respectivement à 200Mo/s et 100Mo/s
 
Est-ce que quelqu'un aurait une idée pour optimiser le resync ?

Y a un fichier special qqpart caché dans /proc ou /sys pour lever la restriction de débit, je me souviens plus de son emplacement je te laisse faire la recherche

J'avais mis dans mon message que j'avais vérifier les 2 fichiers :
  - /proc/sys/dev/raid/speed_limit_max
  - /proc/sys/dev/raid/speed_limit_min
 
mais les valeurs dedans me semblent OK (100Mo/s et 200Mo/s)

Donc, j’ai installé le noyau LTS (ce que j’avais toujours pas fait sur cette machine), et en démarrant dessus ce matin, pour voir, j’ai bien retrouvé un temps de démarrage correct, avec seulement 5 secondes passées en kernel-space.
 

C’est donc bien un bug qui est apparu lors du passage en 5.0, mais qui n’affecte que le Core 2 Quad du PC (un desktop).
 
Au moins, je sais que ça vient pas du matériel (qui tient donc toujours la route, après 10 ans)…

Idem, sauf qu'en plus j'avais des soucis de sortie de veille et d'audio. Du coup je testerai de temps en temps le noyau normal (par exemple ce soir j'ai démarré sur le 5.0.2 fraichement installé mais le démarrage était toujours aussi lent -> retour au lts).

C'est pas une attitude très cool pour la communauté mais je n'ai ni le temps ni les compétences

 
pourquoi incriminer tout de suite le cpu core 2 quad ?
 
ça pourrait être un autre élément matériel du PC :
 
- carte réseau
- carte wifi
- carte son
- contrôleur disque
- chipset
 
en croisant ta configuration matérielle avec celle de nikro56 tu trouveras peut-être le vrai coupable

OK, c’est parti pour un coup de « inxi -F » (via SSH, c’est pour ça que les infos sur le mode vidéo seront bizarres)…
 

 
Et mon PC portable, qui ne souffre pas de ce problème, lui :
 

 
Donc a priori il faudrait chercher du côté processeur/carte graphique et carte son?
 
Edit: pas le chipset son visiblement

peut-être que la carte son, même si ce n'est pas exactement le même modèle (Intel 82801)

sinon comme indiqué il y a quelques pages :

- énorme ralentissement du système (manque de réactivité quand on bouge la souris, tape du texte) si on copie un fichier de 20 Go d'un disque dur interne à un autre,

les disques durs sont connectés en sata (un port sata de la carte mère, et un port sata d'un controleur sata pci-e)

Il a la même carte son sur portable donc je l'ai écartée...  
Par contre je crois me souvenir que Trit' avait eu le problème avec un noyau précédent mais moi je n'avais pas été touché de mémoire . Depuis j'ai juste ajouté un dongle wifi et peut-être réadopté le driver nvidia... je vais essayer sans ça pour voir  

Ah, les précédents déboires de noyau ? Rien à voir : c’était le noyau 4.18 qui, au début de sa carrière, faisait purement et simplement planter le démarrage sur les Core 2 Duo (donc, ça, c’était le portable qui était touché, pas le desktop). Un bug lié à un mauvais paramétrage par défaut du paramètre « clocksource » qu’il a carrément fallu faire remonter aux développeurs du noyau (donc Linus et compagnie), et qui n’a été corrigé qu’à la sortie du 4.18.9, environ un mois après (mais on pouvait déjà soit l’éviter en démarrant en mode fallback, ou en forçant le paramètre « hpet » pour la clocksource dans GRUB, ou en démarrant sur le noyau LTS qui était le 4.14, à l’époque ; c’était quand même plus simple à corriger !).

Suite à la dernière mise à jour de LibreOffice, je ne peux plus faire d'accents circonflexe dans Calc...   Ce genre de bugs complètement WTF qui te pourrissent la vie, encore en 2019 sous Linux c'est incroyable...

Aucun problème pour moi (fresh-fr). Tu utilises quelle version : fresh ou still ?

J'ai toujours connu des petits bugs sur LibreOffice, pas forcément méchants mais souvent un peu casse bonbon.
D'ailleurs j'ai fait une formation bureautique avec ce logiciel dans le cadre de mon compte individuel de formation, et la personne qui nous encadrait en parlait de temps en temps, de ces bugs... bref il n'est pas parfait c'est évident    
Mais il est libre et gratuit !  

j'utilise la version "still", dans le but de réduire le risque de bugs, je ne sais pas si c'est vraiment une bonne stratégie, car j'ai constaté parfois aussi des bugs assez visibles

Fresh.

Perso, jamais connu de bugs vraiment flagrants avec les versions Fresh (Évolution sur le site Web), à part le gestionnaire de thèmes qui buggue d’une version à l’autre (en 6.2.0, ça faisait crasher LibO ; en 6.2.1, il n’est juste plus fonctionnel).
 
En fait, la seule différence entre les deux est que la branche Still est simplement la branche Fresh, une fois remplacée par une nouvelle. Autant dire que ce sont des versions avec déjà un pied dans la tombe. Une 6.2.5 Still ne sera jamais qu’une 6.2.4 Fresh qui change de canal, car Fresh passe en 6.3.0. Je sais même pas si ça marche comme chez d’autres, où la version n – 1 ne reçoit plus que des correctifs de sécurité, quand la version n est la seule à avoir des corrections de bugs et de nouvelles fonctionnalités.

Y'en a qui utilisent mate ?
Chez moi ça marche plus: écran noir
Du coup je suis sur xfce4

Oui moi.
Tout va bien chez moi  
 

FF 66 ça envoie du pâté en vitesse de démarrage

Je me demande si y'a pas un soucis avec le support du 144Hz sous mate ?
Car c'est pile au moment ou ça passe à 144Hz que ça fait un écran noir...

Mon écran est uniquement en 60 hz donc je ne pourrais pas te répondre.