Resize EXT4 + Partition > Revient (seul) à la taille originale Le sujet est résolu

[dezix]

Bonjour,

J'ai envie de chanter :
"J'ai un petit problème dans ma partition... Pourquoi ça réduit pas ?"


Il s'agit d'un VPS d'OVH en Debian 11,
à l'origine c'est livré comme ça :

NOTE: En Rescue Mode (Live session) le disque système = /dev/sdb

Code : Tout sélectionner

# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdb: 83886080 sectors, 40.0 GiB
Model: QEMU HARDDISK   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 20E5DA22-C74A-D743-9F73-374385782D22
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 83886046
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1          262144        83886046   39.9 GiB    8300  Linux filesystem
  14            2048            8191   3.0 MiB     EF02  
  15            8192          262143   124.0 MiB   EF00  

D'abord cette numérotation me déplait,

/dev/sdb14 et /dev/sdb15 doivent devenir : /dev/sdb1 et /dev/sdb2


Ensuite, je veux ajouter une /dev/sdb3 pour /boot

et

le reste du dique sera passé en PV pour LVM portant le reste du système.


Au final ça devrait donner :

Code : Tout sélectionner

Device          Size    Type                Mount
+++++++++++++++++++++++++++++++++++++++++++++++++++
/dev/sdb1       3M      BIOS boot
/dev/sdb2       124M    EFI System          /boot/efi
/dev/sdb3       300M    Linux filesystem    /boot
/dev/sdb4       4G      Linux filesystem    PV
/dev/sdb5       35.5G   Linux filesystem    PV

Voici la liste des commandes passées pour y parvenir :


# Réduire FS Part1

Code : Tout sélectionner

# e2fsck -fy /dev/sdb1

# resize2fs -M /dev/sdb1
    resize2fs 1.44.5 (15-Dec-2018)
    Resizing the filesystem on /dev/sdb1 to 424129 (4k) blocks.
    The filesystem on /dev/sdb1 is now 424129 (4k) blocks long.  (1.62GB)

# Changer Part1 > Part4 et Réduction → 4GB

Code : Tout sélectionner

# gdisk /dev/sdb

Number  Start (sector)  End (sector)    Size        Code    Name
1       262144          83886046        39.9 GiB    8300    Linux filesystem


Commandes :
°°°°°°°°°°°
    d       1
    n       4
    start   262144
    end     +4G
    type    8300
    w

Résultat :
°°°°°°°°°°

Number  Start (sector)  End (sector)    Size        Code    Name
4       262144          8650751         4.0 GiB     8300    Linux filesystem

# Ajuster le FS

Code : Tout sélectionner

# resize2fs /dev/sdb4
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/sdb4 to 1048576 (4k) blocks.
The filesystem on /dev/sdb4 is now 1048576 (4k) blocks long.    (4GB)

Donc pour moi, à ce stade la partition et le système de fichiers ext4 qu'il porte,
font exactement 4GB <=> (1048576×4×1024) ∕ (1024^3) = 4 (je conserve 1024^1 de chaque bord exprès ;-)

Ensuite j'ai continué avec gdisk pour "transposer"
/dev/sdb14 et /dev/sdb15 pour respectivement /dev/sdb1 et /dev/sdb2

Et j'ai obtenu au final :

Code : Tout sélectionner

Number  Start (sector)  End (sector)    Size        Code    Name
   1    2048            8191            3.0 MiB     EF02  
   2    8192            262143          124.0 MiB   EF00  
   4    262144          8650751         4.0 GiB     8300    Linux filesystem

J'ai ensuite fait dans un chroot :

Code : Tout sélectionner

update-grub
grub-install /dev/sdb

...pour mettre à jour les N° de part gpt.

Comme les UUID n'ont pas changés, je n'ai même pas à modifier /etc/fstab


J'ai redémarré le serveur en Mode normal,
je m'y suis connecté via SSH => Tout semblait fonctionner correctement.


