Reprise du message précédent :

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

Pour autant que je sache, il a été installé lors du pacstrap initial des groupes base et base-devel.
 
EDIT : ah, non… En fait, on dirait qu’il est venu avec une MAJ de udisks2 qui a apporté parted et plein d’autres paquets liés à la gestion de disques, partitions et FS :
 

(Extrait du pacman.log de l’Arch de mon portable, installée le 16/7/2016).

Pourquoi s'obliger à redémarrer après la regénération d'un initram aussi ?
Ca sert à rien du tout.

Je veux pouvoir utiliser mes disques durs USB que j’aurais pas forcément branchés avant ladite régénération (et vu que je fais généralement mon « time yay » quotidien juste après avoir allumé le PC, c’est pratiquement toujours le cas). Donc si : ça sert, et pas qu’un peu.

Mais ça ça n'a rien à voir avec la regénération d'initram.
C'est juste que le kernel actuel et les modules sont pas en phase.
Rien a voir avec l'initram

Le soucis dans ce cas c'est le paquet Linux.
Arch devrait garder le paquet du noyau utilisé, et peut-être les 2 derniers aussi, car si le noyau casse ce n'est pas evident pour tout le monde de réparer sans un autre...
Mettre a jour le noyau en RAM c'est un peu embêtant pour les raisons que tu as écrites, sauf si tu fais exprès de lancer tous les modules dont tu pourrais avoir besoin avec modprobe.d mais ca ce n'est pas evident non plus.

Heu… C’est ce qu’il fait, non ? En tout cas, tant que je fais pas de « sudo pacman -Scc », il garde tout dans « /var/cache/pacman/pkg/ ».
 
Quoique, tu veux plutôt dire que Grub devrait garder au moins une partie des versions précédentes des noyaux dans la liste des OS démarrables, comme sur Fedora ou Ubuntu ? Sûrement. En tout cas, c’est justement à la suite de soucis avec des nouvelles versions du noyau que j’ai fini par installer à côté le noyau LTS (qui est devenu le noyau démarré par défaut, et j’ai donc dû changer les réglages de Grub pour qu’il retienne le choix fait au démarrage précédent).
 

Ah,s’il y a moyen de recharger les modules après régénération des initramfs (donc après MAJ de btrfs-progs ou device-mapper ou linux{,-lts} ou systemd, dans mon cas) sans en passer par un redémarrage, j’avoue ne pas avoir regardé si c’était faisable.

 
Ben t’as le LTS en dualboot non ?
 
Sinon j’ai jamais eu besoin de rebooter après une maj Arch, mais j’utilise rien de farfelu genre encryption ou autre. Mais j’ai jamais entendu le besoin de devoir faire ça…c’est quoi le problème exactement ?

Par défaut (et je parle d’une installation à la main, pas via des assistants dédiés), tu n’as que le noyau normal. Pour avoir le LTS, il faut le demander explicitement.
 

Oh, certes, non, il n’y a en soi pas de besoin impératif de redémarrer, mais il y a des cas où ça peut s’avérer nécessaire, rien que pour pouvoir être tranquille pour le reste de la journée et ne pas se demander pourquoi, soudainement, t’as des choses qui ne fonctionnent plus comme un DD externe que tu branches et qui n’est soudainement pas reconnu, alors que c’était encore le cas avant la dernière salve de MAJ qui a concerné un ou plusieurs des paquets que j’ai énumérés dans mon message précédent ; que tu sais que ce DDE fonctionne très bien, et que le seul moyen de pouvoir t’en servir de nouveau est de… redémarrer d’abord, comme je l’ai déjà rappelé tout un peu plus haut dans cette page :
 

Le "problème" c'est qu'arch remplace le paquet kernel à chaque upgrade.
Pour qu'un module/driver se charge depuis le filesystem faut qu'il soit de la même version que le kernel qui est chargé.
Les modules sont dans le paquet kernel.
 
Donc si tu upgrade un kernel déjà chargé (à part de rares cas spécifiques) les modules du kernel actuel seront inaccessibles parce que /lib/modules/linux-$version n'existera plus (remplacé par /lib/modules/linux-$version_new suite à l'upgrade)
(Y a sûrement moyen de lui forcer la main et le faire charger un module de version différente avec insmod, mais c'est une mauvaise idée )

Oui.

Comme make install te l'a dit, ca n'a rien avoir avec initramfs et non il n'y a pas moyen, il faut charger les modules avant la mise a jour (enfin si la mise a jour ne change pas la version du noyau il n'y aura pas de problème).

