# [Resolu][lvm] mise a jour, grosse cata

## zuthos

Bonjour,

Suite a une mise a jour. ET a un redemarage.

Je n'ai plus accès a mes partions lvm. Je ne sais plus quoi faire ;-(Last edited by zuthos on Tue Aug 17, 2010 8:39 pm; edited 2 times in total

----------

## anigel

Bonsoir.

En root, que renvoie la commande pvscan ?

Ensuite, si tes partitions LVM sont bien reconnues, essaies un vgscan, suivi d'un vgchange -a y. Si tout s'est bien passé, tes partitions sont de nouveau accessibles.

Par contre il va falloir déterminer pourquoi elles ont disparu. Si c'était une grosse mise à jour, et si tu utilise genkernel, pense à refaire un initrd ?

----------

## zuthos

Merci de votre réponse rapide.

Voici le résultat:

# pvscan

No matching physical volumes found

Malheureusement, ce n'est pas aussi simple

----------

## anigel

Si pvscan ne trouve pas les partitions LVM, c'est que le souci est plus important que prévu.

Que donne un fdisk -l ? Est-ce que les partitions LVM ont bien le bon type (8e de mémoire) ?

Ah aussi : penser à modifier ton premier post pour le mettreen conformité avec les conventions du forum  :Wink: .

----------

## zuthos

```

# fdisk -l /dev/sda

# fdisk /dev/sda

Unable to open  /dev/sda

```

Heu la, je sais pas trop quoi faire   :Question: 

----------

## KageBunshinNoGentoo

Tu n'aurais pas mis à jour ton noyau par la même occaz ? :p

----------

## zuthos

Bin non, je n'y est pas touché.

----------

## MadeIn94

Bonjour, j'ai peur d'être dans le même cas alors afin d'éviter de créer un nouveau je vous expose mon problème.

J'utilise depuis quelques temps une clé usb de 16 Go sur laquelle je possède deux partitions de 8Go chacune. La première est une partition FAT32, la deuxième une partition EXT4 cryptée.

Résultat de fdisk :

 *Quote:*   

> Disque /dev/sdc: 15.7 Go, 15703474176 octets
> 
> 9 têtes, 40 secteurs/piste, 85196 cylindres
> 
> Unités = cylindres de 360 * 512 = 184320 octets
> ...

 

Actuellement la partition FAT32 est utilisable correctement, je peux la monter sans problème, cependant la deuxième partition n'est plus montable.

Voici les commandes que j'utilise pour la monter :

 *Quote:*   

> cryptsetup create usb /dev/sdc2 (en root)
> 
> mount /dev/mapper/usb (en user)

 

Mon fstab :

 *Quote:*   

> /dev/mapper/usb         /home/sam/usb        ext4    user,noauto,exec                0 0

 

Lors du mount :

 *Quote:*   

> mount : type erroné de syst .de fichiers, option erronée, super bloc
> 
>         erroné sur /dev/mapper/usb, codepage ou aide manquante ou autre erreur
> 
>        Dans quelques cas certaines informations sont utiles dans syslog - essayez
> ...

 

dmesg :

 *Quote:*   

> [  526.867791] EXT4-fs (dm-0): bad geometry: block count 499437898 exceeds size of device (1916910 blocks)

 

Cet échec survient également après une récente mise à jour (hier), cependant j'étais très en retard et j'ai recompilé + de 150 packets (sûrement + de 200 avec les revdep)

Je ne sais donc pas précisément qu'est-ce qui a été mis à jour...

----------

## anigel

 *zuthos wrote:*   

> 
> 
> ```
> 
> # fdisk -l /dev/sda
> ...

 

Attention : j'avais bien demandé un simple fdisk -l, sans rien derrière comme argument. Ainsi fdisk se charge lui-même de tenter de trouver les disques (c'est au cas où on passe à la libata par exemple).

Donc, que donne un simple

```
fdisk -l
```

Par ailleurs, je me répète :

 *anigel wrote:*   

> Ah aussi : penser à modifier ton premier post pour le mettreen conformité avec les conventions du forum .

 

 :Wink: 

----------

## zuthos

Voila, premièrement toute mes excuses, je n'avais pas vu ta première demande pour le sujet du post. 

 :Embarassed: 

Ensuite, 

```

