Reprise du message précédent :
Boum, je sors le PC de veille (chose que je fais rarerement, je préfère éteindre)
 
Et je vois que le bluetooth est fonctionnel
 

 
Si quelqu'un a une explication?

T'as Windows en dual-boot, spa possib' ?!

Du tout, installation toute fraiche, et ici j'ai booté ce matin le PC et ça fonctionne au poil, rien à comprendre

ha ca y est, après 3 versions et 3 mois de retard, php 8.4.3 est enfin disponible !!
 

• Version 8.4.3 - 16 Jan 2025
• Version 8.4.2 - 19 Dec 2024
• Version 8.4.1 - 21 Nov 2024

et la version qu'on aurait du avoir en attendant alors qu'on était resté bloqués en 8.3.15 depuis le 19/12/24 :
 

• Version 8.3.16 - 16 Jan 2025
• Version 8.3.15 - 19 Dec 2024

 
Les puces bluetooth semble être un point noir pour le noyau linux, les résultats dépendent du modèle de puce bluetooth utilisée, parfois il peut y avoir des bugs, des régressions selon la version du noyau linux, essaie de tester avec le noyau LTS pour voir s'il y a une différence,
https://wiki.archlinux.org/title/Bluetooth
 
Tester certaines options du fichier de configuration du service bluetooth, notamment les options d'économie d'énergie, ça joue peut-être sur la stabilité avec certaines puces :
/etc/bluetooth/main.conf
 
la commande lspci permettrait de connaitre le type de puce bluetooth utilisée, il existe des puces qui font à la fois office de contrôleur wifi et de contrôleur bluetooth,
une mise à jour du bios peut aussi aider,
 
les spécifications de ton PC portable :
https://psref.lenovo.com/syspool/Sy [...] D_Spec.pdf
 
 

 
Un test utile : démarrer la session avec un compte utilisateur de test, le home sera alors différent, avec une config par défaut, au cas où le problème viendrait d'un fichier de configuration présent dans le home de ton compte utilisateur actuel,
 
de mon coté j'avais testé une clé USB bluetooth générique, et pour la faire fonctionner il fallait respecter ces étapes :
 

 
Pas vraiment d'explications mais sur mon pc (à base d'Intel AX201) ça m'arrive que le BT soit en mort cérébral aléatoirement (généralement après un reboot) et un  

 
fixe généralement le problème. Quand j'avais cherché sur internet c'était un peu monnaie courante visiblement.
 
 

Merci pour vos réponse je vais regarder ça dès que possible    
 
Ici il fonctionne mais je compte réinstaller rapidement car c’était une installation de test je n’ai pas chiffré le SSD

Salut,
Pour ceux qui n'aurait pas modifié leur /etc/pacman.conf lors du passage à Git, il est impératif de le faire avant le 01/03.
https://archlinux.org/news/cleaning [...] ositories/

En gros, si on n’avait pas remplacé le pacman.conf (si jamais celui-ci avait été modifié, par exemple pour rajouter des dépôts tiers, activer les Multilib ou passer en Testing), on se retrouvait avec un dépôt « Community » vide qui ne s’actualisait plus ?
 
Je me rappelle avoir remplacé le mien par celui apporté par la MAJ de Pacman à cette époque, certainement le jour même. Ce qui fait que pour moi, c’est bon : j’ai que « Core » et « Extra » d’activés (et « Multilib » sur le portable).
 
Si je comprends bien l’actu, il y aura désormais une erreur pour ceux qui ne l’avaient pas fait, vu que les dépôts obsolètes seront bientôt supprimés ? Je croyais que c’était déjà le cas, mais ça dit qu’ils avaient juste été vidés et conservés en l’état.

Salut,
C'est ça, de mon coté je les avais juste commentés (#). J'ai posté rapidement avant de partir au boulot,  sans détailler ni traduire.
Je me suis abonné à la mailling list, j'ai donc l'info directement sur ma boite mail. C'est pratique, il n'y a pas besoin de compte, juste fournir une adresse. Environ 8 mails par ans.
https://lists.archlinux.org/mailman [...] linux.org/

