Le fichier de cache des paquets est corrompu

Support Debian
1

Bonjour,

J’essaie de passer à bullseye mais voilà, j’ai une erreur d’entrée/sortie

    root@Debian:~# apt update
    <...>
    Réception de :49 http://deb.debian.org/debian bullseye/non-free i386 Contents (deb) [29,1 kB]
    103 Mo réceptionnés en 1min 47s (960 ko/s)
    Lecture des listes de paquets... Erreur !
    E: Erreur de lecture - read (5: Erreur d'entrée/sortie)
    W: Vous pouvez lancer « apt-get update » pour corriger ces problèmes.
    E: Le fichier de cache des paquets est corrompu
    root@Debian:~#

J’ai essayé tout ce que je connaissais (apt clean, supprimer le répertoire /var/lib/apt/lists) mais l’erreur persiste. J’ai un taux d’occupation du disque de 15%.

Je ne vois pas trop comment régler ça.

Merci pour vos suggestions

2

pour voir:
sudo rm /var/cache/apt/archives/* /var/cache/apt/*.bin

3

Il est vide. Mais à tout hasard

root@Debian:~# rm /var/cache/apt/archives/* -vf
'/var/cache/apt/archives/lock' supprimé
rm: impossible de supprimer '/var/cache/apt/archives/partial': est un dossier
root@Debian:~#

Le problème persiste…

4

Que dit ceci:
grep -hs '^[^#]*:' /etc/apt/s{,*/}*t

5 
root@Debian:~# grep -hs '^[^#]*:' /etc/apt/s{,*/}*t
deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free
deb http://http.debian.net/debian bullseye-updates main contrib non-free
deb-src http://http.debian.net/debian bullseye-updates main contrib non-free
deb http://security.debian.org/ bullseye-security/updates main contrib non-free
deb-src http://security.debian.org/ bullseye-security/updates main contrib non-free
root@Debian:~#
6

On va augmenter un peu la dose:
sudo rm -rf /var/cache

7

hum, désolé mais je vais pas la tenter celle-là :confused: (trop de dossiers à reconstituer)

root@Debian:~# ls /var/cache
apparmor  apt               cracklib  debconf              flashplugin-nonfree  fonts  ldconfig  man         pm-utils    private
app-info  apt-xapian-index  cups      dictionaries-common  fontconfig           fwupd  lightdm   PackageKit  postgresql  samba
root@Debian:~#
8

C’est du cache à reconstruire après reboot et upgrade bullseye.
C’est vous qui voyez… / voir tentatives plus progressives, mais je ne vois pas pourquoi ça coince après spécifiquement tentative d’upgrade à bullseye.

9

Trop de boulot et pour tout dire je ne vois pas le lien avec une erreur apt et la destruction du cache postgresql (par exemple).

Sinon j’ai eu d’autres alertes du même genre :

Erreur du busistes de paquets… 0%

sur un apt purge

et ça (qui sent pas trop bon :smirk:)

root@Debian:~# mandb -t
Erreur du bus
root@Debian:~#
10

?? Je n’ai jamais rien eu à construire/reconstruire dans ce cache. Du cache est du cache.
Je n’insiste pas, mais dans des cas zarbis d’origine non identifiée, il faut parfois des solutions zarbies.

11

Y’a des paquets qui sont pas dans la distrib de base et j’ai des préférences à garder dans ma base de données

12

Certes, mais en général on les tente en dernier recours. En attendant je vais voir si on ne me propose pas d’autres idées. Mais merci pour tes propositions.

13

Je viens d’avoir ça sur un apt upgrade

