Ajouter un disque à un ensemble LVM sur LUKS

2 réponses
Avatar
Olivier
--00000000000021300e057c476de9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai un nouveau syst=C3=A8me avec un disque SSD chiffr=C3=A9 avec LUKS et p=
lusieurs
disques m=C3=A9caniques inutilis=C3=A9s pour l'instant.

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2,7T 0 disk
=E2=94=94=E2=94=80sda1 8:1 0 2,7T 0 part
sdb 8:16 0 2,7T 0 disk
=E2=94=94=E2=94=80sdb1 8:17 0 2,7T 0 part
sdc 8:32 0 2,7T 0 disk
=E2=94=94=E2=94=80sdc1 8:33 0 2,7T 0 part
sdd 8:48 0 2,7T 0 disk
=E2=94=94=E2=94=80sdd1 8:49 0 2,7T 0 part
sde 8:64 0 55,9G 0 disk
=E2=94=9C=E2=94=80sde1 8:65 0 243M 0 part /boot
=E2=94=9C=E2=94=80sde2 8:66 0 1K 0 part
=E2=94=94=E2=94=80sde5 8:69 0 55,7G 0 part
=E2=94=94=E2=94=80sde5_crypt 254:1 0 55,7G 0 crypt
=E2=94=9C=E2=94=80foobar--vg-root 254:2 0 8G 0 lvm /
=E2=94=9C=E2=94=80foobar--vg-var 254:3 0 3G 0 lvm /var
=E2=94=9C=E2=94=80foobar--vg-swap_1 254:4 0 15,7G 0 lvm [SWAP]
=E2=94=9C=E2=94=80foobar--vg-tmp 254:5 0 588M 0 lvm /tmp
=E2=94=94=E2=94=80foobar--vg-home 254:6 0 28,4G 0 lvm /home
sr0 11:0 1 1024M 0 rom


Je souhaite =C3=A9tendre la partition foobar--vg-var avec la totalit=C3=A9=
de sda1
sans avoir =C3=A0 saisir au d=C3=A9marrage une deuxi=C3=A8me "phrase de pas=
se".

Comment proc=C3=A9der ?
J'ai trouv=C3=A9 [1]. qu'en penser ?

[1] https://bbs.archlinux.org/viewtopic.php?id=3D214833

Slts

