Rsync erreur d'allocation mémoire et pertes de commandes bash

Support Debian
#1

Bonjour,

Après des mois de bon fonctionnement, lors de la sauvegarde vers le
disque dur, avec un script utilisant rsync ,
après une vingtaine de lignes, j’ai des centaines de lignes d’erreurs du
type :

rsync read error mapping "home/knoppix… " Input/Output error (5) …
rsync readlink_stat …cannot allocate memory (12) …

De plus, je perd d’innombrables commandes bash, comme dmesg, halt,
reboot …:“command not found”

Après mise hors tension brutale, aucune commande de coupure propre ne
fonctionnant, le système repart correctement.

La RAM serait en cause ?

$ cat /proc/meminfo donne:

(…)
HardwareCorrupted: 0 kB

(…)

Un dépassement de l’allocation mémoire pour rsync ?

Distribution
Linux Microknoppix 4.2.2 (Debian Jessie stable mais avec des dépôts
testing et unstable)

Cordialement.

#2

Cela ressemble à des erreurs disques. Je vous suggère de sauvegarder ce qui peut l’être sur un autre support (si ce n’est déjà fait) et de lancer

sudo smartctl -a /dev/sdX

pour confirmer cette hypothèse.

Si, par malheur c’est effectivement la mémoire RAM qui est défectueuse j’ai bien peur que la solution la plus simple soit le remplacement de la machine :unamused:

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

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

« L’arbre tombe toujours du côté où il penche. »
Proverbe français

#3

Merci.

OK, en fait mon “disque” est une mémoire USB utilisée en live avec knoppix 76 et une partie cryptée persistante.

Donc ce serait cette mémoire Flash qui serait défectueuse ?

D’après le man :
smartctl controls the Self-Monitoring, Analysis and Reporting Technology (SMART) system built into most ATA/SATA and SCSI/SAS hard drives and
solid-state drives. The purpose of SMART is to monitor the reliability of the hard drive and predict drive failures, and to carry out different
types of drive self-tests.
Donc smartctl affiche les défaut éventuels des DDURS y compris les mémoires flash .

$ sudo smartctl -a /dev/sdb1
smartctl 6.4 2014-10-07 r4002 [i686-linux-4.2.2] (local build)
Copyright © 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor: Kingston
Product: DataTraveler 3.0
Revision: PMAP
Compliance: SPC-4
User Capacity: 31 474 057 216 bytes [31,4 GB]
Logical block size: 512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0

Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.

Donc des erreurs ou il faut que la partition soit démontée pour le test ?

Comment tester la RAM ?

#4

En toute rigueur smartctl s’applique à un disque entier, pas une partition.

Les clés USB ne supportent pas SMART. Au mieux tu peux utiliser badblocks pour rechercher les blocs défectueux.

Pour tester la RAM, on peut utiliser memtest86, memtest86+ ou memtester.

#5

Bon jour,

excusez ma réponse tardive.

Effectivement smartctl ne peut tester une mémoire USB .

J’ai utilisé e2fschk, car le man de badblock le recommande :

Pour la mémoire, je ne peux installer aucun logiciel par apt-get pour causes de dépendances non satisfaites.
Je vais voir si je l’ai sur un CD, sinon :

$ cat /proc/meminfo donne:
(…)
HardwareCorrupted: 0 kB
(…)
Test de la partition1 de knoppix76_USB_King4_32Go
$ e2fsck -c /dev/sdc1
e2fsck 1.43-WIP (15-Mar-2016)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d’utiliser les blocs de sauvetage…
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d’ouverture de /dev/sdc1

Le superbloc n’a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu’il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d’exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>

/dev/sdc1 contient un système de fichiers vfat étiqueté « KNOPPIX »

#6

Si, mais pas les clés USB, dont le contrôleur intégré est trop rudimentaire pour supporter SMART contrairement à celui des disques durs ou SSD.

Tu as dû mal comprendre la page de manuel. Elle ne recommande d’utiliser e2fsck -c que si le but est de fournir la sortie de badblocks à e2fsck. Ce n’est pas le cas ici. On veut juste vérifier la clé.

L’utilisation d’e2fsck, qui ne gère que les formats ext2/3/4, est d’autant moins pertinente.

#7

Merci, pascal. là c’est clair.
En fait, moi j’appelle mémoire USB toute mémoire qui communique en USB . Le terme Clé qui n’ouvre rien… :smile:

Oui, je viens de relire. Il me faut bien deux fois en anglais.

Donc pour la mémoire USB 32Go live avec knoppix76 (non montée) :

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdc1 * 2048 9349119 9347072 4,5G c W95 FAT32 (LBA)
/dev/sdc2 9349120 61472767 52123648 24,9G 83 Linux

$ badblocks /dev/sdc
Ne donne rien . Donc, à priori pas de Blocs défectueux ?

Je vais essayer les options -sv

Pourtant, le même type de mémoire USB Kingston DataTraveler 32Go qui est un clone(dd if=xx of=yy ) de la précédente avant qu’elle ne présente des problèmes, fonctionne bien sur la même machine, toujours en USB live.

Je vais essayer de cloner en sens inverse, pour voir .

#8

badblocks doit être exécuté en tant que root, à moins que l’utilisateur courant soit dans le groupe “disk”.

#9

A priori, l’utilisateur knoppix est bien dans le groupe disk:

$ cat /etc/group | grep knoppix
disk:x:6:knoppix,backup

La sortie de badblocks (celà prend autour de 20’ tout de même):

$ badblocks -sv /dev/sdc
Vérification des blocs 0 à 30736383
Vérification des blocs défectueux (test en mode lecture seule) : complété
Passe complétée, 0 blocs défectueux repérés. (0/0/0 erreurs)