# fdisk -l

```

ne donne aucun résultat, ni message d'erreur

----------

## Poussin

euh attends, là il y a un soucis quand même ^^ Tu as bien booté sur quelque chose tout de même

fdisk -l   l'argument est un L minuscule et la commande est à exécuter en root

(au pire tu peux nous coller la sortie de 'cat /proc/partitions' )

----------

## zuthos

Bin oui, dous l'incompréhension...

Donc, voici la copie de /proc/partitions

```

# cat /proc/partitions

major  minor  #blocks name

8          0        39070080  sda

8          1        1020096    sda1 

8          2        2048287    sda2

8          3        8193150    sda3

8          4                 1   sda4

8          5          1020096  sda5

8          6          2048256  sda6

8          7        24740068  sda7

```

Voila, il s'agit d'une recopie à la main...

----------

## anigel

 *zuthos wrote:*   

> Ensuite, 
> 
> ```
> 
> # fdisk -l
> ...

 

Dans ce cas il ne reste pas beaucoup de solutions : soit ton (tes ?) disque(s) est (sont) débranché(s), soit le noyau sur lequel tu boot ne contient pas le pilote pour le chipset ou la carte contrôleur sur laquelle ce(s) disque(s) est (sont) branché(s)...

A toi de chercher maintenant  :Wink: .

----------

## GentooUser@Clubic

Si il a un initrd, c'est lui qui monte rootfs, après la partition qui contiens le / peut "disparaître" de /dev ça ne pose pas de problème.

J'ai ce problème en ce moment avec lvm-2.02.70, udev ne crée plus les périphériques correctement dans /dev/mapper, mais comme l'initrd a monté / (qui se trouve sur un volume lvm) avant, le système démarre !

À priori, si on est dans ce genre de cas, les données sont sauves. Faut essayer avec un liveCD (genre RIPLinux, ou le CD d'install d'ARCH) pour voir si tout est reconnu correctement, si c'est le cas essayer de réparer la Gentoo en commençant par reinstaller/downgrader lvm2 puis Udev.

MadeIn94 -> Déjà essaye de voir si tu as un superblock valide sur /dev/mapper/usb avec dumpe2fs, si ce n'est pas le cas et que tu as donné le bon mot de passe à cryptsetup, ça sent pas bon !

----------

## MadeIn94

Je m'empresse de tester la commande et voici le résultat :

```

dumpe2fs: The ext2 superblock is corrupt lors de la tentative d'ouverture de /dev/mapper/usb

Impossible de trouver un superbloc de système de fichiers valide.

```

Ça sent pas bon donc?   :Confused: 

Je suis tout de même à peu près sûr que le média reste valide, vu que j'ai ici deux machines, et que après la maj sur la  machine A ça ne fonctionnait plus mais encore sur la B, une fois la B mise à jour ni sur la A ni sur la B

Sinon est-ce normal qu'il me parle d'"ext2"?

Ma partition est censé être en ext4.

J'espère que ce problème est bien lié à celui de zuthos, un ami m'a dit que ça avait un rapport avec lvm, je ne voudrai pas mettre le désordre.

Merci!

PS : Je suis sûr du mot de passe, je l'ai aussi tappé en clair pour être sûr

----------

## GentooUser@Clubic

Une fois j'ai eu un problème avec encfs, en fait j'avais chiffré avec une version buggé de SSL qui "comptait" mal, du coup impossible de déchiffrer avec les suivantes.

cryptsetup se base sur les modules cryptographiques du noyau, ce genre de bug est peu probable, mais ça peut aider de revenir à une version des outils que l'on sait fonctionnelle !

