Debian Debian-France Debian-Facile Debian-fr.org Debian-fr.xyz Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 07-04-2021 08:30:31

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Dépannage serveur : repartitionnement + LVM & LUKS

Bonjour à tous,

J'ai acheté deux autres disques dur.

J'ai voulu les lier aux points de montage suivant,
/home
/mnt/data

Du coup je suis passé par plusieurs opérations depuis.

Mon système LVM a changé, comment le faire prendre en compte par l'OS debian buster ?

Au démarrage de grub, j'ai les messages suivants,

Volume group "root" not found
Cannot process volume group root
cryptsetup: Waiting for encrypted source device /dev/mapper/root-root...
Volume group "root" not found
Cannot process volume group root



L'OS cherche encore les anciens points LVM de /dev/mapper/root-root_crypt.

Pourtant, j'ai bien modifié le /etc/crypttab et le /etc/fstab.

Effectué un chroot de mon système, grub-install et update grub.

Je démarre bien avec grub

Pour utiliser plusieurs disques dur, je suis passé en GPT avec partition EFI.

Avant j'avais juste le /boot sans EFI.

Une idée pour indiquer les nouveaux points de montage LVM ?

Merci

Hors ligne

#2 07-04-2021 11:25:20

raleur
Membre
Inscription : 03-10-2014

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Pas très clair tout ça...

joffrey575 a écrit :

Du coup je suis passé par plusieurs opérations depuis.
Mon système LVM a changé,


Quelles opérations ? Qu'est-ce qui a changé ? Quelle est la structure actuelle des volumes LVM/LUKS ?

joffrey575 a écrit :

L'OS cherche encore les anciens points LVM de /dev/mapper/root-root_crypt.
Pourtant, j'ai bien modifié le /etc/crypttab et le /etc/fstab.


Est-ce que tu as reconstruit l'initramfs avec update-initramfs ?


Il vaut mieux montrer que raconter.

Hors ligne

#3 07-04-2021 15:14:19

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Je suis partie de mon OS serveur prossédant,


ANCIENNE CONFIG

# <file system>                             <mount point>   <type>  <options>         <dump>  <pass>
/dev/mapper/root-root_crypt                 /               ext4    errors=remount-ro   0       1
UUID=57199c81-7bcd-4744-b9c7-8a64dfe931e2   /boot           ext4    defaults            0       2
/dev/mapper/root-data_crypt                 /mnt/my_data    ext4    defaults            0       2
/dev/mapper/root-swap_crypt                 none            swap    sw                  0       0



/etc/crypttab
root-data_crypt UUID=f3ef51a2-afd2-4ca8-9f69-e46d5dd8703a none luks,discard
root-root_crypt UUID=2079615d-7358-4963-8cb6-e0df3b1e558c none luks,discard
root-swap_crypt UUID=a6ddf7c5-a3db-4e55-ba42-2fa76cc68888 none luks,swap,discard



lsblk

NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                     8:0    0   1,8T  0 disk  
├─sda1                  8:1    0 279,4G  0 part  
├─sda2                  8:2    0 279,4G  0 part  
└─sda3                  8:3    0   1,3T  0 part  
sdb                     8:16   0   1,8T  0 disk  
├─sdb1                  8:17   0   190M  0 part  /boot
└─sdb2                  8:18   0   1,8T  0 part  
  ├─root-root         254:0    0   136G  0 lvm  
  │ └─root-root_crypt 254:1    0   136G  0 crypt /
  ├─root-swap         254:2    0   3,7G  0 lvm  
  │ └─root-swap_crypt 254:3    0   3,7G  0 crypt [SWAP]
  └─root-data         254:4    0   1,7T  0 lvm  
    └─root-data_crypt 254:5    0   1,7T  0 crypt /mnt/my_data
sdc                     8:32   0 232,9G  0 disk  
└─sdc1                  8:33   0 232,9G  0 part



---------------------------

CONFIG ACTUELLE

J'ai utilisé l'installeur de debian pour repartitionner.

Je suis passé d'un boot legacy (bios) à un EFI.

J'ai effacé le système installé par l'installeur pour y mettre l'ancien.

Grossièrement : rm system_actuel  && rsync -PahhlHx --delete system_sauvegardé system_actuel


AJUSTEMENTS DEJA EFFECTUES

/etc/fstab
# <file system>             <mount point>   <type>  <options>         <dump>  <pass>
/dev/mapper/system-system   /               ext4    errors=remount-ro   0       1
UUID=1168-0568              /boot/efi       vfat    umask=0077          0       1
/dev/mapper/home-home       /home           ext4    defaults            0       2
/dev/mapper/data-data       /mnt/my_data    ext4    defaults            0       2



