Reprise du message précédent :
Je vais re-verifier dans mon installation du coup... J'ai pourtant bien installé le paquet base (linux en fait partie)... et le système fonctionne !

Édit je l'ai bien maintenant .... Bizarre...

Hola,
 
J'ai relancé hier une machine que j'avais laissé trainer dans son coin pendant près de deux ans.  
Mise à jour faites, mais pas sans adaptations. Et j'étais pas sûr que ca redémarre    
 
Après redémarrage, un premier constat. Ca met plus de temps à arriver à l'ecran de login et aussi les icones sont remplacés par icônes fichier avec une croix rouge dedans. Après ouverture de la session, même problème pour les icones de la barre de lancement rapide et les icones du bureau sont pas la. Juste le texte en dessous.  
 
Quelqu'un aurait une piste pour régler ca ?  
 
Je suis sur LXDE.  
 
Gracias,
 
Edit: Après réinstall de gdk-pixbuf2 c'est déjà mieux pour l'histoire des icones.  
 
J'imagine qu'il y'a d'autres choses qui ont du cassé mais pour le moment rien de visible.

Pour le temps tu peux regarder avec:
 systemd-analyze blame
 
Pour les icones aucune idée mais il y a surement un log quelque part qui en parle.

Nouveau bug qui affecte les CPU double cœur de la génération Core 2 ! Ce matin, j’ai fait la MAJ de mkinitcpio sur les deux PC que j’ai sous Arch : un Core 2 Duo et un Core 2 Quad. Puis j’ai redémarré comme il se doit, cette MAJ ayant provoqué la reconfiguration du noyau 4.18.14 précédemment installé (et fonctionnel sur les deux machines !).
 
PAF ! Le Core 2 Quad a redémarré sans broncher. OK, très bien.
 
Sauf que le Core 2 Duo, mis à jour dans la foulée, ne l’a pas entendu de cette oreille et au redémarrage, blocage sur le chargement de l’initramfs en 4.18.14 (qui, je rappelle, était fonctionnel sur ce PC, puisque j’ai pu faire la mise à jour en ayant démarré dessus) ! C’est encore plus tôt que lors du précédent bug, puisqu’en août, le démarrage foirait au démarrage de systemd. Là, c’est carrément l’étape de l’initramfs qui échoue. J’avais pourtant pas eu de message d’erreur, c’est toujours le même noyau qui est employé, et ça démarre correctement sur le noyau LTS que j’ai conservé depuis l’autre fois.
 
Sauf que, cette fois, aucune remontée d’info sur le forum officiel, donc il semble que seul moi suis touché, cette fois…  
 
Je vais éventuellement tenter de démarrer avec l’initramfs fallback du 4.18.14, ou refaire un « mkinitcpio -p linux », des fois que ça le remette d’aplomb (rétrograder sur la précédente version du paquet en dernier lieu)…
 
EDIT : j’ai, à tout hasard, retenté de forcer le paramètre « clocksource=hpet » dans le fichier de configuration de GRUB, et ça fonctionne : je peux redémarrer normalement sous le noyau 4.18.14… Mais est-ce que c’est ça qui a résolu le problème, ou n’était-ce qu’un problème aléatoire qui ne se serait pas reproduit en me contentant de redémarrer l’ordi ? Je sais pas et comme c’est ma machine principale, je vais pas perdre mon temps à m’amuser à tester tous les cas de figure possibles.

 
J'ai trouvé pour les icones. Réinstall de paquet à faire. En l'occurencde gdk-pixbuf2.  
 
Merci pour le blame. Après comparaison , je comprends pas trop pourquoi ca prends plus temps, sachant que le backup d'avant la grosse mise à jour est sur du lvm et pas le courant.  
 
Ca donne ca :
 

 
Je m'étais pas trompé et j'ai pas du attendre bien longtemps    
Réinstall de pluma à faire parce qu'il ne se lancait pas.  
 
C'est quand même étrange qu'une simple réinstall suffise à régler les problèmes. Pourtant les scripts de post install ont bien du passer j'imagine lors de la mise à jour. Qu'est ce qui aurait plu clocher ?

J'attends avec impatience le 4.19

 
Il est dans testing, et chez moi ça boot.

Pour quelle fonctionnalité?

J'avais la même question

J'attends toujours qu'ils aient corrigé les bugs énormes qui ont flingué mes 2 PC.

Pour le support du nouvel agesa amd parceque j'ai un ancien bios avec un bug à cause de ça, je voudrai mettre le dernier.

Encore un bug assez étrange, et passablement ennuyeux…
 