#10

Et en plus, avec ces lectures et écritures à répétition vous la fatiguez cette mémoire USB :slight_smile:

Les messages d’erreurs inquiétants du message #1 sont-ils toujours là ?

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

F. Petitjean
« L’arbre tombe toujours du côté où il penche. »
Proverbe français

#11

Le test par défaut de badblocks est en lecture seule, ce qui n’use pas significativement la mémoire flash.

#12

Oui, malheureusement. Point de Miracle .

Là je travaille avec une mémoire USB de même type Kingston DataTraveler 32Go qui est un clone(dd if=xx of=yy ) de la précédente avant qu’elle ne présente des problèmes,
Elle fonctionne bien sur la même machine, toujours en USB live, espérons qu’elle ne déraille pas comme la précédente .

Le problème est que je ne vois pas la cause. Seule la mémoire USB change, et elle ne présente pourtant pas de blocs défectueux.

La knoppix76 vient avec Jessie et des dépôt Testing et unstable. J’ai d’ailleurs des problèmes de “dépendances insatisfaites” .
Est-ce ce problème peut aussi causer ces présentes erreurs :
d’entrée sortie,
d’allocation mémoire
de disparition d’une foule de commande bash
de fichiers qui passent brusquement en lecture seule, alors qu’un ls -l les affichent avec des droits en 700 ???

Cordialement.

#13

En aucun cas.
Ces erreurs en chaîne me font penser à une situation où c’est l’ensemble du système de système de fichiers qui est inaccessible, parce que le disque ne répond plus.

On ne peut pas non plus exclure que cela soit causé par un épuisement de la mémoire disponible, notamment dans le cas d’un système live.

#14

Bonsoir,

J’ai déja eu un soucis de ce genre avec rsync sur un disque dur externe usb :
Des messages d’erreurs du même type, puis arrêt du “rsync”.
Le fait de changer de cable usb a résolu le problème.

Avec un clef usb, pas de soucis de cable…

Tu devrais essayer de faire une image de ta clef via “dd” sur un disque dur.
La commande dd affiche des messages d’erreurs en cas de soucis éventuel de lecture sur la source ou d’ écriture vers la destination.

#15

J’ai des situations ou ça se fige surtout sur mon ordianteur portable . Très rarement sur un fixe .
Cas avec libreoffice et Beaucoup d’onglets iceweasel , des logiciels de calcul et de mesure …

On ne peut pas non plus exclure que cela soit causé par un épuisement de la mémoire disponible, notamment dans le cas d’un système live.

Je surveille avec htop, et la mémoire est en dessous de sa capacité; Mais est-ce que des pointes font planter …?

#16

Je fais ça régulièrement entre 2 mémoire USB du même type 32Go , par sécurité.
Aucun message d’erreur affiché.

#17

Au fait, la mémoire USB live knoppix comporte une partie persistante cryptée.
C’est là qu’on conserve tout ce que l’on fait, les logiciels que l’on installe…

Système de base en fat sur partition 1 et partition cryptée personalisée sur la 2 :
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 * 2048 9349119 9347072 4,5G c W95 FAT32 (LBA)
/dev/sdb2 9349120 61472767 52123648 24,9G 83 Linux

Au boot, il demande le mdp pour la partition cryptée.

Un problème de décryptage ?

#18

Je ne suis pas un as de dd, mais tu dois pouvoir créer une image iso de ta clef sur un disque dur, pour pouvoir la restaurer par la suite.

Tu pourrais ainsi faire davantage de tests sur ta clef, comme un formatage de bas niveau avec dd…
Si par la suite ta clef est toujours défaillante, pourquoi ne pas envisager un éventuel SAV Kingston.

Je ne suis pas un as non plus avec les partitions cryptées, mais tu dois pouvoir monter ta partition cryptée sur un PC, et faire le “rsync” via le système du PC et non via celui du système live.

C’est un système à problème , tu devrais peut être sauvegarder tes données et essayer de faire plus propre avec une nouvelle installation. Ce qui peut être plus rapide que de corriger ces problèmes.

#19

dd ne fait pas de formatage de bas niveau.

#20

A priori, je ne peux rien faire sur la partition cryptée, à part la cloner . Sinon, il faut être dessus avec le mdp…
C’est l’intérêt et l’inconvénient.

J’ai cloné la knoppix76 de la mémoire USB de sauvegarde et la mémoire USB avec la Knoppix76 défectueuse semble fonctionnelle. C’est l’intérêt du clonage, c’est la copie bit à bit .
Maintenant, je suis prudent, les erreurs viennent plus tard et s’accumulent rapidement. Comme si la distribution se dégradait avec l’usage.

Je me demande justement si le fait d’avoir des dépôts unstable et testing, ne la rend pas instable ?

Il copie bit à bit tout ce qu’il trouve sur l’input file , non ?

Je vais essayer de cloner une sauvegarde de la mémoire USB avec Knoppix76 _32Go, sur une partition du DDUR de 32Go.

A priori les mémoires USB n’ont pas de blocs défectueux.
Il me reste à trouver memtest86+ sur un CD…, pour tester la RAM .

Je viens de voir aussi que ma session graphique de la Knoppix72 sur mon DDUR est figée.
Je l’utilisait pour cloner et dépanner. J’ai du faire CtrlAltF1 vers le terminal.

Je vais probablement mettre la debian stable sur le DDUR et voir si on peut revenir à une debian stable sur les mémoires USB knoppix76 . Mais ce sera pour un autre fil.

Par contre, un virus ne pourrait pas expliquer tous ces problèmes ? Un virus qui altèrerait les fichiers systèmes ?