Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 10/01/2020 à 22:31, ajh-valmer a écrit :

On Friday 10 January 2020 21:34:25 Pascal Hambourg wrote:

Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :

Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
qui n'a plus raison d'être dans Buster car intégré à son noyau.



mountkernfs.sh n'est pas du tout intégré au noyau. C'est absurde.


Réponse trop courte, sans précision :
soit..., mais ou est-il passé ?
Le package n'existe plus sous Buster.


Si : cf. 


Alors le service mountkernfs est géré par systemd,


Disons plutôt qu'il le remplace, puisque le paquet systemd installe un 
lien symbolique qui inhibe ce service.


/lib/systemd/system/mountkernfs.service -> /dev/null

Re: insserv: FATAL: service mountkernfs is missed

[ajh-valmer]

On Friday 10 January 2020 21:34:25 Pascal Hambourg wrote:
> Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :
> > Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
> > qui n'a plus raison d'être dans Buster car intégré à son noyau.

> mountkernfs.sh n'est pas du tout intégré au noyau. C'est absurde.

Réponse trop courte, sans précision :
soit..., mais ou est-il passé ?
Le package n'existe plus sous Buster.

Alors le service mountkernfs est géré par systemd,
sous un autre nom sans doute ?
Je vais donc retirer "mountkernfs.sh".

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :


Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
qui n'a plus raison d'être dans Buster car intégré à son noyau.


mountkernfs.sh n'est pas du tout intégré au noyau. C'est absurde.

Erreur apt/dpkg

[BERTRAND Joël]

Bonsoir à tous,

Sur une debian/testing à jour (sur laquelle j'essaie de corriger un
problème hplip), j'attrape cette erreur que je n'arrive pas à identifier :

root@hilbert:~# dpkg -i --force-all
/var/cache/apt/archives/libboost1.67-dev_1.67.0-17_amd64.deb
Sélection du paquet libboost1.67-dev:amd64 précédemment désélectionné.
(Lecture de la base de données... 574982 fichiers et répertoires déjà
installés.)
Préparation du dépaquetage de .../libboost1.67-dev_1.67.0-17_amd64.deb ...
Dépaquetage de libboost1.67-dev:amd64 (1.67.0-17) ...
dpkg: erreur de traitement de l'archive
/var/cache/apt/archives/libboost1.67-dev_1.67.0-17_amd64.deb (--install) :
 impossible d'installer une nouvelle version de
« /usr/include/boost/vmd/detail/recurse/data_equal/data_equal_4.hpp »:
Aucun fichier ou dossier de ce type
dpkg: error while cleaning up:
 impossible de réinstaller la copie de secours de
« /usr/include/boost/log/expressions/formatters/wrap_formatter.hpp »:
Aucun fichier ou dossier de ce type
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/libboost1.67-dev_1.67.0-17_amd64.deb

Or le fichier en question existe :

root@hilbert:~# ls -l
/usr/include/boost/vmd/detail/recurse/data_equal/data_equal_4.hpp
-rw-r--r-- 1 root root 5110 janv.  7 13:13
/usr/include/boost/vmd/detail/recurse/data_equal/data_equal_4.hpp

J'ai essayé de retirer le paquet en question puis de le réinstaller
sans plus de succès.

Une idée ?

JKB

Re: [testing] se connecter sur un NAS

[Pierre Malard]

Ok,

Dans ce cas l’important est dans les UID des Linux et des droits de ceux-ci sur
le Syno. Le tout est que tes 2 PC sous Linux utilisent les mêmes utilisateurs
au sens Unix du terme soit le même UID/GID et que ton partage Syno autorise
l’écriture de cet UID.

Dans cette configuration l’important est seulement de partager ton répertoire
Syno uniquement par NFS et de monter ce répertoire sur tes PC. Soit sur le
Syno :
- Panneau de configuration / Panneau de configuration
  Activer uniquement NFS et vérifier que le tag « Application des permissions
  Unix par défait » soit coché dans les paramètres avancés
