[Résolu] Repartitionnement DD chiffré Debian

raleur · 20-08-2016 19:59:31

Tu fais ça dans quel environnement ?
/proc est monté ?

Abuishaq · 20-08-2016 20:34:41

raleur a écrit :

le mode "rescue" de l'installateur Debian que tu peux donc utiliser (par contre les pages de manuel ne sont pas disponibles, en cas de besoin il faudra avoir une autre poste à côté ou avoir noté les options nécessaires avant). Ça commence comme l'installation mais à un moment il te demandera la passphrase pour ouvrir le volume chiffré, activera les LV, affichera la liste des partitions et volumes détectés et te demandera lequel monter comme racine. Au lieu d'en choisir un, bascule dans un des shells accessibles par Ctrl+Alt+F2 ou F3 pour exécuter tes commandes.

J'ai utilisé ce mode avec mon CD Debian et j'ai (essayé?) commencé les étapes.

raleur a écrit :

/proc est monté ?

Je ne sais pas à quoi correspond /proc, je ne saurai pas te dire..
Si je dois commencer par démonté /proc, je n'ai qu'à l'écrire sans rien d'autre ou quel est le chemin habituel ?

raleur · 21-08-2016 11:28:12

Si tu es dans le shell de la console n° 2 ou 3 (fond noir) de l'installateur en mode rescue après la détection des volumes, /proc est monté, les LV sont activés et aucun volume du disque n'est monté donc ces deux commandes sont inutiles. Tu peux vérifier ce qui est monté avec la commande "mount". Si tu as une erreur concernant /proc/mounts, cela signifie que tu as fait quelque chose de travers. Il doit y avoir des fichiers et répertoires dans /proc et /sys.

Sinon tu peux les monter à la main avec

mount -t proc proc /proc

mount -t sysfs sysfs /sys 

mais quelque chose n'est pas normal.

Dernière modification par raleur (21-08-2016 11:29:52)

Abuishaq · 21-08-2016 17:56:15

De quelle genre d'erreur veux-tu parler, au niveau des commandes lors du démarrage de la procédure de redimensionnement ou alors au niveau de mon système ?
Je vais tester avec ces commandes, merci. Mais je dois t'avouer que

raleur a écrit :

mais quelque chose n'est pas normal

ça me fait un peu flipper

raleur · 22-08-2016 10:19:20

Je n'ai pas parlé d'erreur. Raconte plutôt tout ce que tu as fait depuis le démarrage de l'installateur jusqu'au moment où tu as eu ces messages.
Parce que les "j'ai fait comme tu m'as dit", je connais : quand on creuse on se rend compte qu'en fait des étapes ont été oubliées, ajoutées ou modifiées.

Abuishaq · 10-09-2016 22:00:32

Me revoila, je vais m'y mettre dur dur car ça devient urgent, j'ai pas trop eu le temps en ce moment.

Voici déjà pour commencer ce que me met la commande "mount":

# mount

rootfs on / type rootfs (rw, size=8107064k,nr_inodes=1012304)

none on /run type tmpfs (rw,nosuid,relatime,size=810708k,mode=755)

none on /proc type proc (rw,relatime)

none on /sys type sysfs (rw,relatime)