Depuis hier, je constate des soucis fréquents de latence au chargement des pages Web dans le navigateur (en connexion Wi-Fi), suite à la MAJ des paquets que j’ai faite hier matin (comme je les fais tous les jours, ça ne concerne donc que les paquets mis à jour entre lundi matin et hier).
Symptômes : quand je clique sur un lien ou que j’ouvre une page dans un nouvel onglet, il peut s’écouler une bonne dizaine de secondes avant que la page ne charge, ce qui n’arrivait pas jusqu’à présent.
 
Mon pacman.log pour tout ce qui concerne les MAJ d’hier :
 

Je soupçonne une reconfiguration erronée de systemd, car dans dmesg, j’ai régulièrement des messages d’audit qui le concernent, et qui doivent être enregistrés lorsque ce phénomène se produit :
 

Une idée de ce qui se passe ? Et tant qu’à faire, pour corriger ce problème ? Parce que même après avoir redémarré ma box hier soir, et rallumé mon ordinateur ce matin, ça persiste. Et ça ne semble pas toucher les autres machines, qu’elles soient connectées en Ethernet via CPL ou en Wi-Fi (mais elles sont pas sous Arch). Pas un souci de résolveur DNS dans les choux, pour les mêmes raisons.
 
Ma configuration Network-Manager est correcte et mon /etc/resolv.conf est intact.

Je ne sais pas si ça va t'aider mais depuis quelques jours (voire semaines je ne sais plus   ) j'ai eu pas mal de mises à jour successives de NetworkManager.
Ce soir par exemple j'ai fait 1.14.4-1 -> 1.14.5dev+17+gba83251bb-1, donc peut-être que les mainteneurs découvrent des régressions au fil de l'eau    

Jamais eu de soucis liés à Network-Manager (à part une fois où j’avais fait l’andouille avec les permissions, ce qui m’avait valu une impossibilité de me connecter au redémarrage ; bêtise vite réparée quand je m’en suis rendu compte).
 
Après avoir lancé d’autres bouteilles à la mer, il semble que c’était surtout le résolveur DNS que j’utilisais (FDN) qui était pas au mieux de sa forme (pourtant, RAS sur tous mes appareils qui ne sont pas sous Arch ; donc j’ai quand même un doute ). On m’a conseillé de tester ceux de CloudFlare et là, aucun problème de « retard à l’allumage » à signaler. C’est bien et ça m’arrange, mais je ne peux prendre ça que comme un contournement… Surtout que, bon, CloudFlare, ils ont beau insister sur le fait qu’ils gardent pas les logs plus de 24h (va vérifier ça, tiens !) et qu’ils y conservent pas les IP (idem) parce que c’est pas sur ça qu’ils font leur blé, je reste assez circonspect sur la question, vis-à-vis d’eux.
Après, pour être honnête, c’est pas nécessairement plus vérifiable auprès de FDN (que j’ai choisi principalement car non menteur)…

Je ne sais pas si c'est directement lié à Networkmanager mais je me rappelle de 2 problèmes que j'ai vécus :
- l'applet de connexion qui affiche n'importe quoi -> style de l’Ethernet avec les 2 flèches alors que je suis en wifi
- l'impossibilité de taper le mot de passe de connexion wifi : visiblement un couillon avait implémenté un temps limité pour le faire ce qui faisait planter la tentative de connexion au réseau. Seul moyen de s'en sortir : rentrer le mot de passe via un copier/coller ( ou taper le mot de passe en mode supersonique    )
 
Heureusement aujourd'hui ces 2 bugs fâcheux ont disparu  

juillet...
Je suis vraiment une feignasse.

Le noyau 4.19 vient de débouler sur mon PC !
Tout va bien... le démarrage est même un poil plus rapide qu'avant  

Yep, ça semble être de la bonne ! J’étais un peu inquiet, surtout après le passage du 4.17.x au 4.18.x qui faisait planter mon portable au démarrage si je passais pas en mode fallback (avant de découvrir, en attendant une version corrigée du noyau qui n’est arrivée que pour la 4.18.8, qu’il suffisait de forcer un paramètre pour la clocksource), ou sur le noyau LTS (qui reste en 4.14 pour l’instant). Mais non : tout s’est bien passé !
 
Il a même corrigé un vieux « bug » sur le PC « familial » : au démarrage, celui-ci affichait des lignes d’erreur de systemd dès que celui-ci démarrait, et avant la vérification de la partition /, à propos de périphériques USB qu’il ne reconnaissait pas. Je pense que ça concernait le lecteur de cartes SD, CompactFlash et autres (je vois rien d’autre qui aurait pu être incriminé). Bref, rien de grave, surtout que les lecteurs en question étaient parfaitement fonctionnels, une fois la machine finie de démarrer.