@Elbarto et @Sudo: Re-bonjour, merci pour les pistes    
 
Comme j'ai trois portable identiques, j'ai gardé le premier pour faire des tests, et j'en ai installé un second bien proprement avec le chiffrement du SSD et des mots de passe plus fort, comme c'est celui là qui sera en vadrouille avec moi, l'autre reste au taf pour tests    
 
ET cette nouvelle install a fait les même grimaces: le Bluetooth a été direct après l'install en ayant installé Bluez et exécuté systemctl start bluetooth.
 
Je redémarré, refait la commande, ensuite un systemctl enable bluetooth, et rien.
 
Plus tard après avoir éteins le portable je le rallume, lance enable et start et boum depuis lors ça fonctionne sans soucis.
 
Bluetooth intégré à la carte Wi-Fi Intel Wi-Fi 6 AX200
 
C'est étrange, mais ici ça fonctionne sans chipotage à chaque allumage donc cool.
 
Pour info, j'ai commencé Arch il me semble en octobre 2023, et il est sur une SurfaceGo depuis plus d'un an, et il a été sur mon PC de jeu pendant 8 mois. J'ai capitulé à cause des manette Xbox Séries en 2,4ghz avec le stick officiel Microsoft qui était instable et que mon fils voulait Fortnite    
 
Mais ici avoir récupéré des "vieux" PC portable 14 pouces je vais pouvoir m'en servir ne plus de la SurfaceGo qui est quand même un peu limitée, mais bien moins que sous Windows 10    
 
J'avais déjà une fois parlé de détailler mon usage et ma manière d'installer et configurer Arch, ça tente que je poste une fois que j'aurais peaufiné le pavé?

Oui targan ça m'intéresse, c'est toujours utile de confronter les expériences.
Généralement c'est des tutos de spécialistes et tout semble facile, mais dans la vrai vie, pour un débutant, ça ne l'ai pas forcément.

On pourra comparer, je viens de changer de PC et je suis parti sur une installation complètement neuve.
Moi c'est sur un Dell précision 3541, avec une carte graphique NVIDIA en plus qui complique les choses. J'ai fait au plus simple avec archinstall, puis utilisation du script architect derrière, ça installe tout ce qu'il faut (AUR, pilotes, softs). Ça fonctionne bien et c'est rapide. Mais sous wayland je ne suis pas sûr que tout soit bien fonctionnel encore. Par exemple faut pas essayer de customiser sddm sinon ça redémarre sur une fenêtre noire avec juste le curseur de souris.

D'ailleurs architect c'est pour les gamers à la base, il y a des questions pour l'installation de manettes, as-tu essayé ?

Un petit pense-bête pour l'installation de mon imprimante/scanner en wifi (brother mfc9340cdw), j'ai eu un peu de mal à retrouver pour le scanner
 
Pour l'impression, il faut Cups et mettre les pilotes trouvables sur AUR ("brother-mfc-9340cdw" LPR and CUPS driver for the Brother MFC-9340CDW)
 
Pour le scanner, installer les pilotes venant de AUR aussi ("brscan4" SANE drivers from Brother for compatible models) et aussi l'utilitaire ("brscan-skey" Brother scan-key-tool). Et ça fonctione avec SANE, puis les applications Skanlite et Skanpage sous KDE Plasma.
 
Il faut être vigilant à l'installation de brscan, car à la fin il y a un message indiquant qu'il faut saisir la commande suivante en root : brsaneconfig4 -a name="Brother" model="YOURMODELHERE" ip=YOUR.SCANNER.IP.HERE"
 
Sinon, ça ne va pas trop mal sur mon nouveau Dell Precision 3541, à part la carte graphique en plus qui est capricieuse en sortie de veille, il y a notamment "nvidia-smi" qui se met à bugger et faire chauffer le pc, il chauffe bien plus que le modèle d'avant celui-là d'ailleurs.
 
 