J'ai donc relancé une nouvelle session Live "Rescue" pour poursuivre la mise en place de LVM
et voici ce que je retrouve :

Code : Tout sélectionner

# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 83886080 sectors, 40.0 GiB
Model: QEMU HARDDISK   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 20E5DA22-C74A-D743-9F73-374385782D22
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 83886046
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            8191   3.0 MiB     EF02  
   2            8192          262143   124.0 MiB   EF00  
   4          262144        83886046   39.9 GiB    8300  Linux filesystem

!!! La part 4 est revenue à 39.9 GiB !!!

et maintenant :

EDIT

La commande suivante est erronée,
j'aurais du mettre : e2fsck -fy /dev/sdb4

Code : Tout sélectionner

!!!! MAUVAISE PARTITION en argument !!!!

# e2fsck -fy /dev/sdb1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Là je suis coincé !

À part tenter de reconstruire le système sur un LVM vide à partir d'une copie intégrale du système avec rsync (la sauvegarge est déjà faite)

... mais ça m'ennuie de ne pas comprendre où j'ai merdé !


Merci pour vos solutions

[lol]

Salut,

Je n'ai jamais été très à l'aise avec le partitionnement en ligne de commande et surtout pas avec parted (trop peur de faire des conneries...)
Du coup j’utilise cfdisk, c'est un peu plus visuel... Tu peux accéder à cette commande en live ?

cfdisk.png

[dezix]

Bonjour,

gdisk est aussi un système interactif ; j'ai plus l'habitude de fdisk
mais les 2 sont assez similaires du moins en ce qui concerne l'interface.

Je n'ai pas eu le temps de m'y pencher ce matin,
mais je me demande si ce n'est pas un (mauvais) coup de cloud-init

Sur les anciens VPS avec une table msdos je commence par désactiver cloud-init
puis, virer le noyau cloud-init pour utiliser le noyau stable par défaut,
et seulement alors je mets LVM en place.

Avec ce partitionnement GPT,
j'ai préféré commencer par remettre les partitions dans l'ordre,
...c'est peut-être mon erreur ?

[lol]

Hello,

Je ne crois pas que cloud-init y soit pour quelque chose.
Les partitions ne sont pas gérées au démarrage de l'OS.

J'ai déjà été emmerdé chez OVH par cloud-init mais pour des histoires réseau...

[dezix]

C'est réparé !

Je n'ai pas compris (vraiment) pourquoi la modification (resize part4) n'a pas été validée

Mais j'ai refais :

1. Réduire le FS au mini
2. Réduire la Part 4
3. Ajuster le FS pour qu'il occupe toute la part4
4. Créer la part5 sur le reste du disque
5. Créer un Volume Physique LVM (PV) sur la part5 (comme cela, elle est clairement utilisée)

Et cela donne finalement :

Code : Tout sélectionner

# gdisk -l /dev/sdb

	Disk /dev/sdb: 83886080 sectors, 40.0 GiB
	Model: QEMU HARDDISK   
	Sector size (logical/physical): 512/512 bytes
	Disk identifier (GUID): 20E5DA22-C74A-D743-9F73-374385782D22
	Partition table holds up to 128 entries
	Main partition table begins at sector 2 and ends at sector 33
	First usable sector is 2048, last usable sector is 83886046
	Partitions will be aligned on 2048-sector boundaries
	Total free space is 0 sectors (0 bytes)
	
	Number  Start (sector)    End (sector)  Size       Code  Name
	   1            2048            8191   3.0 MiB     EF02  
	   2            8192          262143   124.0 MiB   EF00  
	   3          262144          876543   300.0 MiB   8300  Linux filesystem
	   4          876544         9068543   3.9 GiB     8300  Linux filesystem
	   5         9068544        83886046   35.7 GiB    8300  Linux filesystem

Cause possible du problème
Peut-être que le problème est survenu parce que le noyau n'avait pas encore pris en compte les modifications de la table partition au reboot ???