devtmps on /dev type devtmpfs (rw,relatime,size=4049224k,nr_inodes=1012306,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

/dev/sr0 on /cdrom type iso9660 (ro,relatime)

Pour le reste :

# cryptsetup luksOpen /dev/sda5 sda5_crypt

Device sda5_crypt already exists

# lvchange -ay /dev/cebolla-vg/root

# umount /dev/cebolla-vg/root

umount: can't umount /dev/cebolla-vg/root: invalid argument

Si je teste ça:

# umount -a /dev/cebolla-vg/root

umount: can't umount /dev/pts: Device or resource busy

umount: can't umount /dev: Device or resource busy

umount: can't umount /run: Device or resource busy

umount: can't umount /: Device or resource busy

Je ne sais pas où j'ai bugué ?

raleur · 11-09-2016 09:36:18

Bon, la commande mount fonctionne normalement maintenant.
Le volume chiffré est déjà ouvert, donc il est normal que l'ouverture échoue. Les volumes logiques LVM sont activés. Le volume logique n'est pas monté, donc il est normal que le démontage échoue. Jusqu'ici tout est nominal.

Par contre, quant à ta dernier commande, l'option -a de mount sert à démonter tous les systèmes de fichiers montés. Ce n'est évidemment pas ce que tu veux. Il y a une erreur pour ceux qui sont en cours d'utilisation, mais les autres (/proc, /sys...) ont dû être démontés et c'est à partir de là que la commande mount/umount ne fonctionne plus puisqu'elle a besoin de /proc/mounts.

Avec tout ça, j'ai oublié quel est le problème initial, je vais devoir relire le début de la discussion.

Dernière modification par raleur (11-09-2016 09:39:21)

Abuishaq · 11-09-2016 14:12:56

raleur a écrit :

Par contre, quant à ta dernier commande, l'option -a de mount sert à démonter tous les systèmes de fichiers montés. Ce n'est évidemment pas ce que tu veux.

Ok, en fait j'ai voulu tester une commande qui forcerait un peu l'action comme ça ne passait pas..

Alors justement j'ai lancé ces deux commandes

mount -t proc proc /proc

mount -t sysfs sysfs /sys 

Il me semble que ça n'avait pas fonctionné, j'aurai du te copier les résultats..
Donc si j'ai bien compris, la commande "mount" a besoin de "proc"pour fonctionner ? Donc problème étant donné que proc ne fonctionne pas/n'est pas lancé.

Voila le premier soucis rencontré : https://debian-facile.org/viewtopic.php … 39#p187739

Merci pour ta patience

raleur · 11-09-2016 16:08:23

mount a besoin de /proc (car /etc/mtab est un lien symbolique pointant vers /proc/mounts) pour afficher les montages, et umount en a besoin pour démonter un périphérique. Par contre on peut monter /proc lorsqu'il n'est pas monté. Je ne vois pas pourquoi les montages de /proc et /sys échoueraient. Tu aurais dû noter le résultat des commandes.

Abuishaq · 11-09-2016 21:18:25

Bon, j'ai passé les premières commandes inutiles et j'ai commencé directement par monter proc mais ça n'a pas fonctionné : "mount: mouting proc on /proc failed: Device or resource busy" mais pas grave, j'ai fait pareil pour /sys et ça a fonctionné ! Donc j'ai continué les étapes, j'ai redimensionné /root à 499G et son lv à 500G. Je fais également la copie de l'UUID.

J'arrive maintenant à ces commandes ou je reste bloqué :

lvremove /dev/cebolla-vg/swap_1

Logical volume cebolla-vg/swap_1 contains a filesystem in use

lvchange -an /dev/cebolla-vg/root

Logical volume cebolla-vg/root contains a filesystem in use

pvresize --setphysicalvolumesize 517G /dev/mapper/sda5_crypt

/dev/mapper/sda5_crypt: cannot resize to 132351 extents as later ones are allocated

Bon j'ai fait le foufou, j'ai essayer ces commandes malgré que la première n'a pas voulu fonctionner. La je sèche, ça a encore un rapport avec le fait qu'ils soient montés (swap_1 et root) ? Je ne pense pas sinon je n'aurais pas pu modifier la taille de /root

Bon on a déjà fait quelques pas en avant, c'est déjà bien

(On peut donc bien voir que lv root a bien été modifié à 500G)

lsblk

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT

sda                        8:0    0 931,5G  0 disk  

├─sda1                     8:1    0   243M  0 part  /boot

├─sda2                     8:2    0     1K  0 part  

└─sda5                     8:5    0 931,3G  0 part  

  └─sda5_crypt           254:0    0 931,3G  0 crypt 

    ├─cebolla--vg-root   254:1    0   500G  0 lvm   /

    └─cebolla--vg-swap_1 254:2    0    16G  0 lvm   [SWAP]

sr0                       11:0    1   3,7G  0 rom   /media/cdrom0

raleur · 12-09-2016 08:56:28

Là, tu as visiblement démarré le système installé puisqu'on voit que le LV root est monté sur / et le swap est actif, donc c'est normal que tu ne puisses pas supprimer ni désactiver ces LV. Tu as bien redimensionné le système de fichiers du LV root avant de réduire le LV ? Cela, tu n'as pas pu le faire s'il était monté. Donc si tu l'as fait, c'était depuis un autre système. Si tu as oublié, ne touche plus à rien et agrandis le LV root à sa taille initiale.

Abuishaq · 12-09-2016 10:07:49

La commande 'lsblk' a été entrée une fois le système lancé, juste pour confirmé que j'avais bien modifié root, j'aurai du te préciser, désolé.

J'ai bien suivi les commandes et bien réduit root avant son lv, voila la commande exacte que j'avais tapé :

e2fsck -f /dev/cebolla-vg/root

resize2fs -p /dev/cebolla-vg/root 499G

#La modification a duré environ 5min

lvresize -L 500G /dev/cebolla-vg/root

raleur · 12-09-2016 10:17:19

Depuis le système installé tu peux désactiver le swap avec "swapoff -a". Tu devrais ensuite pouvoir supprimer le LV swap_1 et réduire le PV. Tu peux recréer un LV swap_1 dans la foulée et l'initialiser avec le même UUID que l'ancien sans attendre.

Tu n'es peut-être pas obligé de désactiver le volume chiffré (et donc les LV, donc de démarrer avec un autre système) pour réduire la partition chiffrée. Par contre il faudra redémarrer pour que la nouvelle taille soit prise en compte.

Abuishaq · 12-09-2016 12:22:46

D'acc', je test plus tard dans la journée quand je serais au calme.

Juste pour être sûr, pour remettre le même UUID que l'ancien swap, après avoir tapé cette commande hier "blkid /dev/vg/swap | sed -e 's/.* UUID="//' -e 's/".*//' > uuid.txt", je n'ai plus maintenant qu'à continuer à partir d'ici :

raleur a écrit :

- enregistrer l'UUID d'un volume /dev/vg/swap dans le fichier uuid.txt (respecter les espaces) et vérifier :
blkid /dev/vg/swap | sed -e 's/.* UUID="//' -e 's/".*//' > uuid.txt
cat uuid.txt

- supprimer un LV vg/swap :
lvremove /dev/vg/swap

- désactiver (rendre non disponible) un LV vg/root :
lvchange -an /dev/vg/root

- redimensionner un volume physique dans /dev/mapper/sdXN_crypt à <N> Gio :
pvresize --setphysicalvolumesize <N>G /dev/mapper/sdXN_crypt

- fermer un volume chiffré :
cryptsetup luksClose sdXN_crypt

- redimensionner une partition /dev/sdX<N> à <L> Gio :
parted /dev/sdX resizepart <N> <L>Gi

- ouvrir un volume chiffré stocké sur /dev/sdXN :
cryptsetup luksOpen /dev/sdXN sdXN_crypt

- ajuster la taille d'un PV dans /dev/mapper/sdXN_crypt :
pvresize /dev/mapper/sdXN_crypt

- activer un volume logique LVM vg/root :
lvchange -ay /dev/vg/root

-ajuster la taille d'un système de fichier ext2/3/4 dans /dev/vg/root :
resize2fs -p /dev/vg/root

- créer un LV vg/swap de <N> Gio :
lvcreate -L <N>G -n vg/swap

- créer un swap dans /dev/vg/swap avec l'UUID enregistré dans le fichier uuid.txt :
mkswap -U $(cat uuid.txt) /dev/vg/swap

Et pour la dernière commande, je la tape telle qu'elle ?

raleur · 12-09-2016 12:30:41

Il faut ajuster les noms des VG et LV.
Attention : ce que tu as cité n'était pas une séquence d'actions mais une démonstration de la syntaxe des différentes commandes, vaguement ordonnées.

Abuishaq · 12-09-2016 21:20:41

raleur a écrit :

Il faut ajuster les noms des VG et LV.
Attention : ce que tu as cité n'était pas une séquence d'actions mais une démonstration de la syntaxe des différentes commandes, vaguement ordonnées.

Oui pas de soucis, sinon j'y serais même pas arrivé jusque là déjà.

Bon, voila j'y suis j'ai presque tout modifié.. Seul hic, le volume chiffré ne semble pas vouloir changer, il m'écrit que l'opération a fonctionné mais lorsque je regarde avec la commande lsblk, il n'a pas réduit.. Je n'ose pas redémarrer la machine.. Le reste des commandes ont fonctionné, je te laisse ce que j'ai tapé au cas ou:

root@cebolla:/home/abu# swapoff -a

root@cebolla:/home/abu# lvremove /dev/cebolla-vg/swap_1 

Do you really want to remove active logical volume swap_1? [y/n]: y

  Logical volume "swap_1" successfully removed

root@cebolla:/home/abu# pvresize --setphysicalvolumesize 517G /dev/mapper/sda5_crypt 

  Physical volume "/dev/mapper/sda5_crypt" changed

  1 physical volume(s) resized / 0 physical volume(s) not resized

root@cebolla:/home/abu# parted /dev/sda resizepart 5 557G

Warning: Shrinking a partition can cause data loss, are you sure you want to

continue?

Yes/No? y                                                                 

Information: You may need to update /etc/fstab.

root@cebolla:/home/abu# pvresize /dev/mapper/sda5_crypt 

  /dev/mapper/sda5_crypt: read failed after 0 of 4096 at 999945076736: Erreur d'entrée/sortie

  /dev/mapper/sda5_crypt: read failed after 0 of 4096 at 999945134080: Erreur d'entrée/sortie

  Physical volume "/dev/mapper/sda5_crypt" changed

  1 physical volume(s) resized / 0 physical volume(s) not resized

root@cebolla:/home/abu# resize2fs -p /dev/cebolla-vg/root 

resize2fs 1.42.12 (29-Aug-2014)

Le système de fichiers de /dev/cebolla-vg/root est monté sur / ; le changement de taille doit être effectué en ligne

old_desc_blocks = 32, new_desc_blocks = 32

Le système de fichiers sur /dev/cebolla-vg/root a maintenant une taille de 131072000 blocs (4k).

root@cebolla:/home/abu# lvcreate -L 16G -n cebolla-vg/swap

  /dev/mapper/sda5_crypt: read failed after 0 of 4096 at 999945076736: Erreur d'entrée/sortie

  /dev/mapper/sda5_crypt: read failed after 0 of 4096 at 999945134080: Erreur d'entrée/sortie

  Logical volume "swap" created

root@cebolla:/home/abu# mkswap -U $(cat uuid.txt) /dev/cebolla-vg/swap

Configure l'espace d'échange (swap) en version 1, taille = 16777212 Kio

pas d'étiquette, UUID=505abc85-fdb7-4a57-b3ea-6a8571b6f967

lsblk

NAME                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT

sda                      8:0    0 931,5G  0 disk  

├─sda1                   8:1    0   243M  0 part  /boot

└─sda5                   8:5    0 518,5G  0 part  

  └─sda5_crypt         254:0    0 931,3G  0 crypt 

    ├─cebolla--vg-root 254:1    0   500G  0 lvm   /

    └─cebolla--vg-swap 254:2    0    16G  0 lvm   

sdf                      8:80   1   7,3G  0 disk  

└─sdf1                   8:81   1   7,3G  0 part  /media/abu/D48D-FEEB

sr0                     11:0    1   3,7G  0 rom   /media/cdrom0

J'attends ton avis avant d'éteindre, ou au pire je retoucherai avec le livecd Debian.

Dernière modification par Abuishaq (12-09-2016 21:23:06)

raleur · 12-09-2016 23:07:07

Abuishaq a écrit :

pvresize /dev/mapper/sda5_crypt

Ça, c'était une mauvaise idée. J'avais bien écrit dans mon message #38 que si tu ne pouvais pas désactiver tous les volumes, il fallait redémarrer après avoir réduit la partition pour que le volume chiffré prenne la nouvelle taille. D'où les erreurs que tu as rencontrées lors des opérations suivantes.
Je te conseille de redimensionner le PV à 517 Gio si tu veux éviter les ennuis au redémarrage. Après avoir redémarré, tu pourras ajuster les tailles.

Abuishaq · 12-09-2016 23:33:08

Mince !
On verra ce que ça donne, j'ai relancé la commande pour redimensionner à 517Gio.
Je redémarre après, je te tiens au courant demain si ça à foiré ou si c'est good.

Le problème d'avoir laisser le sujet de côté pendant un moment, j'ai zappé que la commande "pvresize /dev/mapper/sda5_crypt" servirait pour réajuster les pv avec le G en moins. Et pour clouer le tout j'avais pas bien compris ce que tu voulais me dire dans ton post #38

raleur a écrit :

Par contre il faudra redémarrer pour que la nouvelle taille soit prise en compte.

Eh oui, comme j'étais plus dans le bain, j'ai pas capté tout de suite la logique du "redémarre pour prendre en compte les changements sinon ta commande pvresize servira à rien"

raleur · 13-09-2016 08:49:12

J'aurais dû mieux expliquer.
Le fait de redimensionner la partition chiffrée sda5 ne redimensionne pas automatiquement le volume chiffré sda5_crypt lorsque ce dernier est déjà ouvert (actif, présent). C'est pourquoi j'avais recommandé dans ma séquence de le faire alors que le volume chiffré était inactif, ainsi la nouvelle taille de la partition aurait été prise en compte à l'ouverture du volume chiffré. Sans taille spécifiée, pvresize ajuste (agrandit) la taille du PV à la taille du périphérique qui le contient, le volume chiffré. Or ce dernier a toujours une taille apparente de 931 Gio alors que la partition a maintenant une taille de 518 Gio. Une lecture ou une écriture à une position du volume chiffré située au delà de 518 Gio provoque une erreur, ce qu'on peut voir lors de l'exécution des commandes LVM. J'espère qu'il n'y a pas eu de corruption et que le redimensionnement du PV a une taille compatible avec la taille de la partition chiffrée aura suffi à tout remettre dans l'ordre.

Il aurait été possible de redimensionner le volume chiffré à chaud avec cryptsetup. Mais le reboot m'a paru une alternative plus simple.

Abuishaq · 13-09-2016 12:54:28

Pas de soucis, ce n'est pas ta faute, bien au contraire tu m'as bien tout expliqué et mâché le travail !

J'ai démarré la machine ce matin, aucun soucis, tout s'est bien passé. Le volume chiffré était même à 518,5G alors que j'avais modifié à 517G. J'en conclu que la commande pvresize a fonctionné quand même.

Un grand merci pour ta patience et ton aide, en espérant que ce post aidera certaines personnes à l'avenir !

Après dernier détail vraiment pour faire le perfectionniste, je ne suis pas sur la tour mais si je me souviens bien sda5_crypt est de 518,5G et son contenu est égal à 516G (/root = 500 et swap = 16) Donc 2G sont inutiles, sur le côté quoi. Je n'ai qu'à refaire les commandes que j'avais faites et donc en particulier resize2fs et modifier /root à 502,5 ?
Bon, c'est pas important mais si je veux l'ajuster, je tape la commande sans indiquer la taille pour faire comme j'ai fait pour le volume chiffré ou alors j'indique la taille à 502,5 ou alors je ne prends pas le risque, ça n'en vaut pas la peine ? (Tu me diras, même 1T c'est déjà de trop, je vais pas chipoter pour 2G)