Attention il y a un problème avec la dernière version du paquet grub, j'ai fait la mise à jour, puis j'ai réinstallé grub : mon PC ne démarre plus,
 
il plante sur le message :
error : symbol "grub_is_cli_need_auth" not found,
 
et je tombe alors sur la console grub rescue,  
 
mon installation de grub est sur un bios standard, non UEFI.

C'est bon j'ai pu me dépanner,  
 
en démarrant sur une clé USB contenant une image ISO d'arch linux, afin de démarrer en mode console et de réinstaller grub,
 
le problème venait du fait que mon script automatique de mise à jour de grub (un hook pacman) était bogué, il installait grub sur la mauvaise partition.
 

Si t’as des scripts custom, aussi…
 
Juste : pour la prochaine fois, au lieu de simplement dire « la dernière version de ××× », merci d’indiquer le numéro de version. Parce que je sais que j’ai installé une MAJ de Grub récemment (et pas eu de problème au démarrage suivant). Mais y en a-t-il eu une autre depuis… ? Faudrait aller voir sur le site d’Arch pour voir ; alors qu’avec le numéro, un simple coup d’œil rapide dans « pacman.log » permet de voir si c’est bien cette version qu’on a installée en dernier ou pas.

C'est la version 2:2.12.r226.g56ccc5ed-1 de grub.

J'ai créé un hook "grub.hook" pour appliquer le conseil ci-dessus, qui indique de réinstaller grub et de régénérer la config à chaque mise à jour de grub.

Mais le souci c'est que mon script visait la mauvaise partition, ce qui faisait que grub n'était jamais réinstallé sur la partition système, à la longue ça finit par créer ce problème que j'ai eu ce dimanche, à savoir que mon vieux grub situé dans le MBR ne retrouve plus une fonction qui semble avoir disparu dans la version récente des fichiers systèmes de grub.

Mon script qui réinstalle grub et qui regénère la configuration de grub :

où il faut remplacer le X par la bonne lettre, moi j'avais mis la mauvaise.

Donc, c’est bien la dernière en date.
 

Ce conseil ne vaut que pour les installations UEFI, non ? Et seulement pour la révision qui obligeait ces installations à réinstaller complètement Grub (et plus après, parce que s’il faut refaire ça à chaque MAJ… OK, il y a ce hook, mais ça resterait relou/20 !) Parce que moi, j’ai jamais fait ça sur mes ordis (installations MBR aussi) et ils s’en portent pas plus mal.

Moi non plus   pour les mises à jour kernel
 
Avant d’être avec Arch je suis resté longtemps avec Fedora. Fedora conserve 3 kernels par défaut. A chaque mise à jour de kernel, à la fin de la mise à jour système, une mise à jour du Grub installé était faite automatiquement (grub-mkconfig -o /boot/grub/grub.cfg). Il fallait bien que Grub sache quel était le kernel le plus récent  au boot. Ainsi que  lors d'une mise à jour de Grud lui même. C'était géré par DNF, le gestionnaire de paquet.  
 
C'est une question intéressante que je vais prendre le temps de creuser, car je sais pas comment c'est géré précisément sous Arch par pacman. (et les hooks finaux?)
 
Dans le cas de la dernière mise à jour, j'ai vu passé la mise en garde demandant de passer un "Grub update" , et avec l'idée de pas cherché les ennuis, je l'ai fait. J'ai un lanceur tout prêt    pour mon multiboot.

Arch ne fait pas ça, car ils ne conservent que la dernière version installée du noyau (qui remplace donc la précédente). Le seul moyen de garder une version précédente est donc d’installer le noyau LTS en plus (mais Grub étant configuré pour démarrer par défaut sur la branche la plus récemment installée, il faut modifier le fichier « /etc/defaults/grub » et passer un coup de « grub-mkconfig … » pour le forcer à présélectionner le dernier choix effectué au démarrage).
 

C’est bien de le garder près (donc pas loin) de toi, mais encore faut-il qui soit prêt à servir (donc en état de le faire)…