- Panneau de configuration / Dossier partagé
 o créer un partage « toto »
 o Soit en le créant soit en le sélectionnant et cliquant sur « Modifier »
   - Choisir « Autorisations NFS » et ajouter les noms ou IP de tes PC (ou
 tout le réseau) avec :
 o Privilège : « Lecture/écriture »
 o Squash : « Pas de nappage »
 o Sécurité : « sys »
 o Activer le mode synchrone coché

Sur ton/tes PC il te suffit de monter le répertoire « toto » avec les droits
root :
  # mount :/toto /
et de tester si tu peux créer un fichier ou répertoire sur ce point de
montage.

Si ça fonctionne et que tu veux que ce répertoire soit monter automatiquement
au démarrage de ton PC, ajoute simplement une ligne du genre dans
« /etc/fstab » :
:/toto  / nfs4
rw,vers=4.0,hard,proto=tcp  0   0

En fait tu peux voir les paramètres à indiquer en affichant le fichier
« /etc/mtab » une fois le montage NFS de test effectué. Mais en sachant
que beaucoup des options affichées le sont par défaut.

En espérant que cela t’aide, bonne année.


> Le 10 janv. 2020 à 11:12, Gaëtan Perrier  a écrit :
> 
> Bonjour,
> 
> Mon but est de déporter une partie de mon home sur le NAS afin qu'il puisse
> être commun entre 2 PC sous Linux, donc pas de Windows dans la boucle.
> Il y a d'autres données (genre photos/vidéos) qui éventuellement seront 
> accéder
> par d'autres systèmes pour lesquelles un montage Samba pourrait convenir
> effectivement.
> Mais pour le home j'ai commencé effectivement avec Samba mais j'ai très vite
> rencontré des problèmes avec certains noms de fichiers/répertoires
> incompatibles.
> Le NAS (Synology) tourne sous Linux et le FS est btrfs.
> 
> A+
> 
> Gaëtan
> 
> Le vendredi 10 janvier 2020 à 07:48 +0100, Pierre Malard a écrit :
>> Bonjour,
>> 
>> NFS est un très bonne solution mais le tout est de savoir ce que tu entends
>> par « conserver la gestion des droits » ?
>> Ne serait-ce pas plutôt : « avoir une gestion des droits identique depuis
>> un PC sous Windows et sous Unix » ou sur le NAS directement et depuis
>> Unix ?
>> Si c’est bien ça, dans ce cas, le problème n’est pas la conservation des
>> droits mais d’utiliser le même protocole de partage et/ou la même
>> identification pour des utilisateurs différents.
>> Comme je le suppute la définition des droits du NAS est diffusée via
>> Samba pour des partages Windows avec un mappage des UID par translation
>> pour éviter les mélanges d’identification. Du coup, NFS va poser problème
>> car rien n’indique l’identité de UID/GID et seul SMB garantira une
>> certaine homogénéité.
>> 
>> Donc, pour conclure, tout dépend de ce que tu envisage par partage…
>> 
>> A+
>> 
>>> Le 9 janv. 2020 à 23:18, Gaëtan Perrier  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Je me demande quelle est la meilleure façon de monter un répertoire d'un
>>> NAS
>>> sur debian tout en conservant la gestion des droits.
>>> J'ai essayé nfs mais je me suis perdu dans les problèmes de mappage d'id.
>>> 
>>> A+
>>> 
>>> Gaëtan
> 

--
πr

  « Ce qui tombe sous le sens rebondit ailleurs »
 Jacques Prévert
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: insserv: FATAL: service mountkernfs is missed

[NoSpam]

Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :

[...]
Par contre, initscripts semble utile même si je suis sous systemd.


Non, reprends mes précédents messages: initscripts n'est pas installé 
sur une Buster fraiche.


--
Daniel

Re: insserv: FATAL: service mountkernfs is missed

[ajh . valmer]

On Friday 10 January 2020 10:37:00 Luc Novales wrote:
> Le 07/01/2020 à 16:42, ajh-valmer a écrit :
> > Donc, il ne faut pas désinstaller (remove) "initscripts" ?