Je vais pouvoir m'y remettre sauf que je n'ai plus la motivation.

 
Oui à ce propos, logiquement il va disparaitre le 4.14 non ?
Car ce noyau 4.19 est aussi un noyau LTS il me semble...

Justement, j’ai été étonné de voir que le 4.14.80 était proposé comme noyau LTS au lieu du 4.19.1 aussi. Sans doute que l’équipe d’Arch conserve le 4.14 par sécurité, le temps que le 4.20/5.0 arrive, si jamais certains ont des problèmes avec le 4.19 normal ? Jusqu’à l’été dernier et mes déboires avec le 4.18, j’avais que le noyau normal d’installé, donc je sais pas quelle est leur politique de versions entre LTS et normal.

Sur kernel.org le 4.19 n'est pas mentionné comme LTS je doute que ce soit le cas. Peut etre le 4.20/5.0

Oui en effet, pourtant des tas de sites et d'articles sur le net l'affirment pourtant. Bref c'est zarbi...

Voilà 4.19 installé j'ai pu upgrader mon bios et passer à l'agesa 1.0.0.4

J'ai juste un bug d'affichage un peu bizarre dans le coin supérieur droit de l'écran.... Je vais voir si ça disparaît tout seul au gré des majs.

J'ai trouvé j'ai le bug en 144hz et 120hz mais en 90hz et 60hz pas de bug.

hello,
 
J'utilise archlinux sur plusieurs machines déjà, en mono boot.
Là je voudrais faire un multiboot sur mon pc fixe en utilisant Refind, histoire de le thémer un peu et que ça soit joli
 
Ce PC a la config suivante :
- UEFI
- ssd 500 Go (sda) qui contient Windows, et la partition EFI (ESP)
- HDD 1To, data de Windows, sdb
- SSD mSata de 500 Go, sur lequel je veux installer Arch
 
Plusieurs questions :
1) Je créé les partoche comme d'hab : une /, une swap, une home et une boot ou je n'ai pas besoin de la boot (vu que la partition UEFI existe déjà)?
2) à l'issue de l'install initiale, quand on dois installer grub, je remplace par l'install de reFind et je lance refind-install en ayant monté l'ESP dans /boot ?
 
J'avoue que c'est nouveau refind pour moi

Bon, je suis un peu noob, mais je réponds quand même, un peu à côté de la question  
Je ne connais pas Refind, mais tu n'as pas besoin, mais c'est vrai que ça serait plus joli.
 
Comme tu as 2 disques c'est plus prudent de créer une nouvelle partition EFI sur le ssd mSATA lors de l'installation de Arch qui sera montée en /boot. Donc tu laisses la partition EFI sur l'autre disque qui pourra servir en cas de problème.
J'installerai Arch en débranchant le disque windows, ensuite, après avoir remis le disque, je modifierai grub pour avoir un démarrage sur la partition windows, il me semble qu'il y a une option dans grub pour trouver les autres systèmes.

est-ce que quelqu'un a déjà réussi à installer windows 10 dans virtualbox sous archlinux ?
j'ai tenté le coup hier avec l'image iso "windows 10 build 1809 french october update" disponible gratuitement sur le site de microsoft, et il y a 2 problèmes :
 
- des freezes aléatoires de la machine virtuelle durant l'installation
 
- parfois pas de freeze mais l'installation ne se termine jamais, l'étape de création de compte utilisateur se répète à l'infini (l'assistant qui reboucle avec les mêmes questions)
 
je précise que j'ai installé le paquet aur "Oracle VM VirtualBox Extension Pack",  
j'ai l'impression qu'il y a un bug dans la dernière version de virtualbox qui empêche l'installation de windows 10 sous un linux rolling release comme archlinux,
 
j'ai pas encore testé avec qemu

j'ai remarqué aussi des soucis de DNS avec ceux de google il y a quelques semaines, la solution que j'ai trouvé c'était de remettre les DNS de mon FAI,

pour ton autre bug lié aux CPU core 2 j'ai un core 2 quad (Q9650) et à priori pas de souci,
j'ai un autre CPU (pentium dual core E6800) de type core 2 mais il n'est pas installé sur ma carte mère, peut-être que lui aurait eu ce bug,

perso je conseille d'ajouter une ligne dans ton grub pour avoir un noyau linux de secours (une version plus ancienne du noyau qui n'a pas de bug), ce qui permettra de basculer sur ce noyau temporairement si le dernier possède un bug bloquant, il suffit de télécharger le PKGBUILD du noyau qui t'interesse en allant sur le git du paquet archlinux, puis tu modifies une ligne du PKGBUILD relatif au nom du paquet (pour avoir le suffixe "custom" dans le nom du noyau) et tu compiles avec l'outil makepkg, puis installation du noyau dans grub en lançant le script de mise à jour du menu grub