Ensuite à ta place j'essayerai photorec sur /dev/mapper/usb s'il trouve des sauvegardes du superblock ou qu'il récupére des fichiers =>  partition corrompue mais correctement déchiffrée, s'il ne trouve que de la bouillie => problème au niveau du déchiffrage.

Et :

- Oui normal que dumpe2fs parle d'ext2, c'est le même outil pour toute les générations d'ext2/3/4.

- Non je ne pense pas que ce soit le même problème que zuthos dont des périphériques physiques ont disparus de /dev

- Oui lvm2 est utilisé  par cryptsetup en remplacement de device-mapper, tu peut donc essayer de downgrader lvm2 pour voir

----------

## MadeIn94

Un grand merci GentooUser@Clubic!

J'ai rétrogradé lvm2-2.02.67-r2 en lvm2-2.02.56-r2

puis j'ai pu rétrograder cryptsetup-1.1.2 en cryptsetup-1.0.6-r2 (je n'arrivais plus à compiler cette version avant de rétrograder lvm)

Ensuite j'ai directement retenté un dumpe2fs, ma tty a été floodée d'information et le mount a marché direct.

Ça me fait plaisir car les données stockée sur ce media était très sensibles, je m'empresse de faire une sauvegarde quelque part, et je pense essayer de refaire une nouvelle partition avec les nouveaux packages en notant leurs versions pour éviter de retomber sur un problème similaire ou plus grave.

Bon courage à toi zuthos pour ton problème et désolé d'avoir cybersquatté ton sujet   :Wink: 

----------

## zuthos

En fait, ma partition / n'est pas sous lvm.

Bon, je vais essayer de trouver un cd live.

Merci.

Je vous tiens au courant de la suite

----------

## guilc

 *MadeIn94 wrote:*   

> Un grand merci GentooUser@Clubic!
> 
> J'ai rétrogradé lvm2-2.02.67-r2 en lvm2-2.02.56-r2
> 
> puis j'ai pu rétrograder cryptsetup-1.1.2 en cryptsetup-1.0.6-r2 (je n'arrivais plus à compiler cette version avant de rétrograder lvm)
> ...

 

Ca n'a effectivement rien à voir, et downgrader dans ce cas est reculer pour mieux sauter...

Un peu de lecture :

 *http://code.google.com/p/cryptsetup/wiki/Cryptsetup110 wrote:*   

> 
> 
> Changes since version 1.0.7
> 
>     * IMPORTANT: the default compiled-in cipher parameters changed
> ...

 

Donc soit tu compiles avec options assurant la compatibilité, soit tu copies une version de la partition décryptée, tu upgrades, et tu recrées le volume dm-crypt from scratch

Mais le downgrad c'est vraiment que tu temporaire !

----------

## MadeIn94

Bien entendu il s'agissait d'une solution temporaire pour rapidement récupérer les données,

je vais par la suite opter pour la solution de recréer le volume dm-crypt.

Merci

----------

## zuthos

Bon, j'ai réussis à trouver un rescue CD.

J'arrive à monter mes partitions sans aucun soucis (avec le rescue CD).

Donc, toutes mes données sont la.

Par contre, je ne sais pas commet upgrader lvm et udev a partir du rescue cd??

----------

## El_Goretto

Tu regardes la doc d'installation Gentoo pour faire la même chose qu'à l'install, à savoir un chroot dans ta gentoo  :Smile: 

C'est une manip' ultra utile (et pas uniquement pour du gentoo).

----------

## zuthos

Oui, je connaissais. Je vais essayer de recompiler mon Noyau. On verra bien.

J'ai re-compiler mon noyau en enlevant l'option CONFIG_SYSFS_DEPRECATED.

Maintenant, j'ai quelque information:

```

# fdisk -l

Disk /dev/sda: 40.0 GB, 40007761920 bytes

255 heads, 63 sectors/track, 4864 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x91769176

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1               1         127     1020096   82  Linux swap / Solaris

/dev/sda2   *         128         382     2048287+  83  Linux

/dev/sda3             383        1402     8193150   83  Linux

/dev/sda4            1403        4864    27808515    5  Extended

/dev/sda5            1403        1529     1020096   83  Linux

/dev/sda6            1530        1784     2048256   83  Linux

/dev/sda7            1785        4864    24740068+  83  Linux

Disk /dev/sdb: 1994 MB, 1994292736 bytes

4 heads, 16 sectors/track, 60860 cylinders

Units = cylinders of 64 * 512 = 32768 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1   *           1       60861     1947543+   e  W95 FAT16 (LBA)

```

et

```

# lvdisplay

 --- Logical volume ---

  LV Name                /dev/mvg/var

  VG Name                mvg

  LV UUID                aGZvUy-tBjP-lT1x-U7v8-Eey3-0cpB-L4i3ZN

  LV Write Access        read/write

  LV Status              NOT available

  LV Size                3.00 GiB

  Current LE             768

  Segments               2

  Allocation             inherit

  Read ahead sectors     auto

   

  --- Logical volume ---

  LV Name                /dev/mvg/home

  VG Name                mvg

  LV UUID                6qx3VY-4VI9-TUAz-dIiV-jVUo-KWyb-1lpKIr

  LV Write Access        read/write

  LV Status              NOT available

  LV Size                11.00 GiB

  Current LE             2816

  Segments               2

  Allocation             inherit

  Read ahead sectors     auto

   

  --- Logical volume ---

  LV Name                /dev/mvg/opt

  VG Name                mvg

  LV UUID                MxjSbF-rhDF-GIxP-2hNw-1XSj-r0i8-sXazc6

  LV Write Access        read/write

  LV Status              NOT available

  LV Size                1.00 GiB

  Current LE             256

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

   

  --- Logical volume ---

  LV Name                /dev/mvg/usr

  VG Name                mvg

  LV UUID                Lgf31H-fn30-W3j1-seR2-hlFj-UxxO-glZ3oA

  LV Write Access        read/write

  LV Status              NOT available

  LV Size                13.00 GiB

  Current LE             3328

  Segments               6

  Allocation             inherit

  Read ahead sectors     auto

  
```

Toutefois, le répertoire /dev/mvg n'existe pas

j'ai vérifié, dm-mod se lance bien   :Question: 

----------

## anigel

 *zuthos wrote:*   

> J'ai re-compiler mon noyau en enlevant l'option CONFIG_SYSFS_DEPRECATED.

 

Me rappele pas exactement à quoi elle sert celle-ci ; mais si tu n'en as pas besoin, de toute façon c'est pas plus mal de l'avoir viré.

 *zuthos wrote:*   

> Maintenant, j'ai quelque information:

 

OK j'y vois un peu plus clair : déjà je me suis un peu emmêlé les pinceaux avec le copain de Clubic qui pose ses logs en plein milieu de ton thread, et du coup je ne comprenais plus rien  :Very Happy: .

fdisk renvoie qqch, donc ton disque à priori va bien, tes partitions aussi.

Si les partitions LVM ne sont pas dispo, essaye ceci :

```
pvscan

vgscan

vgchange -a y
```

Et ensuite regarde si les partitions sont de nouveau accessibles dans /dev/mvg.

----------

## zuthos

Voila,

En fait, j'ai un noyau qui avais device maper. Mais qui ne vois pas mes partitions.

Et, un autre qui vois mes partitions mais dont les modules n'était pas compilé.

J'ai donc recompiler tous cela. Mais, ça marché plus.

Pour finir, j'ai récupérer le config d'un autre ordinateur qui lui fonctionné, tous recompilé et la ça à fonctionné.

En fait, il semble que le passage d'un noyau  2.6.27 à 2.6.28 à été bénéfique.

Merci Anigel, les instructions que tu m'a demandé de taper mon révélé la source du probléme

----------

## anigel

Tant mieux...

Moi j'ai toujours rien capté en revanche. Mais bon, globalement : un problème de config noyo  :Smile: .

----------