E: Erreur de lecture - read (5: Erreur d'entrée/sortie)
W: Sources disagree on hashes for supposely identical version '3.66' of 'mime-support:amd64'.
W: Sources disagree on hashes for supposely identical version '3.69' of 'mailcap:amd64'.
W: Sources disagree on hashes for supposely identical version '4.0.0' of 'media-types:amd64'.
W: Sources disagree on hashes for supposely identical version '3.0.7.33374.ds4-2' of 'firebird3.0-common:amd64'.
W: Sources disagree on hashes for supposely identical version '3.0.7.33374.ds4-2' of 'firebird3.0-common-doc:amd64'.
W: Sources disagree on hashes for supposely identical version '20200910-1' of 'fonts-urw-base35:amd64'.
W: Sources disagree on hashes for supposely identical version '4.8.0-1' of 'libgtksourceview-4-common:amd64'.
W: Sources disagree on hashes for supposely identical version '3.36.1-1' of 'gnome-weather:amd64'.
W: Sources disagree on hashes for supposely identical version '3.24.24-4+deb11u2' of 'libgtk-3-common:amd64'.
W: Sources disagree on hashes for supposely identical version '4.10.0-1' of 'manpages-fr:amd64'.
W: Sources disagree on hashes for supposely identical version '2.0.0-1' of 'python3-dnspython:amd64'.
W: Sources disagree on hashes for supposely identical version '3.16.0-1' of 'python3-louis:amd64'.
14

Petit détail (ou pas) que j’ai oublié de préciser :
Je suis en console de récupération.

Je ne sais pas si ça joue mais dans le doute je précise ce point.
Initialement, c’est sur une mise à jour de grub que le problème a commencé. Du coup je n’ai plus accès au boot « normal »

15

Ça fait en effet beaucoup de ‹ petits › détails que tu oublies, un peu trop.

16

Super ! Donc ça veut dire que tu envisages d’autres solutions dans ce contexte ?

Je patiente…

17

Pas exactement le sens non. Je préfère avoir une vue d’ensemble dans un premier temps plutôt qu’après des "tiens au fait, javais oublié de dire " x 5.
Pas d’idée là. Il faut déjà trouver l’origine d’autres problèmes précédemment cumulés.

18

Bonjour

Ca aurait été bien de commencer par là avant d’aller parler d’un souci de cache…

Essaye déjà de réparer ton grub pour commencer:

update-grub

puis tu tentes de rebooter en mode normal

19

Oui j’ai essayé ça. J’ai même fait un apt install --reinstall grub-pc grub-common qui s’est bien passé.
Il a booté normalement quelques fois puis a recommencé à planter sur le boot normal.

En fait, j’ai beaucoup d’IRQ suite à I/O error mais je ne suis pas sûr que ce soit le disque qui ait des problèmes de surface.

Je dis ça parce que si je réessaie plusieurs fois un apt update ou apt install qui sort en erreur, il finit par passer (une sorte de brute-force en essayant de passer entre les IRQ).

J’en déduis que c’est peut-être un problème de bus ou soft du disque.

Je l’ai monté sur un autre PC (pas facile d’enlever un disque sur un Compad Presario SR2029).

Pour l’instant j’ai

root@kali:~# fsck -t vxfs -n /dev/sdb3
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
Warning: skipping journal recovery because doing a read-only filesystem check.
Debian: clean, 320280/4587520 files, 2810431/18318080 blocks
root@kali:~#

Sur la partition système. Donc rien d’anormal.

Quels tests non destructifs je pourrais faire pour vérifier correctement le disque ?

20

J’ai initié un test avec badblocs

root@kali:~# badblocks -nsv /dev/sdb
Checking for bad blocks in non-destructive read-write mode
From block 0 to 244198583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 673243% done, 0:33 elapsed. (0/0/0 errors)
673253% done, 0:35 elapsed. (1/0/0 errors)

  0.27% done, 4:55 elapsed. (16/0/0 errors)
badblocks: Input/output error during test data write, block 6955009
6955009 done, 53:19 elapsed. (16/0/0 errors)

6955072
  2.97% done, 55:30 elapsed. (19/0/61 errors)

Voilà ce que j’ai pour l’instant (j’ai tronqué le résultat qui donne les numéros de blocs pour une meilleure lisibilité)

C’est la première fois que j’utilise badblocs.

Mais qu’est-ce donc que cette erreur puisqu’il n’est pas censé écrire avec l’option -n ?