Erreur de dpkg > mises à jour impossible

Bonjour,
Je suis actuellement sous Debian Buster, Kernel 4.16.0-2-amd64.
Ce matin en mettant à jour mon pc, je suis tombé sur cette erreur. Ca va bientôt faire 3 bonne heures que je cherche une solution, tout ce que je trouve sur internet est trop vieux… :confused:
Est-ce que quelqu’un aurait une solution à m’apporter ?

$ sudo apt upgrade
Lecture des listes de paquets…
    Construction de l'arbre des dépendances…
    Lecture des informations d'état…
    Calcul de la mise à jour…
    0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
    5 partiellement installés ou enlevés.
    Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
    Souhaitez-vous continuer ? [O/n] Paramétrage de udev (239-7) ...
    Le groupe « kvm » existe déjà, sans être un groupe système. Fin de la procédure.
    dpkg: erreur de traitement du paquet udev (--configure) :
     installed udev package post-installation script subprocess returned error exit status 1
    dpkg: des problèmes de dépendances empêchent la configuration de initramfs-tools-core :
     initramfs-tools-core dépend de udev ; cependant :
     Le paquet udev n'est pas encore configuré.

dpkg: erreur de traitement du paquet initramfs-tools-core (--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de initramfs-tools :
 initramfs-tools dépend de initramfs-tools-core (= 0.131) ; cependant :
 Le paquet initramfs-tools-core n'est pas encore configuré.

dpkg: erreur de traitement du paquet initramfs-tools (--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de linux-image-4.17.0-1-amd64 :
 linux-image-4.17.0-1-amd64 dépend de initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool ; cependant :
 Le paquet initramfs-tools n'est pas encore configuré.
  Le paquet linux-initramfs-tool n'est pas installé.
  Le paquet initramfs-tools qui fournit linux-initramfs-tool n'est pas encore configuré.

dpkg: erreur de traitement du paquet linux-image-4.17.0-1-amd64 (--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de linux-image-amd64 :
 linux-image-amd64 dépend de linux-image-4.17.0-1-amd64 ; cependant :
 Le paquet linux-image-4.17.0-1-amd64 n'est pas encore configuré.

dpkg: erreur de traitement du paquet linux-image-amd64 (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 udev
 initramfs-tools-core
 initramfs-tools
 linux-image-4.17.0-1-amd64
 linux-image-amd64

Quand je fais dpkg -C , j’obtient :

Les paquets suivants ont été dépaquetés mais ne sont pas configurés. Ils
doivent être configurés en utilisant dpkg --configure ou l'option configure
du menu de dselect pour pouvoir fonctionner :
 initramfs-tools      generic modular initramfs generator (automation)
 initramfs-tools-core generic modular initramfs generator (core tools)
 linux-image-4.17.0-1-amd64 Linux 4.17 for 64-bit PCs
 linux-image-amd64    Linux for 64-bit PCs (meta-package)

Les paquets suivants sont à demi configurés, probablement à cause de
problèmes survenus lors de la première configuration. Il faudrait réessayer
de les configurer en utilisant dpkg --configure <paquet> ou l'option
configure du menu de dselect :
 udev                 /dev/ and hotplug management daemon

Et… Je ne sais pas trop quoi en faire finalement :sweat:

Merci d’avance ! :slight_smile:

ok

J’utilise stretch, et je vois à propose de ce paquet udev

  • une taille respectable pour un utilitaire système ( > 7Mo)
  • une contrainte Pre-Depends: dpkg
  • un paquet source nommé systemd
    Bref nous sommes au coeur du système.

Avez-vous essayé la gentille suggestion donnée par dpkg --audit?

sudo dpkg --configure udev

suivi d’un apt upgrade s’il n’y a pas d’erreur

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

The statement below is true.
The statement above is false.
https://frishit.wordpress.com/2010/04/26/paradoxes-self-reproducing-code-and
-bash/

Tout d’abord, merci de votre réactivité :slight_smile:

J’avais déja essayé cette commande, elle me retourne le mesage d’erreur :

Paramétrage de udev (239-7) ...
Le groupe "kvm" existe déjà, sans être un groupe système. Fin de la procédure.
dpkg: erreur de traitement du paquet udev (--configure) :
 installed udev package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution  :
 udev

On progresse
Le message est donc bien lié à la présence d’un groupe kvm.
A votre place, je vérifie via

getent group kvm

je supprime ce groupe mal configuré (qui n’ existe pas sous stretch d’ailleurs) et relance

sudo delgroup kvm
sudo dpkg --configure kvm

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

En ces temps de canicule, monsieur le CIO (Chief Executive Officer) l’avait pourtant prévu
« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

Bonjour

Sur mon système le groupe kvm existe :

michel@debg53sw:~$ cat /etc/group | grep kvm
kvm:x:123:
michel@debg53sw:~$ 

Mais virt-manager a été installé sur mon système debian stretch.

Je n’ai pas vérifié si le groupe kvm existait avant l’installation de virt-manager
et/ou sur une machine dont le microprocesseur ne permettrait pas la virtualisation
ou que l’option du BIOS permettant la virtualisation soit désactivée.

Merci encore de vous pencher sur mon cas :grin:

Alors en suivant vos indications , j’obtiens :

$ getent group kvm
kvm:x:1001:terruss
$
$ sudo delgroup kvm
/usr/sbin/delgroup: "libvirt-qemu" possèdent toujours "kvm" en tant que groupe primaire !
$ sudo dpkg --configure kvm
dpkg: erreur de traitement du paquet "kvm" (--configure)
 aucun paquet nommé "kvm" n'est installé, configuration impossible
Des erreurs ont été rencontrées pendant l'exécution :
 kvm

Je réessaye de configurer udev :

$ sudo dpkg --configure udev
Paramétrage de udev (239-7) ...
Le groupe "kvm" existe déjà, sans être un groupe système. Fin de la procédure.
dpkg: erreur de traitement du paquet udev (--configure) :
 installed udev package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution  :
 udev

kvm est revenu ! :weary:

Pour ce qui est de l’existence du groupe kvm sur ma machine, c’est peut être parceque j’ai installé cordova et certains utilitaires qui permettent de virtualiser Android pour du développement :thinking:

Mais ça doit faire 6 mois que j’utilise ces outils sans problèmes…

Merci, Michel de me corriger. Je voulais simplement dire que j’avais une machine sous stretch et qu’avec une installation simple d’un bureau xfce je n’avais pas ces logiciels de virtualisation et donc que

getent group kvm

ne retournait rien.
Il se pourrait que le message

nne soit qu’une simple information, et que les choses se compliquent pour TERRUSS

Ne mélangeons pas tout !

Le système vous dit que le groupe kvm est nécessaire au bon fonctionnement d’un paquet nommé libvirt-qemu. et même il est très vraisemblable que que le groupe a été créé à l’étape de configuration de ce paquet.
Avant de tout casser, vous pouvez vérifier que le groupe kvm a bien disparu du système

getent group kvm

Si rien n’est retourné il est grand temps de rectifier le tir (le delgroup sans l’option --only-if-empty)

sudo  aptitude  reinstall  libvirt-qemu

(je n’ai pas vu d’option reinstall avec apt)
Ceci devrait remettre les choses d’aplomb en ce qui concerne ce groupe kvm.

Nous en revenons à la difficulté initiale

et là c’est une autre paire de manches :disappointed_relieved:
Il faudrait éplucher les presque 200 lignes de /var/lib/dpkg/info/udev.postinst pour trouver l’origine de l’erreur :tired_face:
Mais comme vous êtes un utilisateur chevronné qui maîtrise les technologies de virtualisation et qui utilise la distribution buster( aka testing) je ne doute pas qu’avec ces éléments vous allez trouver. Peut-être même que vous allez pouvoir rédiger un rapport de bug (sur udev qui ne se configure pas bien sous buster dans un système avec certains paquets de virtualisation).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Je vous déclare encore ceci : il est difficile à un chameau de passer par le trou d’une aiguille, mais il est encore plus difficile à un riche d’entrer dans le royaume de Dieu. »
– Matthieu 19:24

Bonjour

Ooops !!

Le GID de ce groupe est supérieur à 1000 ce qui ne me semble pas "normal"
et qui pourrait expliquer le message d’erreur retourné :


Le groupe “kvm” existe déjà, sans être un groupe système. …

Voir : WiKipedia : Group identifier - Reserved ranges

et un extrait du contenu du fichier /etc/adduser.conf

…
# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
# for dynamically allocated administrative and system accounts/groups.
# Please note that system software, such as the users allocated by the base-passwd
# package, may assume that UIDs less than 100 are unallocated.
FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999

FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=999
…

Pour info, libvirt-qemu est aussi installé sur ma machine
mais le groupe kvm sur tous mes systèmes debian utilise le GID N° 123

michel@debg53sw:~$ getent group kvm
kvm:x:123:
michel@debg53sw:~$ 
1 J'aime

Oulah c’est bien trop me surestimer :sweat_smile:
C’est juste que j’aime bien le challenge :grin:

Du coup, rien n’a changé du côté de kvm :
$ getent group kvm
kvm:x:1001:terruss

Du coup, est ce qu’il y a moyen de “normaliser” l’id du groupe manuellement ?

Spéculation. Sauf erreur de ma part, le système se borne à dire que le groupe kvm est défini comme groupe principal de l’utilisateur libvirt-qemu.
id libvirt-qemu
En plus de cela, il apparaît que l’utilisateur terruss est aussi membre de ce groupe.

Le groupe kvm a un GID de groupe utilisateur standard (GID>=1000) alors que le nouveau paquet udev semble vouloir qu’il soit un groupe système (GID<1000).

Délicat. La commande groupmod permet de modifier le GID d’un groupe. Mais le GID est ce qui est enregistré dans les permissions d’un fichier, donc si on le modifie on risque de rencontrer des effets de bords, le groupe avec un nouveau GID ayant perdu la propriété des fichiers portant l’ancien GID.

Oui, c’est possible. D’ailleurs vous connaissez le sketch des Nuls

Hassan Cehef, c'est possible

Eh bien, avec Debian GNU/Linux c’est possible !

man vigr
sudo vigr
sudo vigr  --shadow

Ceci étant dit, lisez les commentaires très pertinents de @MicP et @PascalHambourg

id libvirt-qemu

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

Merci à tous.

id libvirt-qemu

J’ai :

$ id libvirt-qemu
uid=64055(libvirt-qemu) gid=1001(kvm) groupes=1001(kvm),64055(libvirt-qemu)

Est ce que je dois tenter de mettre un GID au hasard < 1000 à kvm ? :rofl:

Pas moyen de trouver un paquet avec cordova dans le nom sur https://packages.debian.org/
Quelle est l’origine exacte de ce logiciel ?

apt-cache policy cordova
egrep  -v '^#|^$' /etc/apt/sources.list  /etc/apt/sources.list.d/*

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Je préfère le vin d’ici à l’au-delà »
Pierre Dac

Désolé ne ne pas avoir été assez précis ^^’

Cordova est un framework pour créer des applications à partir de fichiers html, css, et javascript.
Il s’install à partir de la CLI de Node.js

Comme je fais des applications sur android, j’ai du installer java, ainsi qu’un émulateur de device android. Vu que kvm sert à la virtualisation, et qu’il n’est pas présent de base sur debian, je me suis dit que les deux peuvent être liés (totale supposition de ma part).

Quand j’entends le mot Node.js, je sors mon revilver :smile: Franchement un écosystème où des micro-paquets poussent plus vite que les champignons. La multiplication anarchique des bibliothèques amène à un écosystème ingérable et dans pas mal de paquets node-machin on a plus d’informations de méta-données (description, dépendances, copyright, URLs, …) que de lignes de code. C’est un enfer à empaqueter correctement.
Dans la distribution stretch les développeurs Debian n’ont pas chômé malgré tout

fp2@debpacha:~$ aptitude  search  node | wc
    792    7672   52939

soit plus d’un paquet par jour pendant deux ans, sans discontinuer.

Ah oui ?

fp2@debpacha:~$ aptitude  search  kvm
v   kvm                             -                                           
v   kvm:i386                        -                                           
p   kvmtool                         - Native Linux KVM TOOL                     
p   kvmtool:i386                    - Native Linux KVM TOOL                     
p   libicsharpcode-nrefactory-ikvm5 - C# Parsing and Refactoring Library - IKVM 
p   nova-compute-kvm                - OpenStack Compute - compute node (KVM)    
p   qemu-kvm                        - QEMU Full virtualization on x86 hardware  
p   qemu-kvm:i386                   - QEMU Full virtualization on x86 hardware  
fp2@debpacha:~$ 

Le v en face de kvm signifie que c’est un paquet virtuel, un nom attaché à une fonctionnalité précise ici la virtualisation au niveau du noyau.

fp2@debpacha:~$ apt show qemu-kvm
Package: qemu-kvm
Version: 1:2.8+dfsg-6+deb9u4
Priority: extra
Section: oldlibs
Source: qemu
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Installed-Size: 103 kB
Provides: kvm
Depends: qemu-system-x86 (>= 1.7.0+dfsg-2~)
Conflicts: kvm
Breaks: qemu-system-x86 (<< 1.7.0+dfsg-2~)
Replaces: qemu-system-x86 (<< 1.7.0+dfsg-2~)
Homepage: http://www.qemu.org/

et d’autre part

fp2@debpacha:~$ aptitude  search   libvirt | wc
     46     368    2827

Le seul point commun que je vois entre Cordova et

p2@debpacha:~$ aptitude  search android  | wc
    163    1642   14438

c’est qu’on est dans des technologies buzzword compliant.

Pour y voir plus clair et trouver le foutu paquet qui a créé l’utilisateur libvirt-qemu je vous invite à vous transformer en inspecteur. Commencez vos investigations en cherchant le répertoire de cet utilisateur

getent passwd libvirt-qemu | tr ':' '\t'

et vous répétez la commande en ajoutant | cut -f 6 à la fin pour avoir le champ HOME associé.
Puis vous prenez l’exemple suivant : à quel paquet appartient le répertoire /var/lib/dpkg/info

fp2@debpacha:~$ dpkg-query --search /var/lib/dpkg/info | tr ':' '\t' | cut -f 1
dpkg

Une fois que vous avez le nom du paquet

apt-cache policy $pkg
aptitude  why  $pkg
debmany $pkg

Bref, vous ne lâchez pas le morceau, vous parcourez les dépendances avec

apt-cache depends  $pkg
apt-cache rdepends  $pkg

pour les paquets de la chaîne hiérarchique
Ben Allo -> Chef de Cabinet -> Directeur de cabinet adjoint -> directeur de cabinet -> secrétaire général -> …

Nous ne savons toujours pas si votre installation est pure Debian

egrep  -v '^#|^$' /etc/apt/sources.list  /etc/apt/sources.list.d/*

Ce message vous a été envoyé dans le cadre d’une campagne de promotion de la lecture des pages de manuel et de l’utilisation de la ligne de commandes.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

I hope to die before I have to use Microsoft Word.
- Donald E. Knuth, 2001-10-02 in Tübingen

1 J'aime

quand tu auras solutionné ton problème , n’oublie pas d’installer apt-listbugs , ça t’aidera à ne pas mettre de paquet vérolé sur ta machine .

J’ai finalement fait une reinstall complète de debian, merci a tous pour l’aide, et bonne chance a ceux qui auront le même soucis que moi :slight_smile: