fdisk "GPT PMBR size mismatch" dans le résultat d'une commande fdisk -lu : grave ou pas ? Correctible ?

[MilesTEG1]

Dites, en faisant un fdisk -lu sur mon Syno, j'ai vu quelque chose que j'avais déjà vu auparavant mais sans y prêter trop attention :
GPT PMBR size mismatch (239649 != 245759) will be corrected by w(rite).
Cette ligne apparait juste avant Disk /dev/synoboot :

Citation

Disk /dev/mapper/vg1-volume_1: 3.6 TiB, 3995825340416 bytes, 7804346368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

GPT PMBR size mismatch (239649 != 245759) will be corrected by w(rite).
Disk /dev/synoboot: 120 MiB, 125829120 bytes, 245760 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: 0361D5BB-196D-4EB0-AC6B-A8D9B7DE9DCB

Device         Start    End Sectors Size Type
/dev/synoboot1  2048  67583   65536  32M EFI System
/dev/synoboot2 67584 239615  172032  84M Linux filesystem

Disk /dev/md3: 12.7 TiB, 13995581898752 bytes, 3416890112 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Le système semble fonctionner correctement, bien qu'il n'ait pas redémarré depuis un certains temps (il a été bloqué pendant une semaine par le test badblocks, et là par la restauration des données).
Dès que c'est fini je tente un reboot, mais je pense que cette "erreur" sera toujours présente après vu qu'elle est présente je pense depuis longtemps.

Bref, j'aimerais bien comprendre ce que ça signifie, et surtout s'il est possible de ne plus l'avoir sans péter tout le système de fichier du NAS et donc de foirer les données...
Qu'en pensez-vous ?

PS : j'ai trouvé ce sujet où il y a cette "erreur" au même endroit que moi avec une solution : https://community.synology.com/enu/forum/17/post/95467?reply=323860

Mais je vous avoue que la tenter sans savoir ce qu'elle fait me refroidi... Donc j'attends vos avis ^^
Thanks !

[oracle7]

@MilesTEG1

Bonjour,

Si cela peut te rassurer, tu n'est pas seul !🥴 J'ai effectivement aussi ce type d'anomalie sur mes deux NAS.

Comme toi je reste prudent, puisque tout semble marcher correctement par ailleurs, et j'attends donc aussi un avis motivé sur cette affaire. Même si la solution que tu as trouvée me parait "clean" je préfèrerai aussi en savoir un peu plus.

Cordialement

oracle7😉

 

[MilesTEG1]

@oracle7je vais faire un ticket chez Synology quand j’aurais un moment 😊

je suis plus à un ticket ouvert près là 😁

[oracle7]

@MilesTEG1

Bonjour,

Tu as des nouvelles suite à cette anomalie ?

Cordialement

oracle7😉

[MilesTEG1]

@oracle7 salut 🙂

Elle est toujours en cours d'investigation par le support Synology.
Ils ont eu besoin d'avoir accès au NAS, je vous dirais quand ils m'auront répondu.
Mais les premières réponses sont : mieux vaut pas y toucher.

[oracle7]

@MilesTEG1

Bonjour,

OK, merci de ta réponse alors on attendra leur verdict sans rien toucher. Cela reste quand même bizarre cette affaire 🤨

Cordialement

oracle7😉

[MilesTEG1]

Oui c'est clair !
j'avais déjà vu ça sur mon 214play...
D'ailleurs, faudrait que je regarde si sur les disques actuellement dedans j'ai aussi cette chose...

[MilesTEG1]

Salut ,

@oracle7 J'ai eu un retour du support Synology :

Citation

Bonjour,

J'ai eu un retour du service concerné.

c'est une différence technique interne de la configuration entre les appareils d'avant et les modèles récents. Et a été laissé ainsi car cela n'affecte rien

Pour conclure c'est tout a fait normal  n'a aucun impact nul part, par contre le service concerné conseille donc de ne surtout pas éditer le synoboot car cela pourrait entrainé des problèmes sur celui-ci et donc de ne surtout pas utiliser parted pour toucher a cette partition dédiée.

Cordialement,

Verdict : ne rien tenter 😄  ce qu'on pensait initialement.

Par contre, ce que je trouve étonnant, c'est que mes volumes ont été créés sur le 920+ directement... sans passer par l'ancien NAS...
Bon à l'époque c'était en DSM 6.2.3-25426 Update 2... Je sais pas si ça joue...

[oracle7]

@MilesTEG1

Bonjour,

Il y a 3 heures, MilesTEG1 a dit :

Verdict : ne rien tenter 😄  ce qu'on pensait initialement.

OK Merci pour l'info, comme quoi il est sage de ne pas se précipiter sur tout correctif aussi tentant que cela peut-être 🤨

Cordialement

oracle7😉

[MilesTEG1]

Le support FR est plus réactif que le support étranger 😅

J'ai eu une nouvelle réponse après ma question sur le fait que mon NAS avait été installé l'été dernier de 0 :

Citation

Bonjour,

Non non,

rien a voir je m'explique mal je pense.

c'est issue du design original que nous utilisions depuis des années sur l'agencement de ces partitions primaires, sauf que les performances et les capacités évoluent sur les produits récents.

La configuration a été laissée ainsi même si les produits ont eux évolués, les développeurs sont au courant et comme j'expliquai cela n'a aucune incidence du tout, ils ont juste décidé de laisser ainsi(la taille des infos bootable étant demeurée identique), étant la partition de boot, utiliser parted dessus n'est pas anodin si la moindre chose se passe le NAS ne pourrait plus booter, il est donc totalement déconseillé de faire quoi que ce soit sur cette partition d'amorçage.

 

La configuration est très bien comme elle est et n'a aucun besoin d 'être retouchée. et n'engendre aucun souci il ne faut juste pas tenir compte de ce message.

Cordialement,

Quoiqu'il en soit, je touche pas à cette partition 🙂