> Le problème est je pense que personne ne peut affirmer sans connaître le 
> code qu’il n’y a pas d’interactions, et cette affirmation vaut dans les 
> 2 cas (laisser ou retirer le paquet).
> Dans la mesure où ce sont 2 systèmes concurrents pour gérer la même 
> chose, j’aurais tendance à dire qu’il est plus sains de n’en conserver 
> qu’un pour réduire les risques d’incompatibilités entre eux.
> Même si cela à fait couler de l’encre lors de son adoption, systemd est 
> maintenant le système par défaut de notre distribution depuis Jessie 
>  (Debian 8 04/2015). À l’époque 
> tout a été fait pour qu’il soit compatible avec l’ancien système 
> .
> Pour autant, c’était en vue de transition et à part de vouloir 
> absolument rester sur l’ancien système pour lequel devuan 
>  a été créée, il me semble raisonnable d’apprendre 
> à gérer /systemd/ puisque /initscripts/ n’est plus installé 
> automatiquement depuis stretch (debian 9 06/2017) et que nous parlons de 
> aujourd’hui de Buster (Debian 10), d’ailleurs je ne sais par quel chemin 
> vous en êtes arrivé là ;-)
> Il est difficile d’affirmer que le paquet peut être retiré sans risque 
> d’autant plus que l’on ne sait pas ce que vous avez configuré hors 
> /systemd/ et qui pourrait ne plus fonctionner si la compatibilité n’est 
> pas parfaite.
> Personnellement je le ferais, mais à vous de voir…

Merci de ces considérations.

Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
qui n'a plus raison d'être dans Buster car intégré à son noyau.

Par contre, initscripts semble utile même si je suis sous systemd.

Bonne journée.

Re: hplip

[BERTRAND Joël]

Samy Mezani a écrit :
> Bonjour,
> 
> Le 10/01/2020 à 13:03, BERTRAND Joël a écrit :
>> [...]
>> error: Python gobject/dbus may be not installed
>> [...]
> 
> 
> Je n'ai pas tout suivi, mais au cas où python3-dbus est-il installé ?


root@hilbert:~# dpkg-query -l | grep python3-dbus
ii  python3-dbus  1.2.14-1
  amd64simple interprocess messaging system (Python
3 interface)
iU  python3-dbus.mainloop.pyqt5   5.13.2+dfsg-1
  amd64D-Bus Qt main loop support for Python 3
root@hilbert:~#

Le second paquet me semble dans un état bizarre. Je tente la
réinstallation, mais une dépendance (libboost-dev) plante à
l'installation (sur un lien qu'il ne peut créer). Sur mon poste
diskless, il faut... pas loin d'une demi-heure pour installer
libboost1.67-dev:amd64 (!).

Pour information, j'ai comparé les paquets installés sur une machine
fonctionnelle et une autre (hilbert) dysfonctionnelle. Je n'ai pas
trouvé de différence significative. En regardant dans les sources des
scripts, je vois que les dépendances sont différentes pour qt4 et qt5
dans hp-setup. Ceci explique peut-être cela.

Remarque tout à fait hors de propos... Pourquoi diable faut-il des
dépendances sur la moitié des paquets pour installer un simple plugin de
hplip ? Est-ce qu'on ne pourrait pas faire un chouilla plus simple pour
les outils système ou critiques ? On dirait un programme C++ où
lorsqu'on a besoin d'une banane, on est contraint de siffler le singe
pour qu'il l'apporte sur un plateau entraînant avec lui tous ses copains
de la jungle ! Et surtout, pourquoi utiliser pour des trucs qui
devraient fonctionner en ligne de commande stricte des bouts de qt4 et
qt5 avec, visiblement, des dépendances insatisfaites.

Bien cordialement,

JKB

Re: hplip

[Samy Mezani]

Bonjour,

Le 10/01/2020 à 13:03, BERTRAND Joël a écrit :

[...]
error: Python gobject/dbus may be not installed
[...]



