Fstab défaillant

Bonsoir,

J’ai installé une veille machine avec deux disques, partitionnement lvm, Devian 7 avec xfce…
Je pensais avoir tout OK, malheureusement, alors que tout semble bien fonctionner et que je m’attaquais au problème de l’hibernation qui ne fonctionnais pas, j’ai constaté les choses suivantes :
fdisk me laisse un message inquietant, dernière ligne, mais pourtant, j’accède sans difficulté à ma partition home.

[code]# fdisk -l

Disque /dev/sda : 80.0 Go, 80026361856 octets
255 têtes, 63 secteurs/piste, 9729 cylindres, total 156301488 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00008189

Périphérique Amorce Début Fin Blocs Id Système
/dev/sda1 * 2048 39063551 19530752 83 Linux
/dev/sda2 39065598 156301311 58617857 5 Étendue
/dev/sda5 39065600 41211903 1073152 82 partition d’échange Linux / Solaris
/dev/sda6 41213952 156301311 57543680 8e LVM Linux

Disque /dev/sdb : 40.0 Go, 40020664320 octets
255 têtes, 63 secteurs/piste, 4865 cylindres, total 78165360 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00058733

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdb1 2046 78163967 39080961 5 Étendue
/dev/sdb5 2048 78163967 39080960 8e LVM Linux

Disque /dev/mapper/home-home : 98.9 Go, 98939437056 octets
255 têtes, 63 secteurs/piste, 12028 cylindres, total 193241088 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00000000

Le disque /dev/mapper/home-home ne contient pas une table de partitions valable[/code]

Et ftab est tout aussi inquiétant, je n’ai que deux partition déclarées :

[code]# cat /etc/fstab

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

/ was on /dev/sda1 during installation

UUID=c948e0be-e778-407f-9c33-3ffbbf8963d6 / ext2 errors=remount-ro 0 1

swap was on /dev/sda5 during installation

UUID=8d9961e8-5220-4f8d-93e3-f79f16cd6553 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
[/code]

J’avoue ne plus très bien comprendre.

Merci de votre aide.

Regarde
$ df -hT /
et compare à
$ df -hT /home

Ne pas confondre point de la hiérarchie appelé /home et «partition /home».
/home en partition séparée n’est pas obligatoire.
fstab ne mentionne pas de montage pour /home. Il n’y aurait pas de partition home à monter. Rien d’extravagant à ne pas séparer /home.Ça implique que /home et les fichiers des utilisateurs se trouveraient sous /, en /home, en /home/$USER.

Rien d’alarmant. fdisk dérouté par les volumes physiques LVM. Voir

parted -l ou # vgdisplay …

Tu souhaiterais faire de /dev/mapper/home-home le montage /home ?
Identifie son type de système de fichiers, récupère son UUID et inscris-le en fstab.

$ ls -l /dev/disk/by-uuid/

[quote=“etxeberrizahar”]Tu souhaiterais faire de /dev/mapper/home-home le montage /home ?
Identifie son type de système de fichiers, récupère son UUID[/quote]
Pour quoi utiliser l’UUID ? Il a déjà un nom bien identifié et persistant, défini par LVM.

[quote=“PascalHambourg”][quote=“etxeberrizahar”]Tu souhaiterais faire de /dev/mapper/home-home le montage /home ?
Identifie son type de système de fichiers, récupère son UUID[/quote]
Pour quoi utiliser l’UUID ? Il a déjà un nom bien identifié et persistant, défini par LVM.[/quote]

Histoire d’être raccord avec l’existant :005

Par contre quelqu’un peu corrigé ce titre ça pique les yeux un ‘ftab’

Quel existant ? A ma connaissance, les volumes logiques LVM ou RAID logiciel n’ont jamais état identifiés par leur UUID dans fstab. Cela ne concerne que les partitions et disques parce que leurs noms de périphériques sont susceptibles de varier, ce qui n’est pas le cas des noms de volumes LVM ou RAID.