--00000000000021300e057c476de9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGRpdj5Cb25qb3Vy
LDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SiYjMzk7YWkgdW4gbm91dmVhdSBzeXN0w6htZSBh
dmVjIHVuIGRpc3F1ZSBTU0QgY2hpZmZyw6kgYXZlYyBMVUtTIGV0IHBsdXNpZXVycyBkaXNxdWVz
IG3DqWNhbmlxdWVzIGludXRpbGlzw6lzIHBvdXIgbCYjMzk7aW5zdGFudC48YnI+PC9kaXY+PGRp
dj48YnI+PC9kaXY+PGRpdj4jIGxzYmxrPGJyPk5BTUXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIE1BSjpNSU4gUk3CoCBTSVpFIFJPIFRZUEXCoCBNT1VOVFBPSU5UPGJy
PnNkYcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgODowwqDC
oMKgIDDCoCAyLDdUwqAgMCBkaXNrwqAgPGJyPuKUlOKUgHNkYTHCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDg6McKgwqDCoCAwwqAgMiw3VMKgIDAgcGFydMKgIDxicj5z
ZGLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDg6MTbCoMKg
IDDCoCAyLDdUwqAgMCBkaXNrwqAgPGJyPuKUlOKUgHNkYjHCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIDg6MTfCoMKgIDDCoCAyLDdUwqAgMCBwYXJ0wqAgPGJyPnNkY8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgODozMsKgwqAgMMKg
IDIsN1TCoCAwIGRpc2vCoCA8YnI+4pSU4pSAc2RjMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgODozM8KgwqAgMMKgIDIsN1TCoCAwIHBhcnTCoCA8YnI+c2RkwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA4OjQ4wqDCoCAwwqAgMiw3
VMKgIDAgZGlza8KgIDxicj7ilJTilIBzZGQxwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCA4OjQ5wqDCoCAwwqAgMiw3VMKgIDAgcGFydMKgIDxicj5zZGXCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDg6NjTCoMKgIDAgNTUsOUfCoCAw
IGRpc2vCoCA8YnI+4pSc4pSAc2RlMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgODo2NcKgwqAgMMKgIDI0M03CoCAwIHBhcnTCoCAvYm9vdDxicj7ilJzilIBzZGUywqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA4OjY2wqDCoCAwwqDCoMKgIDFL
wqAgMCBwYXJ0wqAgPGJyPuKUlOKUgHNkZTXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIDg6NjnCoMKgIDAgNTUsN0fCoCAwIHBhcnTCoCA8YnI+wqAg4pSU4pSAc2RlNV9j
cnlwdMKgwqDCoMKgwqDCoMKgwqDCoMKgIDI1NDoxwqDCoMKgIDAgNTUsN0fCoCAwIGNyeXB0IDxi
cj7CoMKgwqAg4pSc4pSAZm9vYmFyLS12Zy1yb290wqDCoCAyNTQ6MsKgwqDCoCAwwqDCoMKgIDhH
wqAgMCBsdm3CoMKgIC88YnI+wqDCoMKgIOKUnOKUgGZvb2Jhci0tdmctdmFywqDCoMKgIDI1NDoz
wqDCoMKgIDDCoMKgwqAgM0fCoCAwIGx2bcKgwqAgL3Zhcjxicj7CoMKgwqAg4pSc4pSAZm9vYmFy
LS12Zy1zd2FwXzEgMjU0OjTCoMKgwqAgMCAxNSw3R8KgIDAgbHZtwqDCoCBbU1dBUF08YnI+wqDC
oMKgIOKUnOKUgGZvb2Jhci0tdmctdG1wwqDCoMKgIDI1NDo1wqDCoMKgIDDCoCA1ODhNwqAgMCBs
dm3CoMKgIC90bXA8YnI+wqDCoMKgIOKUlOKUgGZvb2Jhci0tdmctaG9tZcKgwqAgMjU0OjbCoMKg
wqAgMCAyOCw0R8KgIDAgbHZtwqDCoCAvaG9tZTxicj5zcjDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxMTowwqDCoMKgIDEgMTAyNE3CoCAwIHJvbSA8YnI+PC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5KZSBzb3VoYWl0ZSDDqXRlbmRy
ZSBsYSBwYXJ0aXRpb27CoCBmb29iYXItLXZnLXZhciBhdmVjIGxhIHRvdGFsaXTDqSBkZSBzZGEx
IHNhbnMgYXZvaXIgw6Agc2Fpc2lyIGF1IGTDqW1hcnJhZ2UgdW5lIGRldXhpw6htZSAmcXVvdDtw
aHJhc2UgZGUgcGFzc2UmcXVvdDsuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Db21tZW50IHBy
b2PDqWRlciA/PC9kaXY+PGRpdj5KJiMzOTthaSB0cm91dsOpIFsxXS4gcXUmIzM5O2VuIHBlbnNl
ciA/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9iYnMuYXJj
aGxpbnV4Lm9yZy92aWV3dG9waWMucGhwP2lkPTIxNDgzMyI+aHR0cHM6Ly9iYnMuYXJjaGxpbnV4
Lm9yZy92aWV3dG9waWMucGhwP2lkPTIxNDgzMzwvYT48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj5TbHRzPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pg0K
--00000000000021300e057c476de9--

2 réponses

Avatar
Pascal Hambourg
Le 05/12/2018 à 15:44, Olivier a écrit :
J'ai un nouveau système avec un disque SSD chiffré avec LUKS et plusieurs
disques mécaniques inutilisés pour l'instant.
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2,7T 0 disk
└─sda1 8:1 0 2,7T 0 part