Je n'ai pas tout suivi, mais au cas où python3-dbus est-il installé ?


Samy

Re: hplip

[BERTRAND Joël]

Haricophile a écrit :
> Le lundi 06 janvier 2020 à 16:26 +0100, BERTRAND Joël a écrit :
>> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
>> '/tmp/runtime-bertrand'Plugin installation failed
>> error: Python gobject/dbus may be not installed
>>   error: Plug-in install failed.
>>
>> Je n'arrive pas à savoir où trouver ce fichu gobject/dbus !
>>
>> JKB
> 
> Je n'ai pas suivi, et ça fait un moment que je n'ai plus de HP. Dans mes
> vaques souvenir
> 
> - il faut peut-être faire attention que apparmor n'interfère pas ou une bêtise
> comme ça.
> 
> - En installant hplip-gui et en utilisant hp-toolbox (pas le même nom entre la
> commande et le paquet je ne sais pas pourquoi) ça me permettait d'installer
> tout sans soucis quand la config manuelle avec hp-config était pénible avec
> des trucs a régler.
> 
> 
> 

Même motif, même punition :

error: Python gobject/dbus may be not installed
  error: Plug-in install failed.

Je suppose que le problème vient de gobject/dbus, mais je ne vois pas
comment corriger le problème. Il y a aussi des scripts différents entre
qt4 et qt5. Sans doute quelque chose à creuser de ce côté.

JKB

Re: [testing] se connecter sur un NAS

[ajh-valmer]

Merci de ne pas mettre un certificat dans ton mail,
car une fenêtre s'ouvre sans cesse demandant
de l'accepter ou d'annuler, et c'est pénible...

On Friday 10 January 2020 12:04:38 MAS Jean-Louis wrote:
> Le 09/01/2020 à 23:18, Gaëtan Perrier a écrit :
> > Je me demande quelle est la meilleure façon de monter 
> > un répertoire d'un NAS 
> > sur debian tout en conservant la gestion des droits.
> > J'ai essayé nfs mais je me suis perdu dans les problèmes de mappage d'id.
> Vu que tu n'utilise (probablement) pas de système d'authentification
> global comme LDAP, il faut que *chacun* de tes utilisateurs aient
> strictement les mêmes uid et gid sur tous les systèmes linux que tu va
> utiliser via nfs

Re: [testing] se connecter sur un NAS

[MAS Jean-Louis]

Le 09/01/2020 à 23:18, Gaëtan Perrier a écrit :

> Je me demande quelle est la meilleure façon de monter un répertoire d'un NAS
> sur debian tout en conservant la gestion des droits.
> J'ai essayé nfs mais je me suis perdu dans les problèmes de mappage d'id.

Vu que tu n'utilise (probablement) pas de système d'authentification
global comme LDAP, il faut que *chacun* de tes utilisateurs aient
strictement les mêmes uid et gid sur tous les systèmes linux que tu va
utiliser via nfs

Cordialement

-- 
Jean Louis Mas



smime.p7s
Description: Signature cryptographique S/MIME

Re: [testing] se connecter sur un NAS

[Gaëtan Perrier]

Bonjour,

Mon but est de déporter une partie de mon home sur le NAS afin qu'il puisse
être commun entre 2 PC sous Linux, donc pas de Windows dans la boucle.
Il y a d'autres données (genre photos/vidéos) qui éventuellement seront accéder
par d'autres systèmes pour lesquelles un montage Samba pourrait convenir
effectivement.
Mais pour le home j'ai commencé effectivement avec Samba mais j'ai très vite
rencontré des problèmes avec certains noms de fichiers/répertoires
incompatibles.
Le NAS (Synology) tourne sous Linux et le FS est btrfs.

A+

Gaëtan