On ne parle pas de la partition /home qu’il cherche ?
Dans le cas contraire effectivement il n’y a pas besoin de l’UUID pour identifier un volume.

De toute façon comme le précise etxeberrizahar il faudrait déjà savoir où se trouve sa partition ‘home’ et ce qu’il cherche à faire.

L’UUID ne tient qu’au pli pris depuis lenny. J’utilise systématiquement les UUID en fstab sans réfléchir à faire autrement parce que «ça marche sans jamais planter fstab», voilà tout.
Je parle bien de fstab, pas de grub.
Ça a beau ne pas être orthodoxe, superflu, contraire à l’usage … j’ai pris la liberté d’identifier les LVM par leur UUID en fstab sur le canevas de

[code]

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).[/code]

Les UUID sont propres aux systèmes de fichiers.
Les LVM sont montés grâce à leurs UUID. Ça aboutit au but recherché : montages réussis.

D’après le premier message, je comprends que /home est un volume logique LVM et non une simple partition sur un disque. Il a déjà un nom de périphérique persistant, /dev/mapper/home-home, donc l’utilisation de l’UUID est superflue.

Oui. Mais LVM et le RAID logiciel utilisent aussi des UUID en interne pour identifier les volumes physiques, partitions et ensembles RAID. Donc en utilisant encore une couche d’UUID dans fstab on risque de tout mélanger. En plus les UUID ce n’est pas très parlant, donc si on peut utiliser un autre schéma de nommage persistant, il ne faut pas se gêner.

D’après le premier message, je comprends que /home est un volume logique LVM et non une simple partition sur un disque. Il a déjà un nom de périphérique persistant, /dev/mapper/home-home, donc l’utilisation de l’UUID est superflue.[/quote]

J’avais pas saisi ça comme ça :think:

Oui. Mais LVM et le RAID logiciel utilisent aussi des UUID en interne pour identifier les volumes physiques, partitions et ensembles RAID. Donc en utilisant encore une couche d’UUID dans fstab on risque de tout mélanger. En plus les UUID ce n’est pas très parlant, donc si on peut utiliser un autre schéma de nommage persistant, il ne faut pas se gêner.[/quote]

Il est vrai que l’utilisation des label est plus parlante, mais pour avoir eu à faire du redimensionnement de partition et du déplacement de volume logique les UUID m’ont servi à ne pas m’emmêler les pinceaux entre les volumes logiques nouveau et ancien et pareil pour les partions.

Après c’est affaire de goût je pense, mais après vérification mes partoches utilise systématiquement des UUID et les volumes logiques des label plus parlant.

Bonjour à tous,

Je reviens dans la discussion et je vais essayer de répondre à tous et de compléter les informations données qui n’étaient pas bien claires effectivement.

etxeberrizahar m’a mis sur la voie dès son premier message,

# df -hT / Sys. fich. Type Taille Util. Dispo Uti% Monté sur /dev/disk/by-uuid/c948e0be-e778-407f-9c33-3ffbbf8963d6 ext2 19G 8,0G 9,5G 46% /

# df -hT /home Sys. fich. Type Taille Util. Dispo Uti% Monté sur /dev/disk/by-uuid/c948e0be-e778-407f-9c33-3ffbbf8963d6 ext2 19G 8,0G 9,5G 46% /

Suite à une erreur que je n’ai pas identifié, ma partition home est montée dans la racine et non dans le volume logique que je souhaitais pour elle. Je ne m’étais effectivement pas posé la question de la différence entre le point de montage home et la partition home dans le volume logique home qui est bien décrit ici :

vgdisplay home --- Volume group --- VG Name home System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 92,14 GiB PE Size 4,00 MiB Total PE 23589 Alloc PE / Size 23589 / 92,14 GiB Free PE / Size 0 / 0 VG UUID LgDJVK-ffBp-u2lA-BhaD-n6iI-1snF-x0BYva