raleur · 13-09-2016 13:11:58

Tu peux maintenant intégrer cet espace restant au PV avec pvresize (sans spécifier de taille). Si tu veux l'affecter à la racine, il faut agrandir le LV root avec lvextend ou lvresize (en spécifiant la taille) puis son système de fichiers avec resize2fs (sans spécifier la taille). Il faudra peut-être tâtonner un peu pour trouver la taille maximum du LV.

Abuishaq · 13-09-2016 14:38:29

D'acc', je testerai. En tout les cas c'est plié.
Et un sujet de réglé !

Debian-facile

#26 20-08-2016 19:59:31

Re : [Résolu] Repartitionnement DD chiffré Debian

#27 20-08-2016 20:34:41

Re : [Résolu] Repartitionnement DD chiffré Debian

#28 21-08-2016 11:28:12

Re : [Résolu] Repartitionnement DD chiffré Debian

#29 21-08-2016 17:56:15

Re : [Résolu] Repartitionnement DD chiffré Debian

#30 22-08-2016 10:19:20

Re : [Résolu] Repartitionnement DD chiffré Debian

#31 10-09-2016 22:00:32

Re : [Résolu] Repartitionnement DD chiffré Debian

#32 11-09-2016 09:36:18

Re : [Résolu] Repartitionnement DD chiffré Debian