Virtualbox je ne sais pas mais Qemu oui.

Tu peux aussi installer sans débrancher le disque Windows, mais dans ce cas, attention à ne pas te tromper de disque (ne formate pas le mauvais /dev/sd× !) !!!
 
Pour Grub, il faut aussi installer le paquet os-prober pour qu’il détecte les autres OS présents.
 

Oui, car les Core 2 Quad ne sont pas touchés : seuls les Core 2 Duo le sont (et l’ont été).
 
Sinon, j’ai effectivement installé le noyau LTS en plus. Bon, le souci, c’est que c’est lui qui se lance par défaut : j’ai dû régler Grub pour qu’il me conserve la dernière option de démarrage choisie (du coup, je dois taper deux fois sur Entrée sur mon portable, au lieu d’une).

 
Merci à Berlo et Trit', mais je m'auto réponds avec la solution :
La partition EFI de Windows est utilisable sans problème.
Il faut juste la monter dans le dossier /boot/efi
Ensuite, j'ai installé refind-efi (à la place de grub et os-prober) et efibootmgr
Puis j'ai lancé refind-install.
Ça créé la conf de refind, en placant les fichiers nécessaire à refind dans /boot/efi/EFI/refind
Il a détecté tout seul mon Windows, et a créé un menu de boot avec les 2 OS (Arch et Win).
Seul problème :
Windows fonctionnait parfaitement, mais pas arch, je me suis retrouvé dans un shell de secours où quasi rien n'est faisable aisément.
La solution a été de reboot sur la clé d'install, de remonter les partitions comme lors de l'install initiale.
Puis de modifier le fichier refind-linux.conf situé dans /boot pour y ajouter en paramétres kernel : "root=UUID=<UUID de la partition root> rw add-efi-memmap"
 
Reste à mettre un thème au truc, je vais partir la-dessus je pense :
https://github.com/duneheishman/refind-dreary

j'ai joué avec ces trucs, et fini par utiliser systemd-boot.
C'est simple, ça se configure en 4 lignes intelligibles (8 si t'as un kernel FTS de secours) et ça fait le boulot
 
le bootscreen doit rester up moins de 3 secondes, j'ai pas vu l'intéret de me battre avec windows pour ça

 
tu as tout ce qu'il faut dans le wiki
https://wiki.archlinux.org/index.php/VirtualBox
Voilà normalement avec ça tu devrais y arriver.
Chez moi ça marche.

De rien, ta solution est chouette avec un beau menu, mais ça à l'air un peu galère quand même.
Perso j'ai un grub moche, mais que pendant 2 secondes, ça va

j'ai lu ce wiki, mais ça n'a rien changé,

tu as testé avec quelle build de windows 10 ?
celle d'avril dernier, celle d'octobre dernier ?
ce test a été effectué quand ? (vu la nature rolling release d'archlinux : ce qui a marché à une date X peut échouer une date plus tard si les versions de paquets ne sont plus les mêmes, apparition de bugs)

combien de mémoire tu as alloué à la machine virtuelle ?
il serait intéressant que tu refasses une installation pour voir si avec les paquets les plus à jour (noyau linux, virtualbox) le résultat change (échec de l'installation de windows 10 dans virtualbox),

comme CPU j'ai un intel quad core Q9650, peut-être que virtualbox utilise mal les extensions de mon CPU pour la virtualisation, alors qu'avec des CPU plus récents il n'y a pas de problème ?

je suis en train d'installer windows 10 sous qemu, pas de freeze mais ça reste bloqué à 2% pour la copie des fichiers :
 
https://reho.st/self/5e6f8d9e410a37 [...] fc5b98.png
 
noyau linux : 4.19.2-arch1-1-ARCH
 
peut-être un bug dans kvm ?

en utilisant le mode ide pour le controleur disque (au lieu de virtio) dans qemu ça va mieux, je dépasse les 2% pour la copie des fichiers, je croise les doigts pour que ça aille jusqu'au bout

installation de windows 10 (version d'octobre 2018) réussie sous qemu  
mais c'est lent et peu réactif par rapport à une machine virtuelle windows 7, quand je tape du texte il y a une certaine latence

et reste à comprendre pourquoi ça échoue avec la dernière version de virtualbox

Pourquoi utiliser VBox alors que Qemu existe?

 
 
Ce n'est pas si galère que ça quand on a compris comment marche réellement l'UEFI (qui n'a pas du tout le même fonctionnement que le BIOS) ...
Mais je vais refaire une install propre car j'ai mal lu la doc et le point de montage préconisé pour l'ESP (EFI System Partition) n'est plus /boot/efi mais directement /efi.
 
J'essaierai de faire des screen quand ça sera bien en place.