Ca aura le meme soucis, et le LTS parfois ne peut pas être utilisé si tu as besoin d'une fonctionnalité trop récente du noyau.

Lance ton PC, ne fais rien sauf une mise a jour du noyau qui change sa version, tu ne pourras plus monter une image avec mount -o loop . Pourquoi? Car ton noyau en x.y.z n'a plus de modules sur le disque depuis que tu as fait ta mise a jour en x.y.z+n. Par exemple, le repertoire du Linux actuel est /usr/lib/modules/6.1.4-arch1-1/ mais si mon noyau en RAM est 6.1.3 il cherchera dans /usr/lib/modules/6.1.3-arch1-1/ qui est vide/n'existe plus.

OK, on va dire que je confondais cause et (une des) conséquences.
 

↑↑↑ This ↑↑↑
 
Je citais les conséquences à l’usage, mais Gee explique mieux le détail des raisons.

Carnet gris pour Jonathon Fernyhough, contributeur très actif sur Arch, et qui nous a quittés samedi dernier…
 
https://archlinux.org/news/in-memor [...] ernyhough/

RIP

 
Mise à jour de grub aujourd’hui. [2023-01-20T18:28:50+0100] [ALPM] upgraded grub (2:2.06.r415.g1a241e050-1 -> 2:2.06.r440.g4de39a2af-1).  Ils recommandent un grub install et une reconfig (grub-mkconfig -o /boot/grub/grub.cfg).  
Pour ceux qui ont déjà eu des déboires.   . De mon coté c'est passé. Je suis en MBR.

Ils ont simplement laissé le message ajouté dans le PKGBUILD et affiché en fin d’installation de la MAJ depuis la révision 322 de GRUB 2.06. Message qui ne concerne en effet pas les installations en mode MBR faites sur des machines à BIOS classique, qui peuvent donc ignorer superbement cette mise en garde.
 
Mais je pense qu’une fois la révision 322 faite et la procédure effectuée à l’époque, même les machines UEFI n’ont plus besoin de refaire toute la procédure de réinstallation et reconfiguration de GRUB…

Salut, est-ce qu'il y a eu des changements dans des paquets liés à OpenVPN ou NetworkManager, ou tout autre lié à la gestion du VPN ? Depuis plusieurs jkours, je parviens à me connecter au VPN de mon entreprise, mais je ne peux accéder à rien, ni page internet en .lan ni ssh. En revanche, le ping des machines fonctionne. Des idées ?

Bonjour,
[2023-01-28T18:39:10+0100] [ALPM] upgraded openvpn (2.5.8-2 -> 2.6.0-1). [2023-01-27T16:40:28+0100] [ALPM] upgraded networkmanager (1.40.10-1 -> 1.40.12-1)
Mise à jour OpenVPN le 28/01 chez moi et NetworkManager la veille. Mon VPN n'a pas bronché suite à la mise à jour....

Salut,
 
Ici openfortivpn + NetworkManager = aucun souci non plus

Merci les gars. Je tente un downgrade de ces paquets demain pour voir.

Bon et bien en effet, c'est la mise à jour du paquet openvpn qui cause le problème, j'ai downgradé à la version précédente et maintenant tout fonctionne.

Pour ceux qui ne sont pas sur la ML:
 

Est-ce que ça concerne ceux qui ont une installation d'archlinux qui date de novembre 2013 ?
 
Je ne sais plus si à l'époque j'avais installé le méta-paquet "base-devel".

Oh ! T’es de retour ??! Je te croyais disparu pour de bon (vraiment !), vu que ça fait un bail que t’as plus posté ici.

« Ceux qui ont installé base-devel avant le 2 février », chez moi, ça inclut toutes les installations datant d’avant cette date, sans limite de temps.

Perso, je l’ai fait : ça m’a installé un ou deux paquets (debugedit, surtout) selon le PC traité, mais j’imagine que comme ça, Pacman sera content parce qu’il aura un base-devel bien comme il faut.

Mon install date de 2010, j'avais pas ce paquet. On parle pas de groupe justement.
 
Ca se vérifie facilement avec -Qi
Et au pire ça fait pas de mal de le réinstaller.
 