#33 11-09-2016 14:12:56

Re : [Résolu] Repartitionnement DD chiffré Debian

#34 11-09-2016 16:08:23

Re : [Résolu] Repartitionnement DD chiffré Debian

#35 11-09-2016 21:18:25

Re : [Résolu] Repartitionnement DD chiffré Debian

#36 12-09-2016 08:56:28

Re : [Résolu] Repartitionnement DD chiffré Debian

#37 12-09-2016 10:07:49

Re : [Résolu] Repartitionnement DD chiffré Debian

#38 12-09-2016 10:17:19

Re : [Résolu] Repartitionnement DD chiffré Debian

#39 12-09-2016 12:22:46

Re : [Résolu] Repartitionnement DD chiffré Debian

#40 12-09-2016 12:30:41

Re : [Résolu] Repartitionnement DD chiffré Debian

#41 12-09-2016 21:20:41

Re : [Résolu] Repartitionnement DD chiffré Debian

#42 12-09-2016 23:07:07

Re : [Résolu] Repartitionnement DD chiffré Debian

#43 12-09-2016 23:33:08

Re : [Résolu] Repartitionnement DD chiffré Debian

#44 13-09-2016 08:49:12

Re : [Résolu] Repartitionnement DD chiffré Debian

#45 13-09-2016 12:54:28

Re : [Résolu] Repartitionnement DD chiffré Debian

#46 13-09-2016 13:11:58

Re : [Résolu] Repartitionnement DD chiffré Debian

#47 13-09-2016 14:38:29

Re : [Résolu] Repartitionnement DD chiffré Debian

Pied de page des forums