J'écris cela car lorsque je fais toute cette mise en place via un script,
je dois utiliser la commande : partprobe
entre les diverses étapes pour que la précédente modif soit prise en compte par le noyau,
qui sinon il semble rester sur un "cache" ne correspondant plus à la nouvelle config des volumes (c'est pas de la théorie, juste mon observation...)

[lol]

Cause possible du problème

Ou tu n'as pas enregistré avant de quitter gdisk... Ce qui est tout de même, avouons-le, le plus probable, non ?

Edit: Avec un smiley c'est mieux...

[dezix]

Ou tu n'as pas enregistré avant de quitter gdisk... Ce qui est tout de même, avouons-le, le plus probable, non ?

Sûr que non, j'enregistre toutes les sorties dans un fichier...

Mais avec ce même système j'ai eu aussi des difficultés avec adduser <user> <group>
tout semblait bien sur le moment en root et en <user>,
sauf que par la suite le <user> n'était plus considéré dans le groupe, même après un groups <user>

... ça m'a bien pris la tête !

[PascalHambourg]

Ensuite, je veux ajouter une /dev/sdb3 pour /boot
et
le reste du dique sera passé en PV pour LVM portant le reste du système.

Alors pourquoi t'embêter à renuméroter et réduire les partitions plutôt que tout repartitionner ?

Peut-être que le problème est survenu parce que le noyau n'avait pas encore pris en compte les modifications de la table partition au reboot ???

Non. Le noyau avait bien pris en compte la nouvelle taille puisque resize2fs a appliqué celle-ci. Et la renumérotation a bien été prise en compte.
Il y a peut-être quelque chose qui redimensionne automatiquement la dernière partition pour utiliser tout l'espace disque libre à la fin du disque. Cela peut être utile lorsqu'on agrandit un disque virtuel.

lorsque je fais toute cette mise en place via un script, je dois utiliser la commande : partprobe
entre les diverses étapes pour que la précédente modif soit prise en compte par le noyau,
qui sinon il semble rester sur un "cache" ne correspondant plus à la nouvelle config des volumes

En effet le noyau lit la table de partition lors de l'ajout du disque au démarrage et ne va pas prendre en compte de lui-même une modification de celle-ci. Il faut lui dire. Normalement, c'est le programme de partitionnement qui s'en charge automatiquement, mais cela peut échouer.

La méthode traditionnelle pour signaler une modification de la table de partition est de demander au noyau de relire toute la table de partition. Mais il ne peut le faire que si aucune partition du disque n'est en cours d'utilisation (système de fichier monté, swap activé, PV LVM contenant des LV actifs...). Cette méthode était utilisée par les anciennes versions de fdisk et gdisk.

C'est pourquoi une nouvelle méthode consistant à n'envoyer au noyau que les modifications des partitions (ajout, suppression, changement de taille) a été ajoutée. Cette méthode est utilisée par parted, les versions récentes de fdisk, les commandes partprobe, addpart, delpart, resizepart.. Je ne suis pas sûr concernant les versions récentes de gdisk en revanche.

Et cela donne finalement :

Code : Tout sélectionner

	Number  Start (sector)    End (sector)  Size       Code  Name
	   1            2048            8191   3.0 MiB     EF02  
	   2            8192          262143   124.0 MiB   EF00  
	   3          262144          876543   300.0 MiB   8300  Linux filesystem
	   4          876544         9068543   3.9 GiB     8300  Linux filesystem
	   5         9068544        83886046   35.7 GiB    8300  Linux filesystem

Si les deux dernières partitions sont utilisées comme PV LVM, tu devrais changer leur code/type en conséquence pour une meilleure lisibilité.

[dezix]

Bonjour,

Alors pourquoi t'embêter à renuméroter et réduire les partitions plutôt que tout repartitionner ?

Parce que :

1. À la livraison/installation par OVH le disque est totalement utilisé.
2. Je préfère travailler localement (sur le vps) que devoir transférer une copie distante des fichiers en "aller-retour"
3. Les partions originales 14et 15 ont juste besoin d'être "transposées" ( gdisk > mode expert "x" > commande "t" )
4. Du coup j'utilise mv -f pour déplacer les fichiers vers les diverses partitions et volumes logiques, ce qui j'espère conserve parfaitement les permissions et attributs des fichiers.

Y aurait-il une méthode plus directe que j'ignore ?

quelque chose qui redimensionne automatiquement la dernière partition pour utiliser tout l'espace disque libre à la fin du disque

C'est ce que je suspectais en me référant à cloud-init ( au pif )

Si les deux dernières partitions sont utilisées comme PV LVM, tu devrais changer leur code/type en conséquence pour une meilleure lisibilité.

Je vais corriger cela.

Merci

[PascalHambourg]

[*]

Parce que :
À la livraison/installation par OVH le disque est totalement utilisé.
Je préfère travailler localement (sur le vps) que devoir transférer une copie distante des fichiers en "aller-retour"

Je ne vois pas en quoi cela t'empêche de repartitionner. C'est pour éviter de réinstaller ?

[dezix]

C'est pour éviter de réinstaller ?

Oui, car la réinstallation ne peut (je crois ???) se faire que via le service du fournisseur qui écrase tout en recopiant une image "originale" avec le partitionnement initial.

[PascalHambourg]

Ah ? Le mode rescue ne permet pas d'installer ce que tu veux ?

[dezix]

Ah ? Le mode rescue ne permet pas d'installer ce que tu veux ?

Je ne crois pas , je vais me renseigner, mais pour le moment je n'ai rien vu de tel.

[dezix]

J'ai passé un peu de temps sur le site d'OVH et je n'ai rien trouvé de probant.

Je suis tombé sur une question d'un "ancien" admin Debian (probablement recyclé ou en retraite) s'étonnant de devoir tout réorganiser à la main,
sur quoi "los aficionados" du forum ovh, ont répondu en gros : "Autres temps, autres technologies (SSD,...), autres mœurs... c'est à dire : T'occupe pas du partitionnement et installe en vrac ... "

Alors ça me questionne : Soit ils n'y connaissent rien (ou ils ont oublié ou sont devenus très paresseux) ; soit ici nous marchons sur la tête ?

Personnellement, je pars du postulat que ce n'est pas parce qu'un système est installé sur une petite configuration que l'on doit lui allouer moins d'attention,
et serait même le contraire vu que les ressources y sont plus limitées.

Pour revenir à la question de l'installation en RecueMode :

Est-il envisageable si l'espace est suffisant pour télécharger l'ISO,
de faire tourner l'installateur Debian (netinstall) dans un chroot ?

[PascalHambourg]

Soit ils n'y connaissent rien (ou ils ont oublié ou sont devenus très paresseux)

De qui parles-tu ? D'OVH ou des utilisateurs de ces VPS ?
Je ne serais pas surpris que le "public" type de ces VPS soit plus intéressé par les applications que par le système sur lequel elles tournent, et OVH "optimise" son offre en toute connaissance de cause. Pourquoi proposer une installation personnalisée qui dépasserait les compétences de la plupart des clients, sachant que les rares comme toi qui ont le besoin et les compétences sauront se débrouiller sans ?

Pour revenir à la question de l'installation en RecueMode :
Est-il envisageable si l'espace est suffisant pour télécharger l'ISO,
de faire tourner l'installateur Debian (netinstall) dans un chroot ?

Aucune idée, je n'ai jamais essayé de lancer l'installateur Debian dans un chroot. Au minimum il faudrait que le système rescue soit capable d'exécuter debootstrap.

[dezix]

De qui parles-tu ? D'OVH ou des utilisateurs de ces VPS ?

Je ne parle pas des gens d'OVH qui gèrent l'infrastructure et les produits,
mais de contributeurs assidus du forum qui ont probablement un statut particulier vis-à-vis d'ovh.

D'ici peu j'aurais à réinstaller un autre vps, je ferai le test de l'installateur dans un chroot... si j'en suis capable.