Bonjour,
(Système cassé: Squeeze)
- mon système est cassé: impossible de monter la partition LVM2 xfs contenant /var (à partir d’un autre système, Wheezy)
Le message de mount est:
j’ai essayé
qui renvoi aussi une erreur:
[quote]ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption – please attempt a mount of the filesystem before doing this.[/quote]
Si j’ai bien compris ce message, il est conseillé de faire xfs_repair -L qui détruira le log et peut causer une corruption, autrement dit, un quitte ou double (en aveugle pour moi !): soit ça répare, soit ça casse la possibilité de réparer.
J’ai donc limité mon intervention à essayer de comprendre (en vain):
en faisant: #xfs_repair -n /dev/mapper/VG_tout-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
agf_freeblks 83808, counted 83791 in ag 3
agi unlinked bucket 40 is 232 in ag 3 (inode=25166056)
sb_ifree 6501, counted 6457
sb_fdblocks 1307638, counted 1293036
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
7f6b32eaf700: Badness in key lookup (length)
bp=(bno 7323760, len 16384 bytes) key=(bno 7323760, len 8192 bytes)
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 1
- agno = 3
- agno = 4
- agno = 5
- agno = 0
- agno = 6
- agno = 8
- agno = 2
- agno = 7
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
disconnected inode 25166056, would move to lost+found
Phase 7 - verify link counts...
would have reset inode 25166056 nlinks from 0 to 1
No modify flag set, skipping filesystem flush and exiting
d’où je crois seulement comprendre qu’un inode devrait être supprimé (déplacé vers lost+found).
Deuxièmes données du problème:
L’utilitaire de disque de Gnome3 reconnait le RAID0 sur lequel est installé le Groupe de volumes (VG_tout) qui contient 4 volumes logiques, dont 3 sont montés correctement, le 4e étant celui dédié à /var.
Mais en lançant la «Vérification de l’ensemble Raid» de l’utilitaire, j’obtiens le message d’information suivant:
[quote]Une erreur est apparue pendant l’exécution d’une opération sur «Ensemble RAID-0 2,0 TB» …: l’opération a échoué.
Détails:
Error checking array: helper exited with exit code 1: device /dev/md0 is not idle[/quote]
La cause probable est dans une première réparation, apparemment réussie, grace à une aise patiente, persistante de PascalHambourg, que vous pourrez trouver ici: raid0-en-cours-formatage-funeste-t51666.html?hilit=RAID.
Peu avant une panne physique (démarrage aléatoire),j’avais pu retrouver un Squeeze apparemment fonctionnel en utilisant un LVM_miroir pour chaque volume logique (je ne l’avais fait auparavant que pour /home)
La panne qui est survenue ensuite était physique, due à un important empoussiérage, mais j’avais tout de même réussi à installer Wheezy (sur un autre disque interne).
Le dépoussiérage ayant eu lieu, Wheezy tourne normalement, mais toujours pas Squeeze, à cause de ce /var inaccessible.
Ouf, je crois avoir dit l’essentiel.
ANNEXE
Pour les précisions:
1) Squeeze est ainsi construit:
« / » sur /sdc1 (ext4)
« /boot » sur /sdc2 (ext4)
(ces choix car j’avais des inquiétudes sur le démarrage direct en LVM)
Le reste en xfs, sur le groupe de volume VG_tout, groupe unique sur le RAID-0 (/dev/md0) assemblant /dev/sdc4 et /dev/sdf4:
« /home » sur /dev/mapper/VG_tout-home
« /usr » sur/dev/mapper/VG_tout-usr
« /usr/local » sur /dev/mapper/VG_tout-usr-var
« /var » sur /dev/mapper/VG_tout-var
- lvs -a -o +devices /dev/VG_tout renvoie:
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
home VG_tout mwi-aom- 1,46t home_mlog 100,00 home_mimage_0(0),home_mimage_1(0)
[home_mimage_0] VG_tout iwi-aom- 1,46t /dev/sdd1(0)
[home_mimage_1] VG_tout iwi-aom- 1,46t /dev/md0(0)
[home_mlog] VG_tout lwi-aom- 4,00m /dev/sdd2(0)
usr VG_tout mwi-aom- 12,00g usr_mlog 100,00 usr_mimage_0(0),usr_mimage_1(0)
usr_local VG_tout mwi-aom- 1,86g usr_local_mlog 100,00 usr_local_mimage_0(0),usr_local_mimage_1(0)
[usr_local_mimage_0] VG_tout iwi-aom- 1,86g /dev/sdd1(386560)
[usr_local_mimage_1] VG_tout iwi-aom- 1,86g /dev/sdd2(3)
[usr_local_mlog] VG_tout lwi-aom- 4,00m /dev/md0(389120)
[usr_mimage_0] VG_tout iwi-aom- 12,00g /dev/sdd1(384000)
[usr_mimage_0] VG_tout iwi-aom- 12,00g /dev/sdd1(389596)
[usr_mimage_1] VG_tout iwi-aom- 12,00g /dev/md0(386560)
[usr_mimage_1] VG_tout iwi-aom- 12,00g /dev/md0(389121)
[usr_mlog] VG_tout lwi-aom- 4,00m /dev/sdd2(2)
var VG_tout mwi-a-m- 10,00g var_mlog 100,00 var_mimage_0(0),var_mimage_1(0)
[var_mimage_0] VG_tout iwi-aom- 10,00g /dev/sdd1(387036)
[var_mimage_1] VG_tout iwi-aom- 10,00g /dev/md0(384000)
[var_mlog] VG_tout lwi-aom- 4,00m /dev/sdd2(1)
- J’avais déjà oublié: peut-être y-a-t il un rapport avec ce problème: une bizarrerie dans l’installation de Wheezy (le système à partir duquel je tente la réparation: la bizarrerie est décrite ici: gnome3-utilitaire-de-disques-incoherences-t52380.html
Est-ce qu’une réparation est possible, et si c’est la cas, est-ce qu’elle est accessible à l’éternel newbie que je m’entête à rester, bref, est-ce que cela vaut le coup de tenter cette réparation, et pour vous, de m’y aider ?
Il me semble avoir lu, il y a longtemps une page web concernant la réparation d’une partition /var cassée, ce qui serait une voie possible de réparation.
Par ailleurs, cet état «non montable» d’une partition et ce terme de «nettoyage» du messge de mount me laisse -une fois de plus- perplexe.
Merci pour votre patience à m’avoir lu.