Pour mettre mon grain de sel dans la discussion sur les label/uuid, je ne citerais que la doc Debian

[quote]LVM snapshots can result in duplicate UUIDs and labels, so LVM logical volumes should always be identified by logical volume name (/dev/mapper/name).[/quote] Ce qui ne signifie pas que l’uuid pose problème technique, mais peut poser problème de compréhension.

Si j’ai rien loupé il me reste maintenant à déclarer mon volume logique /dev/mapper/home-home comme /home dans fstab et détruire le répertoire /home intallé dans la racine…
Je vais peut-etre finir par comprendre et y arriver…

C’est très mal exprimé. Il n’y a pas de partition home. Il y a d’une part un répertoire /home, sur lequel rien n’est monté et dont par conséquent le contenu fait partie du système de fichiers racine. Et d’autre part un volume logique (et non une partition) qui est censé être monté sur /home, mais qui ne l’est pas actuellement.

Ce que tu montres est un VG (“volume group”), pas le volume logique (LV).

Oui.

Surtout pas, puisqu’il doit servir de point de montage. Si tu voulais dire supprimer ce qu’il contient, une autre option est de déplacer son contenu dans le volume logique préalablement monté sur un point de montage temporaire.

[quote]
Si j’ai rien loupé il me reste maintenant à déclarer mon volume logique /dev/mapper/home-home comme /home dans fstab et détruire le répertoire /home intallé dans la racine…[/quote]
Avant de détruire /home, il serait plus prudent d’en préserver une copie de secours.
Nous ne savons pas ce que contient /dev/mapper/home-home. Nous ne le saurons qu’après l’avoir monté.
Avant de supprimer /home, je le renommerais et créerais un point de montage /home.

Pour mener cette opération, il te faut les droits de root et aucun processus en prise en /home.
Quitter la session d’utilisateur, basculer vers une console virtuelle (ctrl+alt+F2)
login : root
mot de passe de root

mv /home /home-ancien

mkdir /home

éditer /etc/fstab avec /dev/mapper/home-home à monter en /home
Monter le nouveau /home

mount /home

Vérifier le contenu de /home, tenter de se connecter en tant qu’utilisateur.
Si /home est vide, rapatrier le contenu de /home-ancien.

[quote]
Pour mettre mon grain de sel dans la discussion sur les label/uuid, je ne citerais que la doc Debian

[quote]LVM snapshots can result in duplicate UUIDs and labels, so LVM logical volumes should always be identified by logical volume name (/dev/mapper/name).
[/quote][/quote]
lien :
wiki.debian.org/Part-UUID#Overvi … _and_fstab

[quote]
LVM logical volumes should always be identified by logical volume name (/dev/mapper/name).[/quote]
Il apparait qu’utiliser les UUID pour référencer les LVM comme je l’ai fait jusqu’à présent n’est pas conseillable à cause des doublons potentiels. Je n’ai pas rencontré de problèmes à monter les LVM par leurs UUID parce que les UUID étaient réellement uniques chez moi,. Mes LVM ne comportaient pas de snapshots.

C’est pas bête, et tout simple. Je vote pour.

La formulation de cette phrase (“unless”) est bizarre : les deux ne sont pas contradictoires puisque le nommage des volumes LVM est persistant par nature. Nommage persistant n’est pas synonyme d’UUID.

Bonsoir,

J’aurais du attendre vos réactions avant de faire…
Mon idée était simple et pas mauvaise effectivement, mais le conseil de sauvegarder mon ancien home excellent… j’ai un nouveau home, mais les données ne sont pas un problème, il n’y avait rien, mais toutes les adaptations faites sur l’utilisateur ont disparu avec lui… tout est à refaire. Pas fondamentalement grave, mais bête.
Je sujet est réglé, merci à tous de votre aide.