/etc/crypttab
sda1_crypt UUID=54bd4915-401c-4141-80d0-11b402ce46ed none luks,discard
sdb1_crypt UUID=2464bbbd-277c-4d05-9954-cbd1ee9c4305 none luks,discard



(J'ai crypté les PV au lieu des LV, bon pas grave. Je referais plus tard si besoin.)

-----------------------------

INITRAMFS

Je n'ai pas effectué update-initramfs encore, est-ce que ça va reconstruire le LVM & LUKS au démarrage ?

Hors ligne

#4 07-04-2021 16:44:22

raleur
Membre
Inscription : 03-10-2014

Re : Dépannage serveur : repartitionnement + LVM & LUKS

joffrey575 a écrit :

Je suis passé d'un boot legacy (bios) à un EFI.


Une raison particulière à ce changement ?

joffrey575 a écrit :

J'ai crypté les PV au lieu des LV, bon pas grave


Au contraire, c'est plus simple et logique de chiffrer le PV que de chiffrer individuellement les LV qu'il contient.
Par contre il y a un détail que je ne comprends pas : apparemment il y a maintenant un VG distinct pour chaque VG. Pourquoi cela ?
Plus de swap ?

Je trouve que les noms des volumes chiffré ne sont pas bien choisis car ils font références à des noms sd* qui ne sont ni explicites ni garantis fixes. Pour moi le nommage doit être lié au contenu (comme les noms de LV), pas au contenant.

joffrey575 a écrit :

Je n'ai pas effectué update-initramfs encore, est-ce que ça va reconstruire le LVM & LUKS au démarrage ?


Ça va mettre à jour l'initramfs avec le nouveau contenu du fichier crypttab nécessaire pour ouvrir le volume chiffré contenant le système de fichiers racine.
Note que tu devrais pouvoir les ouvrir manuellement avec cryptsetup dans le shell de l'initramfs et poursuivre le démarrage.


Il vaut mieux montrer que raconter.

Hors ligne

#5 08-04-2021 09:23:18

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Pour le changement de boot legacy à EFI, c'est un conseil qu'on m'a donné.

Du coup, j'ai créé une partition EFI et une autre BOOT et après le système.

L'initiramfs m'a reglé le problème quand j'avais juste le HOME et les DATA de chiffrés.

J'ai remis un coup d'installeur debian pour chiffrer aussi le SYSTEME.

Je recopie toutes mes données sauf EFI et le BOOT créé par l'installeur debian et je ferais un update-grub et update-initramfs.

Merci

Hors ligne

#6 08-04-2021 09:59:16

raleur
Membre
Inscription : 03-10-2014

Re : Dépannage serveur : repartitionnement + LVM & LUKS

joffrey575 a écrit :

Pour le changement de boot legacy à EFI, c'est un conseil qu'on m'a donné.


Avec quel motif ?

joffrey575 a écrit :

L'initiramfs m'a reglé le problème quand j'avais juste le HOME et les DATA de chiffrés.


L'initramfs n'a pas besoin de monter home ni data. Il n'a besoin d'accéder qu'au système de fichiers racine et au swap (si utilisé pour l'hibernation).


Il vaut mieux montrer que raconter.

Hors ligne

#7 08-04-2021 10:08:14

Croutons
Membre
Distrib. : Debian10 Buster
Noyau : Linux 4.19.0-12-amd64
(G)UI : Mate
Inscription : 16-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Hello
si j'ai bien suivis il y a 3 VG
mais on aurait pu en avoir qu'un seul c'est bien ça?
est ce que cela complique pas un peu les choses pour géré l'espace disponible restant?

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

Hors ligne

#8 08-04-2021 10:33:13

raleur
Membre
Inscription : 03-10-2014

Re : Dépannage serveur : repartitionnement + LVM & LUKS

En effet cela pose la question de l'utilité de LVM dans cette configuration.
Visiblement le but n'est pas d'avoir plusieurs LV dans un même VG.
Si le but est de pouvoir étendre un LV en ajoutant un nouveau PV au VG, alors le chiffrement des PV complique les choses. Il aurait mieux valu chiffrer les LV comme avant.
Autrement, je ne vois pas l'intérêt de LVM qui rajoute une couche pour rien. Il aurait été plus simple d'utiliser directement les volumes chiffrés comme systèmes de fichiers.

Il vaut mieux montrer que raconter.

Hors ligne

#9 08-04-2021 15:20:58

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Le but est de pouvoir ajouter de l'espace supplémentaire au stockage des données.

Pour le moment, 1 PV est dedié pour 1 LV de DATA.

Si j'ai bien saisi, il vaut mieux chiffrer le LV si l'on veut par la suite ajouter un disque dur et étendre le LV ?

Dernière modification par joffrey575 (08-04-2021 15:41:58)

Hors ligne

#10 08-04-2021 15:32:42

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Depuis un live USB j'effectue les commandes suivantes,