Le vendredi 10 janvier 2020 à 07:48 +0100, Pierre Malard a écrit :
> Bonjour,
> 
> NFS est un très bonne solution mais le tout est de savoir ce que tu entends
> par « conserver la gestion des droits » ?
> Ne serait-ce pas plutôt : « avoir une gestion des droits identique depuis
> un PC sous Windows et sous Unix » ou sur le NAS directement et depuis
> Unix ?
> Si c’est bien ça, dans ce cas, le problème n’est pas la conservation des
> droits mais d’utiliser le même protocole de partage et/ou la même
> identification pour des utilisateurs différents.
> Comme je le suppute la définition des droits du NAS est diffusée via
> Samba pour des partages Windows avec un mappage des UID par translation
> pour éviter les mélanges d’identification. Du coup, NFS va poser problème
> car rien n’indique l’identité de UID/GID et seul SMB garantira une
> certaine homogénéité.
> 
> Donc, pour conclure, tout dépend de ce que tu envisage par partage…
> 
> A+
> 
> > Le 9 janv. 2020 à 23:18, Gaëtan Perrier  a écrit :
> > 
> > Bonjour,
> > 
> > Je me demande quelle est la meilleure façon de monter un répertoire d'un
> > NAS
> > sur debian tout en conservant la gestion des droits.
> > J'ai essayé nfs mais je me suis perdu dans les problèmes de mappage d'id.
> > 
> > A+
> > 
> > Gaëtan



signature.asc
Description: This is a digitally signed message part

Re: [testing] se connecter sur un NAS

[Gaëtan Perrier]

Bonjour,

Je me suis dit que SSH n'était pas le plus performant pour une connexion en
local qui ne nécessite pas de sécurité particulière, non ?

A+

Gaëtan

Le vendredi 10 janvier 2020 à 07:17 +0100, benoit a écrit :
> Bonjour,
> 
> Je te suggère un montage SSH, si de plus tu utilise mysecureshell, tu 
> obtient une gestion aux petits oignons.
> 
> Benoit
> 
> Le 09/01/2020 à 23:18, Gaëtan Perrier a écrit :
> > Bonjour,
> > 
> > Je me demande quelle est la meilleure façon de monter un répertoire d'un
> > NAS
> > sur debian tout en conservant la gestion des droits.
> > J'ai essayé nfs mais je me suis perdu dans les problèmes de mappage d'id.
> > 
> > A+
> > 
> > Gaëtan



signature.asc
Description: This is a digitally signed message part

Re: insserv: FATAL: service mountkernfs is missed

[Luc Novales]

Bonjour,

Le 07/01/2020 à 16:42, ajh-valmer a écrit :


Donc, il ne faut pas désinstaller (remove) "initscripts" ?


Le problème est je pense que personne ne peut affirmer sans connaître le 
code qu’il n’y a pas d’interactions, et cette affirmation vaut dans les 
2 cas (laisser ou retirer le paquet).


Dans la mesure où ce sont 2 systèmes concurrents pour gérer la même 
chose, j’aurais tendance à dire qu’il est plus sains de n’en conserver 
qu’un pour réduire les risques d’incompatibilités entre eux.


Même si cela à fait couler de l’encre lors de son adoption, systemd est 
maintenant le système par défaut de notre distribution depuis Jessie 
 (Debian 8 04/2015). À l’époque 
tout a été fait pour qu’il soit compatible avec l’ancien système 
.


Pour autant, c’était en vue de transition et à part de vouloir 
absolument rester sur l’ancien système pour lequel devuan 
 a été créée, il me semble raisonnable d’apprendre 
à gérer /systemd/ puisque /initscripts/ n’est plus installé 
automatiquement depuis stretch (debian 9 06/2017) et que nous parlons de 
aujourd’hui de Buster (Debian 10), d’ailleurs je ne sais par quel chemin 
vous en êtes arrivé là ;-)


Il est difficile d’affirmer que le paquet peut être retiré sans risque 
d’autant plus que l’on ne sait pas ce que vous avez configuré hors 
/systemd/ et qui pourrait ne plus fonctionner si la compatibilité n’est 
pas parfaite.


Personnellement je le ferais, mais à vous de voir…

Bonne journée,

Luc.

​