Bonjour à tous,

Bonne nouvelle empirique pour la question de @Mic13710 : la mise à jour vers DSM 7.4.1 est passée chez moi ce midi (après libération d'espace via le venv Python + purge du snapshot au redémarrage). Résultat du mdadm --detail /dev/md0 après l'update :

root@NasServeur723:~# cat /etc.defaults/VERSION
majorversion="7"
minorversion="4"
major="7"
minor="4"
micro="1"

root@NasServeur723:~# df -h /
Filesystem        Size  Used Avail Use% Mounted on
/dev/system-root  2.3G  1.6G  598M  74% /
root@NasServeur723:~# sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Fri Jan  3 10:25:56 2020
     Raid Level : raid1
     Array Size : 2490176 (2.37 GiB 2.55 GB)
  Used Dev Size : 2490176 (2.37 GiB 2.55 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Aug  4 14:46:01 2026

Inchangé. Donc confirmé : une simple mise à jour DSM, même avec assez d'espace libéré pour passer, ne déclenche pas le grow automatique de md0 vers les 8 Gio pourtant déjà présents sur mes p1. Ça répond à votre interrogation — le Mode 2 reste bien le seul déclencheur connu à ce stade.

Je garde le ticket ouvert et je poserai les deux questions de @RAHAN-31 (préservation du pool/volume en Mode 2, et existence d'un mécanisme de migration automatique prévu) si le technicien recontacte — sinon je les inclurai dans ma réponse de clôture du ticket.

Mais je pense aussi à tous les autres utilisateurs qui tomberont sur ce même blocage sans avoir nos connaissances techniques ni la patience de creuser en SSH pendant deux jours. Pour un utilisateur lambda qui voit juste "espace disque insuffisant" sans comprendre pourquoi, avec un volume de données rempli à seulement 15-20%, c'est le genre de message qui peut mener directement à un ticket support, une réinstallation complète paniquée, voire un abandon de la mise à jour par peur de casser son NAS. et je ne vous parle pas de surveillance station aucune sauvegarde de configuration

Ce qui manque cruellement, c'est ce que @RAHAN-31 évoquait plus haut : un message d'erreur DSM qui explique la vraie cause ("partition système ancienne, distincte de votre volume de données") plutôt que le message générique actuel qui laisse penser à un problème de stockage. DSM connaît pourtant parfaitement la taille de sa propre partition système — un diagnostic intégré à l'assistant de mise à jour, qui détecterait ce cas précis et proposerait directement les pistes de nettoyage (cache pip, modules Python manuels, etc.) ou orienterait vers le Mode 2 si nécessaire, éviterait à beaucoup de monde ces heures de recherche.

Voila c'est résolu mais pas soigné complètement

Modifié hier à 12:471 j par Pascalou59

il y a 3 minutes, Pascalou59 a dit :

une simple mise à jour DSM, même avec assez d'espace libéré pour passer, ne déclenche pas le grow automatique de md0 vers les 8 Gio

Ce serait pourtant si simple.... Sinon, en lignes de commande ça devrait pouvoir se faire.

Je suis entièrement d'accord avec vous : ce n'est vraiment pas professionnel de la part de Synology non seulement de ne pas avertir clairement la cause d'un problème qui est connu seulement des initiés, mais aussi de ne pas proposer de solution simple autre que le mode 2 (dont on n'est pas sur quelle fonctionne) pour augmenter automatiquement une partition quand les critères pour le faire sont réunis. Cela fait tout de même plus de 2 ans que ce problème existe. Qu'il soit laissé en l'état de gestation depuis tant de temps, qu'il n'y ait aucun communication à ce sujet me surprend. Il serait quelque part logique d'aller au bout du processus, sinon pourquoi augmenter l'espace p1 si au final on ne peut pas l'exploiter sans passer par des opérations qui dépassent largement les connaissances de la grande majorité des usagers.

Mode vieux con => ON

Attention tout de même à ne pas réduire le problème à notre cas relativement favorable p1=8 Gio → md0=2,3 Gio. Le cas de @Mic13710 montre déjà qu'il existe des géométries historiques différentes, celui de @Pascalou59 montre qu'un système peut avoir été modifié hors des chemins prévus par Synology, et il doit exister quantité d'autres héritages issus des migrations, remplacements successifs et configurations RAID/SHR.

Depuis notre canapé, le grow paraît presque trivial. Pour Synology, le vrai problème est probablement de déterminer avec une certitude suffisante quand il est sûr de le faire, et surtout quand il ne faut pas le faire.

C'est finalement pour cela que la réponse à la question laissée sous le coude à @Pascalou59 m'intéresse davantage que nos spéculations sur le déclencheur : savoir si Synology travaille sur un mécanisme officiel de migration qualifiée de ces anciens md0, ou si le Mode 2 restera définitivement la seule voie supportée.

Créer un environnement de laboratoire DSM sans exposer le système de production : vos avis ?

Au fil de cette discussion, nous avons beaucoup progressé dans la compréhension de l’évolution des partitions système (p1 à 8 Gio) et du comportement actuel de md0.

En parallèle, une idée de protocole expérimental a émergé.

Avant d’aller plus loin, j’aimerais savoir si cette approche comporte une faille technique que je n’aurais pas identifiée et bénéficier de vos regards critiques avant d’envisager la moindre manipulation.

Principe envisagé

Sur mon DS1621+, mon Storage Pool de production — SPN, constitué de trois MG11 de 22 To et actuellement porté par le Volume 2 — resterait intact.

Je créerais en parallèle un Storage Pool Laboratoire — SPL sur deux anciens HDD de 6 To, avec son propre volume séparé, en espérant que DSM ne réattribue pas le Volume1.

L’objectif serait de laisser DSM initialiser naturellement ces anciens HDD et y répliquer le système actuellement actif.

L'hypothèse est que j'obtiendrai :

p1 physiques = 8 Gio
md0 logique  = ~2,37 Gio
filesystem / = ~2,3 Gio

Une fois la réplication terminée, je vérifierais que le NAS peut démarrer correctement avec le SPL seul.

Le NAS serait ensuite arrêté et les trois MG11 de production retirés physiquement, les baies 1/2/3 leur restant réservées. Toutes les expérimentations seraient alors réalisées uniquement sur les anciens HDD et dans les baies 4 -> 6, les disques de production restant hors du NAS.

Objectifs techniques

• Analyser en profondeur toute la chaîne système : partitionnement, RAID md0, éventuelles couches propres à DSM et filesystem racine ;

• Tenter un grow manuel de md0, puis de son filesystem, en CLI ;

• Observer le comportement de DSM avant et après reboot ;

• Redémarrer, contrôler l’intégrité du système et tenter ensuite une mise à niveau DSM 7.3 → 7.4 ;

• Déterminer si cette modification produit un état durablement compatible avec les mécanismes de maintenance et de mise à jour de DSM.

L’idée n’est donc pas de modifier directement le système de production, mais de créer sur mon propre NAS un environnement reproductible dans lequel je pourrais observer, comprendre, me tromper et recommencer sans exposer les quatre actifs essentiels actuellement portés par le SPN :

1. les données ;

2. la configuration DSM ;

3. la configuration et l’état des paquets ;

4. leurs interdépendances.

Avant d’aller plus loin, j’aimerais recueillir votre avis.

Voyez-vous une contre-indication technique à cette approche ?

La création du SPL et la réplication du système sur ses HDD peuvent-elles modifier ou fragiliser d’une quelconque manière le système actuellement porté par les MG11 du SPN ?

L’hypothèse selon laquelle le SPL pourra ensuite démarrer de manière autonome avec une copie cohérente du md0 historique vous paraît-elle fondée ?

Existe-t-il une autre couche ou dépendance DSM susceptible de rendre ce laboratoire non représentatif du système de production ?

Enfin, afin de ne pas détourner davantage ce fil consacré à la mise à jour DSM 7.4, pensez-vous préférable d’ouvrir un sujet dédié à cette expérimentation ? Dans l’affirmative, dans quelle section serait-il le plus pertinent de le créer ?

L’objectif n’est pas de défendre cette idée à tout prix, bien au contraire.

Si cette idée comporte une faiblesse, je préfère largement qu'elle soit identifiée ici avant même la première manipulation. C'est précisément le but de cette réflexion.

Merci d’avance pour vos remarques.

Hello @RAHAN-31 et @Mic13710

Après le passage en de DSM en 4.1 ma VM Win10 ne fonctionne plus , plus de passerelle , le paquet Virtual Machine Manager a du etre réparé mais rien a faire la passerelle par Defaut network ne fait plus le lien , j'ai tout supprimé meme les vm et Virtual Manager , fait un redemarrage propre du NAS ......je vais devoir ouvrir encore un ticket

Voici le retour du support c'est la confirmation formelle qu'on attendait — le point important est bien confirmé noir sur blanc : "A Mode 2 reset does not affect the existing storage pool, volume, or user data." Le pool, le volume et les données utilisateur sont bien préservés, seule la config système part.

Ce qui est effacé (rien de nouveau par rapport à ce qu'on savait déjà) :

• Toutes les configs système (réseau, tâches planifiées, utilisateurs, paquets)

• Le mot de passe admin

• Le coffre de clés de chiffrement (si vous chiffrez des dossiers partagés — à vérifier si c'est votre cas)

• DSM entier à réinstaller depuis zéro

Ce que ça implique concrètement pour vous si vous décidez de le faire un jour :

• Immich, Container Manager, MariaDB, Surveillance Station, etc. → tous à réinstaller et reconfigurer manuellement

• Votre export .dss habituel → utile pour restaurer une partie de la config plus vite

Thank you for your mail.

As mentioned previously, in your case, after performing a Mode 2 reset and reinstalling DSM, the system should normally allocate an 8 GB system partition.

A Mode 2 reset does not affect the existing storage pool, volume, or user data. However, please note that it has the following effects:

• All system configurations will be erased.

• The administrator password will be cleared.

• The encryption key vault will be cleared.

• DSM will need to be completely reinstalled.

For this reason, we recommend backing up your system configuration before performing the Mode 2 reset. After reinstalling DSM, you can restore the system configuration from the backup.

• Configuration Backup

• How to rInserteset my Synology NAS (For DSM 6.2.4 or later)

If you use encrypted shared folders or volumes, please also ensure that the relevant encryption keys or recovery keys have been exported and stored safely before proceeding.

Hope this information helps, and kindly let us know if further assistance is needed.

Best Regards,
Technical Support

Modifié il y a 13 heures13 h par Pascalou59