C'est bien qu'ils continuent (je me souviens que ça fait déjà quelques années qu'ils ont commencé) l'effort de dégager les groupes pour remplacer par des metapaquets.
C'était assez foireux les groupes

Merci pour les réponses

si j'utilise cette commande j'ai des résultats :

là on voit qu'il y a du base-devel, j'ai retrouvé mon tuto d'installation texte datant de 2013, j'avais écrit ces lignes :

j'ai ensuite tenté le pacman -Syu base-devel : ça m'a installé debugedit-5.0-4  et base-devel-1-1.

Oui je suis de retour, pour voir les news du topic sur archlinux, j'étais en effet de moins en moins présent sur le forum HFR depuis fin septembre.

 
je venais juste de faire une maintenance, hier soir, trier les pacnews et pacsaves... Debugedit faisait parti des orphelins. Je suppose installé lors de compilation de paquet AUR. A vous lire, je me suis décidé à installer base-devel.
Pamac devrait être content.  
En historique debugedit est régulièrement installé et désinstallé (je supprime souvent les orphelins).
Voila ce que donne la cde pacman -Qg | grep "base" chez moi après installation de base-devel:

Première fois pour moi depuis que je touche à Arch (soit depuis la mi-août 2014).

Je ne sais pas si c'est la première fois ici mais la commande au dessus m'a installé debugedit.

Mon père s’est plaint qu’il ne pouvait plus scanner avec son imprimante (HP OfficeJet 4650) : Simple Scan affiche une erreur « Bac d’alimentation vide » quand il essaie. Je me rappelais que le paquet sane avait eu des MAJ récemment, donc j’ai essayé avec une version précédente (1.1.1 au lieu de 1.2.1), et bingo, c’était ça : c’est cette version 1.2.1 qui casse la numérisation depuis un PC.
 
Rapport de bug.
 
J’espère que quelqu’un voudra bien se pencher dessus et régler ça, vu que mon père utilise assez souvent le scanner (pour garder des traces de chèques ou autres documents importants)…

Avec ce scanner est-ce que tu es obligé de passer par un bac d'alimentation pour scanner ? (insertion du document dans une sorte de bac qui l'avale, et qui ressort ensuite une fois scanné)

Ou bien tu peux aussi scanner à l'ancienne, en posant le document papier sur une vitre ?

Tu as essayé avec le logiciel xsane pour scanner ?
https://archlinux.org/packages/extra/x86_64/xsane/

Faudrait aussi voir s'il y a des fichiers logs exploitables, lancer le logiciel de scan avec l'option "--verbose, ou --debug",
 
un "git bisect" peut aider à identifier le commit qui a introduit le bug, c'est souvent ce qui permet au développeur de résoudre le rapport de bug si tu lui montres le commit fautif :
https://delicious-insights.com/fr/articles/git-bisect/

le dépôt git de sane, plusieurs projets, le paquet archlinux de sane correspond au projet "backends" :
https://gitlab.com/sane-project/

https://github.com/archlinux/svntog [...] k/PKGBUILD

 
J'ai voulu essayer chez moi pour voir si je rencontrais le problème. Imprimante HP ENVY 7640, Simple scan 42.5, sane 1.2.1-3. Je ne rencontre pas le problème . J'ai été à deux doigts de l’édit! Quand j'ouvre simple scan, celui-ci recherche les périphériques, j'ai un menu déroulant avec le choix entre:  "HP ENVY 7640 series" et "HP ENVY 7640 series [F104CA]" . J'ai le message "Bac d’alimentation vide" avec l'option "HP ENVY 7640 series [F104CA]" du menu. Je creuse un peu pour comprendre ...  
 
Diagnostique lancé depuis HP device manager:

 
Edit pfff:
  HP ENVY 7640 series [F104CA] est l'identifiant du protocole "Bonjour" , voir dans les paramètres avancé du WIFI de l'imprimante.  

Les deux sont possibles avec ce modèle, mais j’ai testé avec le scanner vitre (et Simple Scan était réglé pour utiliser celui-là dans tous les cas).
 
tarfun : c’est vrai que j’ai deux mentions de l’imprimante. À voir quand je me repencherai dessus. Si ça se trouve, c’est parce que je choisis la « mauvaise » imprimante (mais ça ne dérangeait pas sane 1.1.1, pourtant).

S'il y a une possibilité de configurer manuellement le choix du périphérique alors c'est en effet une piste à suivre.
https://wiki.archlinux.org/title/SA [...] roblems#HP
https://wiki.archlinux.org/title/SANE

Quand on utilise le logiciel xsane (l'alternative à "simple scan" ) : au lancement du logiciel on a systématiquement une fenêtre qui nous demande de choisir un périphérique de scan, ça évite ce genre de problème (d'ailleurs chez moi dans la liste il me propose ma carte tuner DVB-T en plus de mon scanner USB).