Je me doutais de ça.
Dans le cas d'une mise à jour de Grub lui-même, il existe un hook lancé par Pacman dans /usr/share/libalpm/hooks/  (grub-initrd-generation-fix). Le message d'avertissement devait être lié au paquet, et être informatif dans le cas d'une mise à jour normalement effectuée.
Le hook en question chez moi:

  J'essaye pourtant de me surveiller.

Voici le hook pacman que j'ai créé, il permet de réinstaller grub et de régénérer la configuration grub à chaque fois que le paquet grub est mis à jour :

Il est à mettre dans /usr/share/libalpm/hooks/, sous le nom de grub.hook

puis créer un script dans /usr/share/libalpm/scripts/, sous le nom de reinstall-grub, ici un exemple pour le cas d'un PC avec bios non UEFI, voir le wiki arch linux pour la méthode pour bios UEFI et partition GPT :

Remplacez /dev/sdX par le chemin de la partition où est installé grub (par exemple /dev/sda), si vous ne connaissez pas le chemin alors tapez la commande "lsblk",
vous aurez une sortie de ce type, repérez la partition où se trouve "/" ou "/boot", ici chez moi grub est installé sur /dev/sdc :

si vous avez un SSD NVMe alors le chemin sera de type /dev/nvme0n1.

Il est important de mettre le bon chemin sinon grub ne sera pas installé au bon endroit.

Puis faire un "chmod +x" sur ce script pour qu'il soit exécutable.
Toutes ces opérations (excepté la commande lsblk) sont à faire avec "sudo" ou le compte root.

Si vous avez le moindre doute alors ne faites rien, pour ne pas casser grub.
On peut s’entraîner sur une machine virtuelle pour tester sans risques.

L'image ISO d'arch linux semble avoir grossi en un an, elle passe de 800 Mo à 1.2 Go :

Current Release: 2025.03.01
Included Kernel: 6.13.5
ISO Size: 1.2 GB

Bonsoir Elbarto,
Je vais suivre ton exemple. Je suis en train de m'apercevoir que rien n'était fait lors d'une mise à jour de Grub pour le réinstaller en mbr. Je passais seulement à l'occasion un « grub-mkconfig … » pour mon multiboot. Ce sera plus propre.
 

Avez-vous remarqué des bizarreries avec la dernière version de GIMP, basée sur GTK3 ?

Chez moi je remarque 2 choses :

- au lancement de GIMP le splashscreen n'est jamais centré sur l'écran, il est parfois en haut à gauche, en haut à droite sur le coin

- à la fermeture de GIMP : si une image était ouverte et non sauvegardée alors on a une fenêtre demandant si on veut sauvegarder l'image avant de fermer GIMP, cette fenêtre est bizarre en terme de design, les boutons d'action sont sous forme d'onglets, et lorsqu'on clique sur un des boutons alors il y a une latence perceptible, GIMP met beaucoup de temps à se fermer quand on clique sur le bouton qui sert à ignorer les changements, sur la version précédente (basée sur GTK2) la fermeture était beaucoup plus rapide, quasi-instantanée

j'utilise Plasma avec Wayland (et le thème Oxygen), c'est peut-être lié à une mauvaise intégration des applications GTK3 avec Qt6.

XFCE sous X.org, ici, donc GTK.

Jamais vu ici, mais déjà vu dans les vidéos de présentation des bêtas par Adrien D (Linuxtricks), qui est sur Fedora GNOME sur Wayland. Ça doit donc être lié à ce dernier, ça.

Pas de problèmes ici (XFCE, thème Adwaita dark parce que captures prises à 23h30, et thème de GIMP système) :

Chez moi c'est le thème "default", avec le color scheme "light color", ça donne ceci pour la boite de dialogue de sauvegarde :
 

Probable que Plasma suive les règles de Gnome, qui place aussi ces boutons en haut avec son mode CSD activé.

En tout cas, sur XFCE, je l’ai désactivé ; et on dirait que c’est bien de ça qu’il s’agit, puisqu’en testant après l’avoir activé, ça me fait pareil :