sudo -s
mkdir /mnt/
mount /dev/system/system /mnt/

mount -o bind /dev/ /mnt/dev
mount -o bind /sys/ /mnt/sys
mount -t proc proc /mnt/proc
mount -o bind /run/ /mnt/run
# chroot pour acces au système debian
chroot /mnt
mount -a



Jusqu'ici, j'ai bien monté l'existant sur mon système debian.

J'update grub.

root@debian:/# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found initrd image: /boot/initrd.img-4.19.0-14-amd64
Found linux image: /boot/vmlinuz-4.19.0-13-amd64
grub-probe: error: cannot find a GRUB drive for /dev/sdd1.  Check your device.map.
Adding boot menu entry for EFI firmware configuration
done



Pour finir, j'effectue un initramfs.

root@debian:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-14-generic
cryptsetup: WARNING: target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' not
    found in /etc/crypttab



La target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' n'est pas trouvé alors qu'elle est présente dans le fichier /etc/crypttab.

Ou se situe le problème ? C'est le fait de monter les partitions sur le système debian à mettre à jour ?

Si j'installe Debian avec une clé ou un CD et je crypte le système '/', pas de problème la partition luks-XXX est détecté au démarrage.

Lorsque je reprends mon système serveur et que je le copie à la place de celui installé avec le live USB, la partition système luks-XXX n'est pas détecté alors que les luks-XXX du DATA et HOME sont détectées.

Hors ligne

#11 08-04-2021 15:51:10

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Je reviens à mon besoin initial.

J'ai,

HDD1 : système debian
HDD2 : home
HDD3 : mes données

En cas de besoin, j'ajoute de l'espace la ou je veux.

Dernière modification par joffrey575 (08-04-2021 15:58:23)

Hors ligne

#12 08-04-2021 19:13:40

raleur
Membre
Inscription : 03-10-2014

Re : Dépannage serveur : repartitionnement + LVM & LUKS

joffrey575 a écrit :

Si j'ai bien saisi, il vaut mieux chiffrer le LV si l'on veut par la suite ajouter un disque dur et étendre le LV ?


Ça dépend comment on gère la passphrase.
Si on chiffre les PV d'un VG, en principe il faudra taper la passphrase pour chaque PV. Fastidieux. Sauf
- si tous les PV ont la même passphrase et plymouth est installé et pas désactivé (paramètre nosplash), alors il ne sera demandé qu'une fois
- ou si la passphrase est lue dans un fichier (lui-même dans un volume chiffré ouvert précédemment) alors elle ne sera pas demandée du tout.

En revanche si on chiffre l'unique LV d'un VG et non les PV, alors il n'y a toujours qu'une seul volume chiffré (et une seule passphrase) quel que soit le nombre de PV.

On peut aussi faire un "sandwitch" LVM-LUKS-LVM. Un premier VG avec les PV non chiffrés qui contient un unique LV qui sert de conteneur LUKS dont le volume chiffré sert de PV pour un second VG qui contient un ou plusieurs LV. Ainsi il n'y a toujours qu'un seul volume chiffré quel que soit le nombre de PV et de LV.

joffrey575 a écrit :

update-initramfs: Generating /boot/initrd.img-4.19.0-14-generic


C'est quoi cette version de noyau ? On dirait un noyau Ubuntu. A ma connaissance les noyau Debian ne contiennent pas le suffixe "-generic".

joffrey575 a écrit :

La target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' n'est pas trouvé alors qu'elle est présente dans le fichier /etc/crypttab.


Vraiment ? On peut voir ? En tout cas elle n'est pas dans le fichier que tu as montré dans ton message #3.

Je me suis arraché les cheveux à comprendre d'où venait cet identifiant "luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262". J'ai charché dans dmsetup, systemd... Mais je soupçonne qu'en fait c'est le gestionnaire de fichiers que tu as dû utiliser pour ouvrir le volume chiffré qui a attribué ce nom au volume dans /dev/mapper. Et forcément, il ne correspond pas au nom défini dans crypttab.
Tu as deux options : soit tu ouvres le volume chiffré avec cryptsetup et avec le même nom que dans crypttab, soit tu ajoutes "initramfs" dans le champ des options de ce volume dans crypttab pour qu'il soit inconditionnellement ouvert par l'initramfs.


Il vaut mieux montrer que raconter.

Hors ligne

#13 11-04-2021 13:29:20

joffrey575
Membre
Distrib. : Debian Jessie et stretch
Inscription : 19-12-2016

Re : Dépannage serveur : repartitionnement + LVM & LUKS

Je suis partie sur le volume système non chiffré ni LVM pour ouvrir,

home chiffré
data chiffré et LVM pour augmenter la taille de ce point de montage par la suite.

Merci pour ta solution

Hors ligne

Pied de page des forums