Essaie aussi de créer un rapport de bug sur le site de sane (projet backends),
je le fais souvent lorsque je crée un rapport de bug sur le site d'archlinux, sinon un dévelo archlinux risque de te le demander, le problème n'étant pas forcément dû à un problème de packaging archlinux (à moins de le prouver en analysant les différences dans le PKGBUILD par rapport à la version N - 1, et en compilant avec les options par défaut conseillées par les développeurs de sane-backends) :
https://gitlab.com/groups/sane-project/-/issues

Tarfun : c’était ça ! C’était la mauvaise imprimante qui était sélectionnée. En refaisant un essai mais en choisissant l’imprimante dont le nom n’avait pas d’identifiant entre crochets, ça a fonctionné direct ! Eh ben, ça me soulage de voir que ça a pu être réglé aussi facilement (en espérant que le bon nom sera conservé par la suite) !

Je préfère « remonter le courant », surtout après avoir justement essayé de signaler directement à la source quand j’avais un souci avec GIMP (impossible d’ouvrir des images dont l’URL contenait des espaces (%20) dans le nom de fichier, alors que ça marchait très bien jusque-là ; depuis, ce bug a quand même été corrigé). Mais bon, grâce à l’indice de Tarfun, j’aurai même pas à le faire. Merci quand même pour l’histoire du « sane-backend », parce qu’avec toutes leurs branches parallèles, c’est pas évident de savoir vers laquelle se tourner.

Pour ce que ça vaut, là le scanner est théoriquement utilisable selon 2 protocoles, hpaio, les pilotes HP spécifiques et par détection auto via escl.
 
Pour moi c'est un bug dans sane au niveau du protocole escl (gestion automatique du scanner sans pilote, utilisé par airscan chez apple) qui ne devrait pas poser ce soucis, surtout si ça marchait en 1.1.

Y a clairement un truc qui a dû changer entre les deux versions, mais vu que j’ai pu le faire remarcher…
 
Pour cette imprimante, j’utilise uniquement CUPS. J’ai rien installé d’autre (à part hplip et system-config-printer, mais ce sont pas des pilotes).

Bonsoir,
 
je me suis entêté sur cette histoire d'imprimante.
Avec xsane de la même façon qu'avec Simplescan , à l'ouverture je dois sélectionner entre "HP ENVY 7640 series" et "HP ENVY 7640 series [F104CA]" et j'ai le message  "Bac d’alimentation vide" avec l'option "HP ENVY 7640 series [F104CA]" du menu. Ce message devrait être quelque chose comme: l'imprimante n'est pas en ligne. D'autant que je me souvienne, j'ai toujours eu ces deux choix, et sélectionné celui qui fonctionnait, une fois pour toutes, sans me poser  de questions.
J'ai découvert qu'il existait un paquet sane-airscan 0.99.27-1 (sane backend for AirScan eSCL and WSD document scanners) dans les dépots. Le protocole s'appelle Bonjour chez HP.  
 
Après installation de ce paquet, je peux scanner en utilisant les deux protocoles, escl et hpaio. J'ai un troisième choix : "eSCL HP ENVY 7640 series [F104CA]" dans le menu déroulant de simple scan. Dommage, le choix "HP ENVY 7640 series [F104CA]" est toujours là et pas fonctionnel.
 
Dans la série "on en apprend tous les jours" , en ouvrant l’adresse ip locale de l'imprimante dans un navigateur, on accède au serveur web embarqué de l'imprimante HP, depuis lequel on peut scanner...  Et c'est plutôt bien fait.  Un favori dans le navigateur plutôt qu'une application?  
 
Voir SaneOverNetwork et CUPSAirPrint dans le wiki Debian

Oh, trop cool : j’ai enfin pu mettre l’horloge de cette fichue imprimante au format 24h (chose impossible depuis les options du panneau tactile de l’imprimante) ! \o/

En revanche, il y a un truc qui me plaît un peu moins bien, c’est le rapport d’utilisation : je lis :

Ça veut dire qu’il ne nous reste que 1751 pages pouvant être imprimées avant que l’imprimante ne décide unilatéralement de dire qu’elle en a marre et refuse d’en imprimer davantage ? C’est mon père qui va être content (et ça lui apprendra à imprimer tout et n’importe quoi, comme les prochains horaires du tram quand il doit se rendre quelque part)…

Je ne pense pas, j’espère     960-15=945?

Tu nous diras ça dans 15 pages, parce que c’est quand même bizarre que le nombre de pages ordinaires imprimées soit supérieur au nombre total de pages imprimées. Et pourquoi un nombre négatif pour les « autres types » ?