Redimensionnement de partition suite à upgrade SSD1->SSD2
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

Redimensionnement de partition suite à upgrade SSD1->SSD2

B
Par
BertrandO1
Créé le 2020-02-17 20:44:03 (edited on 2024-09-04 14:14:23) dans Serveurs Privés Virtuels (VPS)

Bonjour,

Je reprends ma question puisque OVH refuse de me répondre !

J'ai fait un upgrade de VPS de SSD1 à SSD2.

J'ai suivi la documentation, mais l'option a de fdisk n'est pas reconnue et depuis impossible de booter le VPS (ce qui parrait logique car il n'a pas été possible de le rendre amorçable)
https://docs.ovh.com/fr/vps/repartitionner-vps-suite-upgrade/

Voici l'historique, on y voit que peu importe la manipulation, elle n'est pas prise en compte y compris après reboot

root@rescue-pro:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.5G 0 disk
└─sda1 8:1 0 2.5G 0 part /
sdb 8:16 0 40G 0 disk
├─sdb1 8:17 0 19.9G 0 part /mnt/sdb1
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part /mnt/sdb15
root@rescue-pro:~# umount /dev/sdb1
root@rescue-pro:~# e2fsck -yf /dev/sdb1
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
cloudimg-rootfs: 287665/2580480 files (0.4% non-contiguous), 5039019/5214459 blocks
root@rescue-pro:~# fdisk -u /dev/sdb

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).
GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).

Command (m for help): p

Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0E34F2CF-E596-4CC5-A048-72442450EF39

Device Start End Sectors Size Type
/dev/sdb1 227328 41943006 41715679 19.9G Linux filesystem
/dev/sdb14 2048 10239 8192 4M BIOS boot
/dev/sdb15 10240 227327 217088 106M EFI System

Partition table entries are not in disk order.

Command (m for help): d
Partition number (1,14,15, default 15): 1

Partition 1 has been deleted.

Command (m for help): n
Partition number (1-13,16-128, default 1): 1
First sector (34-41943006, default 227328):
Last sector, +sectors or +size{K,M,G,T,P} (227328-41943006, default 41943006):

Created a new partition 1 of type 'Linux filesystem' and of size 19.9 GiB.
Partition #1 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: Y

The signature will be removed by a write command.

Command (m for help): a
a: unknown command

Command (m for help): p
Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0E34F2CF-E596-4CC5-A048-72442450EF39

Device Start End Sectors Size Type
/dev/sdb1 227328 41943006 41715679 19.9G Linux filesystem
/dev/sdb14 2048 10239 8192 4M BIOS boot
/dev/sdb15 10240 227327 217088 106M EFI System

Partition table entries are not in disk order.

Command (m for help): w
GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).
fdisk: failed to write disklabel: Invalid argument

root@rescue-pro:~# fdisk -u /dev/sdb

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).
GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).

Command (m for help): p

Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0E34F2CF-E596-4CC5-A048-72442450EF39

Device Start End Sectors Size Type
/dev/sdb1 227328 41943006 41715679 19.9G Linux filesystem
/dev/sdb14 2048 10239 8192 4M BIOS boot
/dev/sdb15 10240 227327 217088 106M EFI System

Partition table entries are not in disk order.

Command (m for help): w
GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).
fdisk: failed to write disklabel: Invalid argument
root@rescue-pro:~# fdisk -u /dev/sdb

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).
GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).

Command (m for help):

J'ai depuis réussi à redémarrer (je ne sais pas comment) mais le disque est toujours en 20Go.

Mon problème, c'est que la doc qu'OVH fournit n'est pas en phase avec l'OS du mode rescue qui nous est mis à disposition.
Mon problème se situe donc sur le mode rescue et non sur l'OS cible (que nous gérons), à l'étape du fdisk "a" pour rendre amorcable qui n'est pas disponible.

D'autre part, il manque le redimensionnement de la GPT PMBR (GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).) qui n'est pas corrigée par un write !

Quelqu'un a t'il déjà rencontré mon problème ? et a réussi à le résoudre, surtout :) ?
J'ai vu que plusieurs d'entre vous ont eu des pbs de redimensionnement, mais aucun sur la GPT PMBR.

Merci par avance pour vos pistes.

Mathieu
Avis positifs (0)
2665 Vues
1 réponse ( Latest reply on 2020-04-11 13:04:56 Par
DavidV24
)
D

Bonjour, j'ai eu *exactement* le même problème et je l'ai résolu.

> GPT PMBR size mismatch (41943039 != 83886079) will be corrected by w(rite).

Cela indique qu'il y a un problème avec la taille de disque qu'indique la table de partition GPT. Peut-être que la procédure d'upgrade par OVH n'a pas fait exactement les choses comme il faut. En tout cas cela empêche fdisk de considérer l'intégralité du disque : lors de la sélection de la fin de la partition (`Last sector`), il propose `41943006` (dernier secteur du disque 20 Go) au lieu de `83886046` (dernier secteur pour 40 Go).

C'est donc en cherchant ce message d'erreur sur GPT que j'ai trouvé cette information (https://ubuntuforums.org/showthread.php?t=2277232&p=13280872#post13280872) :

> Fdisk used to not work at all on gpt partitioned drives, it just reported that drive was gpt partitioned.
Better to use parted, gparted or gdisk.

Donc en fait, fdisk n'arrive pas à gérer correctement les partitions GPT, il faut utilser un autre outil.

Personnellement j'avais déjà utilisé `parted` donc je l'ai installé, c'est possible sur le mode rescue :
````
root@rescue-pro:~# apt-get install parted
````

Il n'y a pas besoin de connaître cet outil en profondeur ; néanmoins (pour information) https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks le wiki de Gentoo à ce sujet montre bien comment l'utiliser. Ici je l'ai seulement utilisé pour corriger le souci avec GPT.
````
root@rescue-pro:~# parted -a optimal /dev/sdb
(parted) print all
Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use
all of the space (an extra 41943040 blocks) or continue with the current setting?
Fix/Ignore? Fix
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdb: 42.9GB
(... infos disque)
````

Lorsqu'on demande à afficher les partitions, parted détecte explicitement le problème avec GPT et propose de le corriger : c'est ce que j'ai fait en répondant `Fix`. On laisse parted faire sa cuisine et hop, maintenant la table GPT connaît tout le disque !

On sort de parted (`quit`) et on retourne sur fdisk, on va maintenant pouvoir suivre les instructions de la doc d'ovh : supprimer la partition sdb1 puis la recréer. On se rend compte que lors de la sélection du dernier secteur, c'est bien `83886046` qui est proposé :
````
Last sector, +sectors or +size{K,M,G,T,P} (227328-83886046, default 83886046):
````

Youpi, on peut mettre la vraie fin du disque pour avoir tout l'espace !

On suit le reste des instructions d'ovh (write et resize2fs). Et maintenant on a bien :
````
root@rescue-pro:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.5G 0 disk
`-sda1 8:1 0 2.5G 0 part /
sdb 8:16 0 40G 0 disk
|-sdb1 8:17 0 39.9G 0 part /mnt/sdb1
|-sdb14 8:30 0 4M 0 part
`-sdb15 8:31 0 106M 0 part /mnt/sdb15
````

On a nos 40 Go !

Pour la question de la partition amorçable, j'ai préféré ne pas y toucher (les deux autres partitions sdb14 et sdb15 servent au démarrage), donc je n'ai pas utilisé la commande `a`, et le VPS a redémarré normalement en mode normal (par l'interface OVH du VPS).
Utile (0)

Sujets apparentés

Rejoindre la discussion