Pour retrouver une disposition plus classique, il te faut donc trouver le réglage qui active les décorations côté client sur Plasma (si ça existe) et les désactiver.

Pour économiser de la batterie, je suis passé de powertop à tlp sur mon Dell Precision 3541, ça m'a l'air moins bien, il y a peut-être des optimisations à faire coté processeur ou avec les cartes graphiques (i7-9850H, Intel UHD630 + NVIDIA Quadro P620 )
), il y en a qui maitrise ?

Je reposte le message que j'avais mis dans le topic Firefox, j'aimerai savoir si vous avez le même bug avec le paquet Firefox de Arch Linux :

C'est un bug qui apparaît une fois sur 3 lorsqu'on a ouvert beaucoup d'onglets (supérieur à 20 onglets).

Pour ceux qui ont 32 Go de mémoire et qui ont un Ryzen :
 
- est-il normal que la commande "free -mh" ne trouve que 30 Go de mémoire ?
 
J'ai un Ryzen 9 7900, chipset B650, j'utilise une carte graphique dédiée, le bios affiche bien 32 Go (2 barrettes de 16 Go).

Ta CG, elle aurait pas 2 Gio de VRAM, par hasard ?
 
Parce que de ce que je sais : RAM adressable = RAM totale – RAM CG.

Ma carte vidéo a 8 Go de mémoire vidéo (une radeon RX7600).
 
La carte mère est une Gigabyte B650 Aorus Elite AX V2.
 

J'ai 16 Go (i3 et rx570)  :

AMHA, ça vient de la différence entre Go (en base 10) et Gio (en base 2), 32 000 000 fait 32Go (/1000000) et ~30,5Gio (/1048576)

En effet on peut choisir l'unité avec la commande free :
 

 
https://linuxize.com/post/free-command-in-linux/
 
 

 
J'aurai donc bien 32 Go si j'ai bien compris.

Pareil, je retrouve mes 4 Go (et non 4 Gio, alors ?) comme ça :
 

Depuis une mise à jour récente je remarque qu'il y a maintenant un script "updatedb" qui se lance à chaque boot, ce script est particulierement pénible car il scanne tous les disques dur pour mettre à jour la liste des fichiers présents, ça peut prendre plusieurs minutes si les disques ont beauoup de fichiers.

Vous avez remarqué la même chose ?

Je me souviens qu'à une époque j'avais eu le souci et j'avais réussi à désactiver le lancement de updatedb, je crois que c'est un timer de systemd que j'avais désactivé, mais la même manipulation ne marche plus vraiment, j'ai essayé de masquer le timer mais ça ne semble pas résoudre le problème.

RAS chez moi : si ce truc est présent et actif (j’avoue : j’ai pas regardé), il n’a aucune incidence sur le temps de démarrage de mes ordis Arch.
 
Sinon, si quelqu’un ici saurait comment forcer un démontage propre d’un disque externe USB qui refuse de se démonter alors que rien ne le justifie (autrement qu’en redémarrant l’ordi), je prends !

Moi je viens de regarder...
Soit c'est dans une autre implémentation de locate que j'ai pas, soit c'est un truc qu'il a mis lui même en local ?
Car chez moi ça n'existe simplement pas du tout.

Mon installation d'Arch Linux date de novembre 2013, peut-être qu'à cette époque un paquet apportait le updatedb.timer.
 
En 2014 sur le forum d'Arch Linux on parlait déjà de ce timer :
https://bbs.archlinux.org/viewtopic.php?id=185766
 
J'ai aussi un autre timer : plocate-updatedb.timer.

Et la mienne date de janvier 2010
Pour le coup, tu as raison avec ce nom là : /usr/lib/systemd/system/plocate-updatedb.timer je l'ai aussi et il est activé.
 
Par contre il est pas au démarrage:
OnCalendar=daily
RandomizedDelaySec=1h
AccuracySec=6h
 
Je me suis donc empressé de le masquer aussi, j'ai l'habitude de lancer updatedb moi même les rares fois où j'ai besoin de locate...
Merci pour l'info du coup.