(...)
sde 8:64 0 55,9G 0 disk
├─sde1 8:65 0 243M 0 part /boot
├─sde2 8:66 0 1K 0 part
└─sde5 8:69 0 55,7G 0 part
└─sde5_crypt 254:1 0 55,7G 0 crypt
├─foobar--vg-root 254:2 0 8G 0 lvm /
├─foobar--vg-var 254:3 0 3G 0 lvm /var
├─foobar--vg-swap_1 254:4 0 15,7G 0 lvm [SWAP]
├─foobar--vg-tmp 254:5 0 588M 0 lvm /tmp
└─foobar--vg-home 254:6 0 28,4G 0 lvm /home
sr0 11:0 1 1024M 0 rom
Je souhaite étendre la partition foobar--vg-var

C'est un volume logique, pas une partition.
avec la totalité de sda1

Si ce n'est pas indiscret, pourquoi as-tu besoin d'autant d'espace dans
/var ?
sans avoir à saisir au démarrage une deuxième "phrase de passe".

Avec sda1 chiffré, je suppose ?
Comment procéder ?

Si tu chiffres sda1 avec LUKS et ajoutes le volume chiffré comme PV au
VG foobar-vg, il y a des chances que l'initramfs cherche à l'ouvrir
puisqu'il fait partie du VG qui contient la racine et le swap. Néanmoins
il paraît que si plymouth est utilisé pour collecter une passphrase,
alors celle-ci est mise en cache et réutilisée pour tenter d'ouvrir les
volumes chiffrés suivants. Donc si les deux volumes chiffrés ont la même
passphrase, alors elle ne serait demandée qu'une fois.
Cependant, à mon avis ça n'a aucun sens d'étendre un VG et un LV sur des
supports aussi différents qu'un SSD et un disque dur. Les performances
sont trop différentes selon que la données accédée est stockée sur l'un
ou sur l'autre, et on ne choisit pas ce qui va sur l'un ou sur l'autre.
D'autre part, avec 3 Go sur SSD et 3 To sur disque dur, l'apport du SSD
est marginal. Je suggèrerais donc plutôt d'abandonner le volume logique
foobar-vg/var (l'espace libéré pourra servir à agrandir les autres LV si
besoin) et de créer un nouveau groupe de volume (ou un simple volume
chiffré s'il ne doit pas être partagé ni étendu) pour /var dans sda1.
Comme ce volume chiffré ne contiendrait pas la racine ni le swap,
l'initramfs n'aurait pas de raison de chercher à l'ouvrir et sa
passphrase pourrait être enregistrée dans un fichier sur la racine qui
est aussi chiffrée.
J'ai trouvé [1]. qu'en penser ?
[1] https://bbs.archlinux.org/viewtopic.php?id!4833

Trop long, trop confus. L'OP oublie de chiffrer le second PV, puis
chiffre le LV au lieu du PV, bref il ne sait pas où il va.
Avatar
Pascal Hambourg
Le 05/12/2018 à 21:03, Pascal Hambourg a écrit :
Si tu chiffres sda1 avec LUKS et ajoutes le volume chiffré comme PV au
VG foobar-vg, il y a des chances que l'initramfs cherche à l'ouvrir
puisqu'il fait partie du VG qui contient la racine et le swap.

J'ai testé et c'est bien ce qui se passe.
il paraît que si plymouth est utilisé pour collecter une passphrase,
alors celle-ci est mise en cache et réutilisée pour tenter d'ouvrir les
volumes chiffrés suivants. Donc si les deux volumes chiffrés ont la même
passphrase, alors elle ne serait demandée qu'une fois.

Ce n'est pas ce qui se passe, la passphrase est demandée pour chaque PV.
Il y a peut-être un paramétrage à mettre en place. Je ne retrouve pas la
discussion où j'avais lu cette information.