Toutes les discussions

Bonjour, J'ai essayé de faire un test de mémoire, mais Synology Assistant ne vois pas mon NAS, pourtant il répond bien au ping. Je le vois bien dans https://finds.synology.com/ et est en statut prêt et lorsque je clique sur se connecter, il met qu'il a mis trop de temps à répondre. Le problème est survenue après avoir installé le paquet qBittorrent, qui je pense prend toute les ressources du NAS du coup je suis coincé

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.

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" Creation Time : Fri Jan 3 10:25:56 2020 Array Size : 2490176 (2.37 GiB 2.55 GB)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

Quelques pistes avant d'aller plus loin : https://kb.synology.com/fr-fr/DSM/tutorial/What_can_I_do_unresponsive_Synology_NAS

Bonjour, J'ai un DS214Play avec 2 disque de 4To chacun et suite à l'installation du paquet qBittorrent depuis le SynoCommunity, je n'ai plus accès à mon NAS depuis l'interface web de DSM. Je ne peux donc même pas désinstaller le paquet. SSH n'étant pas activé, je me retrouve bloqué avec un NAS inutilisable sur lequel je ne peux plus accéder ni faire quoi que ce soit. Pourriez-vous m'aider, si possible sans perdre les données mais la réinstallation de DSM (sans perdre les données des disques) me fait pas peur, je reconfigurerais de nouveau DSM ? Merci de votre aide

@Pascalou59 Une dernière réflexion issue de la réponse du support, que je te laisse simplement sous le coude si ton échange avec eux se poursuit. Finalement, au-delà de savoir si 7.4 déclenche ou non le passage de md0 de ~2,37 Gio à ~8 Gio, la question qui conditionne vraiment la stratégie à long terme serait de savoir si Synology prévoit un mécanisme officiel permettant un jour cette migration automatiquement, sans passer par un Mode 2. Car les conséquences sont complètement différentes : Mécanisme prévu ↓ rester en 2,37 Gio peut avoir du sens et attendre sa disponibilité Mécanisme non prévu ↓ autant envisager le Mode 2 au moment où les conditions sont les plus favorablesSi tu juges le moment opportun et que ton ticket est toujours ouvert, voilà la question que je poserais au support : Aucune urgence à la poser : je te la laisse simplement sous le coude si l'occasion se présente. 😉 Rassure-toi : dans la confrérie des « plus malins qui s'en sont mangé les doigts quelques années plus tard », tu es loin d'être seul. 😉 Et vu ce que je viens de découvrir sur mon propre NAS après des années d'évolution DSM… je vais soigneusement éviter de te jeter le premier secteur. 😇

Pas simple cette histoire de partition système. Attendons la réponse de @Pascalou59 pour en avoir le coeur net. Finalement, ça ne sera pas possible dans mon cas. Il faudrait pour ce faire que j'ai environ 5.6Go inutilisés en fin de disque. Or tout le disque est exploité. Si DSM crée un partition à 7.9Go, je ne pourrais pas reconstruire le groupe avec l'espace restant. La faute à une augmentation de l'espace de donnée que j'avais faite il y a bien longtemps pour exploiter tout le disque. A l'époque, il y avait quelques Go qui étaient non exploités après la création du groupe. J'ai joué au plus malin et du coup je n'ai plus cet espace qui avait probablement été laissé intentionnellement par Synology pour faire face à des modifications ultérieures. Il ne me reste plus qu'à tout reconstruire si je veux changer la taille de ma partition système.

@Mic13710 Tout à fait d'accord. C'est même désormais le test le plus intéressant et le moins intrusif : si @Pascalou59 récupère suffisamment d'espace après son reboot pour lancer normalement 7.4, un relevé df / proc/partitions / mdadm avant et après nous dira directement si l'upgrade constitue le fameux déclencheur. Le Mode 2 ne viendrait qu'ensuite si nécessaire... malheureusement 🤒, on vient de gagner au passage une migration Data mine de rien 🥳 Donc Wait and See la réponse du tech à notre question concernant la préservation du poo/volume Data et/ou celle de son upgrade...

Recourir à un reset mode 2 me semble un poil excessif. Il faudrait aussi savoir si une simple mise à jour de DSM vers une version ultérieure déclenche une augmentation automatique de la partition système de 2.3Go à 7.9Go si p1 est à 8Go.

Merci @Pascalou59 pour avoir complété la réponse du support, là c'est beaucoup plus clair ! Leur proposition confirme donc bien que, dans ton cas particulier : p1 physiques = 8 Gio md0 historique = ~2,37 Gio ↓ Mode 2 + réinstallation DSM ↓ partition système = 8 GoEt le fait qu'ils proposent ensuite de restaurer la configuration DSM laisse logiquement penser que le pool et le volume DATA existants sont conservés. Mais c'est justement le dernier point que j'aimerais verrouiller explicitement, car les conséquences ne sont évidemment pas les mêmes entre « réinstaller DSM » et « reconstruire le stockage ». Si ton ticket est toujours ouvert, pourrais-tu leur poser cette dernière question, idéalement en anglais pour éviter toute ambiguïté : Leur réponse permettrait de savoir précisément où se situe la frontière de l'opération. Ton retour concernant Surveillance Station illustre d'ailleurs parfaitement le problème suivant : préserver les DATA ne signifie pas nécessairement préserver l'ensemble de l'environnement applicatif. La configuration DSM, les configurations propres aux paquets et leurs interdépendances constituent également des actifs qu'il faut pouvoir restaurer. Merci encore de nous faire suivre les échanges avec le support.

On avait déjà eu le coup des périphériques USB non reconnus suite à une mise à jour de la branche 7.3, et qui empêchait surtout les communications avec les onduleurs. C'est surprenant que Synology ait refait la même bourde avec DSM 7.4… 🤦‍♂️

Bonjour a tous @RAHAN-31 Retour du support sur ta question (pas formulée exactement comme tu l'as demandée, mais ça y répond indirectement) : Donc a priori : pas de mécanisme de grow automatique de md0 malgré les p1 déjà à 8 Gio sur les disques. Seule la réinstallation complète (Mode 2) déclenche la réallocation. Ça confirme ta lecture initiale, malheureusement — la présence de l'espace physique ne suffit pas, il faut le déclencheur de réinstallation pour que DSM en profite. Autre découverte en creusant de mon côté, qui pourrait vous intéresser à tous les deux : en supprimant des paquets Python installés manuellement dans /usr/lib/python3.8/site-packages (190 Mo), l'espace ne s'est pas libéré immédiatement dans df -h. En creusant, j'ai trouvé un dossier /.syno_rbd/snapshot.dat de 126 Mo apparu au moment exact de la suppression — visiblement un mécanisme de snapshot/rollback de sécurité que DSM déclenche automatiquement lors de modifications importantes sur la partition système. L'espace ne sera vraisemblablement libéré qu'au prochain redémarrage propre. Je suis en pleine sauvegarde Active Backup (encore 4-5h), donc je testerai le redémarrage une fois terminée et je confirmerai si ça résout l'écart. Aute point important surveillance station n'a pas de sauvegarde meme les réglages pour toutes les caméras !! je trouve vraiment que synology n'apporte pas de solution et c'est vraiment abuser , a moins de tout refaire il y a beaucoup de temps a passer meme avec toutes les sauvegardes diverses A suivre

Bonjour, Existe t'il une comande pour reconnecter un disque dur USB externe, qui a été antérieurement ejecté, sans être obligé de le débrancher et rebrancher physiquement sur le NAS ?

Je privilégierais le VPN box car si le NAS est en rade, le réseau reste joignable et il sera possible de tenter de remettre le NAS en service à distance. Vous pouvez aussi garder en réserve celui du NAS, openVPN de préférence. Après tout dépend de la box. Si c'est une freebox (je ne sais pas pour les autres), vous avez wireguard (dont tailscale est un dérivé) qui est le VPN le plus rapide.

Bonjour, Tout est dans le titre. Actuellement j'accède à distance via une adresse synology.me, et je sécurise comme je peux via les IP autorisées, grâce au tuto trouvé ici. Mais aujourd'hui les solutions VPN à disposition sont multiples, dont les trois décrites dans le titre. Notons que je parle bien d'un VPN pour accéder à mon NAS, pas pour faire semblant d'être ailleurs ! Quel est le plus simple à configurer, sachant qu'outre l'accès au syno en tant que tel je voudrais autoriser mon fils à accéder à ma filmothèque via Infuse ?

Version : 7.4.1-90080(2026-07-23) Note importanteAprès l'installation de cette mise à jour, vous ne pourrez plus revenir à une version antérieure de DSM. Cette mise à jour redémarrera votre NAS Synology. Si la mise à jour automatique ne s'exécute pas, effectuez une mise à jour manuelle dans le Panneau de configuration. Avant de procéder à la mise à jour, suivez les instructions et effectuez les actions requises pour garantir son bon déroulement. Afin de garantir la qualité de nos produits, chaque version de DSM fait l'objet d'une validation rigoureuse. Pour une stabilité optimale, les modèles listés ci-dessous ne recevront pas cette mise à jour et conserveront leur version la plus adaptée. Le correctif de mise à niveau est uniquement disponible au téléchargement sur le Centre de téléchargement Synology, car vous ne recevrez aucune notification concernant cette mise à jour sur votre DSM. Gestion améliorée des certificats KMIP pour se conformer aux politiques d'émission de certificats mises à jour pour les autorités de certification (AC) publiques. L'authentification du client KMIP requiert désormais des certificats émis par une AC privée. Les certificats par défaut de Synology, le certificat QuickConnect et les certificats émis par des AC publiques (par exemple, Let's Encrypt, SSL.com et Sectigo) ne sont pas pris en charge pour l'authentification du client KMIP. Pour des instructions de configuration détaillées, consultez cet article . Compatibilité et installationPour garantir la compatibilité, les paquets suivants seront automatiquement mis à jour ou nécessiteront une mise à jour manuelle vers une version compatible : SnapshotReplication Problèmes résolusCorrection d'un problème où un onduleur USB ne pouvait pas être reconnu après la mise à jour vers DSM 7.4. Correction d'un problème qui empêchait l'utilisation des périphériques USB sur certains modèles après la mise à jour vers DSM 7.4. Gestion du cache améliorée pour une meilleure stabilité du système.

Je viens de jeter un oeil sur mon 718 qui est en DSM 7.3-81180 j' y vais très tres rarement c'est un disque de 8 To , la partition est déja a 8 go , je vais le mettre en DSM 4.1 Edit je viens de mettre le 718 en 4.1 aucun problème c' était une installation neuve a l'origine de 2025 , donc la partition était déja prête pour le 8 Go . On traine bien bien des casseroles avec les versions plus anciennes sudo mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Sun Jan 19 13:01:53 2025 Raid Level : raid1 Array Size : 8388544 (8.00 GiB 8.59 GB) Used Dev Size : 8388544 (8.00 GiB 8.59 GB)

Pourquoi pas, mais tu devras refaire tout ton backup (et 8 To ça peut être long). La capture que j'ai montrée est sur un 218+ qui sert aussi de backup

j'ai aussi mon 718 qui me sert de backup ,je n'ai qu'un seul disque dessus de 8 to ! ? ça vaux le coup de tenter ??

Je n'en ai aucune idée. Je vois bien que vos 3 partitions sont bien en 7.9Go ce qui les prédisposent à passer sur cette capacité. Maintenant, pourquoi le grow ne s'est pas fait automatiquement, tout simplement je pense parce qu'aucun mécanisme n'est là pour le lancer. Si DSM fonctionne correctement sur la partition d'origine, inutile de l'agrandir. Dès lors, on peut effectivement supposer qu'une nouvelle version va détecter l'espace potentiellement dispo et déclencher l'augmentation du RAID1 sinon ça n'aurait pas de sens. Attendons la réponse du support pour mieux comprendre le mécanisme. De mon côté, je vais tenter (pas tout de suite) une opération qui consiste à sortir un des disques de mon 718 pour le formater et reconstruire le groupe. L'idée est de voir si DSM qui s'installe sur le disque partitionne en 7.9Go ou s'il conserve 2.2Go.

bonjour @RAHAN-31 Effectivement, en regardant mes propres relevés que j'ai postés plus haut : mes deux IronWolf ont bien chacun une p1 de 8388608 blocs = 8 GiB, exactement comme tes disques neufs. Donc le nouveau partitionnement physique est déjà là chez moi aussi, sans que md0 (toujours à 2,37 GiB, créé le 03/01/2020 d'après mdadm --detail) en profite. De mon côté, en parallèle, j'ai identifié et corrigé une partie du problème : un environnement Python installé manuellement (pip install en root pour un script maison) occupait ~190 Mo dans /usr/lib/python3.8/site-packages sur la partition système. Je l'ai déplacé vers un environnement virtuel sur mon volume de données, ce qui devrait libérer assez de marge pour tenter la mise à jour même sans agrandir md0 — mais ta piste sur le redimensionnement reste bien plus intéressante à long terme, vu qu'on va sinon rejouer ce même scénario à chaque mise à jour majeure future. J' ai poser ta question exactement comme tu l'as formulée Espace récupéré jusqu'ici : 454 Mo disponibles (cache pip vidé), en attente de nettoyer /usr/lib/python3.8/site-packages (~190 Mo de plus) une fois le feu vert du technicien reçu Script énergie : migré et fonctionnel sur le venv /volume1/scripts/energie_venv, tâche planifiée mise à jour En cours : session support avec le technicien Taiwan ce matin À suivre avec le technicien ! j'attend son feu vert pour la suite

Salut @Pascalou59 , merci de ton retour, Peux tu poser cette question au technicien si il prend contact avec toi ?

Une évolution arrivera (un jour) avec la méthode DNS-PERSIST-01 qui permettra d'émettre et de renouveler un certificat avec un enregistrement DNS TXT persistant. acme.sh est déjà prêt mais il va falloir attendre que les autorités de certification implémentent cette méthode dont la RFC est encore au stade de brouillon (draft). Dans les grandes lignes : # sudo docker exec <containerName> acme.sh --register-account --email <something>@<domain> # sudo docker exec <containerName> acme.sh --make-dns-persist-value --domain <domain> --dns-persist-wildcard # sudo docker exec <containerName> acme.sh --issue --domain <domain> --dns-persistPour l'instant, la dernière commande affiche systématiquement le message d'erreur Cannot get domain token entry <domain> for dns-persist-01.

Bonjour @RAHAN-31 Voici les différentes info que j'ai récupéré et bonne nouvelle j'ai recu ce matin la demande d'accés du support et la notification de connexion de Taiwan est en cours root@NasServeur723:~# du -x --max-depth=1 -h / 4.0K /initrd 2.5M /etc.defaults 42M /.syno 3.0M /.log.junior 48K /.old_patch_info 11M /var.defaults 16K /opt 47M /etc 4.0K /lost+found 4.0K /mnt 18M /.syno_rbd 1.5G /usr 221M /var 4.0K /.system_info 60M /root 4.0K /volumeUSB1 1.9G / sudo cat /proc/partitions major minor #blocks name 1 0 655360 ram0 1 1 655360 ram1 1 2 655360 ram2 1 3 655360 ram3 1 4 655360 ram4 1 5 655360 ram5 1 6 655360 ram6 1 7 655360 ram7 1 8 655360 ram8 1 9 655360 ram9 1 10 655360 ram10 1 11 655360 ram11 1 12 655360 ram12 1 13 655360 ram13 1 14 655360 ram14 1 15 655360 ram15 259 0 488386584 nvme0n1 259 1 488383008 nvme0n1p1 259 2 488386584 nvme1n1 259 3 488383008 nvme1n1p1 8 0 7814026584 sata1 8 1 8388608 sata1p1 8 2 2097152 sata1p2 8 3 7803303248 sata1p3 8 16 7814026584 sata2 8 17 8388608 sata2p1 8 18 2097152 sata2p2 8 19 7803303248 sata2p3 9 0 2490176 md0 250 0 2490176 synorbd_system 252 0 17472 synofsbd_vm_system 7 0 32768 loop0 249 0 9852928 zram0 249 1 9852928 zram1 9 1 2097088 md1 8 32 976762584 usb1 8 33 976759904 usb1p1 135 240 122880 synoboot 135 241 32768 synoboot1 135 242 86016 synoboot2 9 3 488381952 md3 9 2 7803302208 md2 248 0 12288 dm-0 248 1 487587840 dm-1 248 2 7803302208 dm-2 250 1 7803302208 synorbd_1 252 1 60480 synofsbd_vm_1 sudo cat /proc/mdstat Personalities : [raid1] md2 : active raid1 sata1p3[2] sata2p3[3] 7803302208 blocks super 1.2 [2/2] [UU] md3 : active raid1 nvme0n1p1[0] nvme1n1p1[1] 488381952 blocks super 1.2 [2/2] [UU] md1 : active raid1 sata1p2[0] sata2p2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sata1p1[0] sata2p1[1] 2490176 blocks [2/2] [UU] unused devices: <none> 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 : Mon Aug 3 08:31:23 2026 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : 2df02df8:2494f7f0:3017a5a8:c86610be Events : 0.1239 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sata1p1 1 8 17 1 active sync /dev/sata2p1

Bon... vos échanges m'ont fait mettre le nez dans les entrailles de mon propre NAS et je viens de découvrir quelque chose qui change pas mal ma perception du problème 😅 Mon DS1621+ a une longue histoire derrière lui : son DSM remonte à l'époque de DSM 4 et de son DS1512+, puis a été mis à jour au fil des années jusqu'à DSM 7.3 aujourd'hui. Je viens parallèlement de terminer une migration complète de mon stockage : mes anciens HDD ont été remplacés par 3 Toshiba MG11 22 To neufs, actuellement constitués en SHR-1 / Btrfs. Malgré le renouvellement complet des HDD, ma partition système est toujours : root@Synology:~# df -h / Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.4G 852M 62% /Jusque-là, je pensais donc simplement avoir hérité de l'ancien partitionnement système de mon installation historique. Sauf qu'en regardant /proc/partitions, surprise : sata1p1 8388608 sata2p1 8388608 sata3p1 8388608 sata1p2 2097152 sata2p2 2097152 sata3p2 2097152 md0 2490176 md1 2097088Les trois HDD neufs possèdent donc déjà chacun une p1 de 8 Gio, alors que md0 reste dimensionné à environ 2,4 Gio. Si j'ai correctement compris la mécanique, ma situation est donc plutôt : HDD1 p1 = 8 Gio ─┐ HDD2 p1 = 8 Gio ─┼──> md0 RAID1 ≈ 2,4 Gio ──> filesystem / ≈ 2,3 Gio HDD3 p1 = 8 Gio ─┘Autrement dit, le nouveau partitionnement physique existe déjà sur tous les HDD. C'est md0, puis son filesystem, qui n'exploitent pas encore l'espace disponible dans les p1. Et c'est là que j'aurais une question pour @Mic13710, @PiwiLAbruti ou quiconque aurait déjà rencontré ce cas : DSM possède-t-il un mécanisme prévu/supporté permettant de faire croître md0 lorsque TOUS ses membres p1 sont déjà passés à 8 Gio ? Et surtout, si oui, quel est le déclencheur du grow ? Une mise à niveau majeure de DSM ? Une réparation/reconstruction particulière ? Le remplacement du dernier HDD portant l'ancien partitionnement ? Une opération interne de DSM ? Une intervention du support Synology ? Je sais que Linux permet techniquement d'agir sur le RAID puis le filesystem avec mdadm/resize2fs, mais ce n'est volontairement pas la question : je cherche à savoir si DSM possède lui-même un mécanisme prévu pour effectuer cette transition, sans bidouille manuelle sur sa partition système. et @Pascalou59 ton cas pourrait justement être intéressant pour essayer de comprendre cette mécanique. Ton dernier relevé donne actuellement : /dev/system-root 2.3G 1.9G 359M 84% /On connaît par ailleurs ta configuration : DS723+, 32 Go de RAM, 2 SSD M.2 de 500 Go en cache et 2 IronWolf 8 To en RAID1. Avant de chercher, comme le suggère @Mic13710, quels dossiers pourraient être allégés afin de récupérer suffisamment d'espace pour tenter normalement la mise à niveau DSM 7.4, pourrais-tu nous donner : sudo cat /proc/partitions sudo cat /proc/mdstat sudo mdadm --detail /dev/md0Si la dernière commande ne trouve pas /dev/md0, poste simplement son retour : ton DSM présentant actuellement / sous /dev/system-root, /proc/mdstat nous permettra d'abord d'identifier précisément l'array concerné. Ce qui m'intéresse surtout est de savoir si les partitions système p1 de tes deux IronWolf sont encore à ~2,5 Gio ou si elles sont déjà passées à 8 Gio. Si elles sont toutes les deux à 8 Gio alors que ton filesystem système reste à 2,3 Gio, nous serions potentiellement dans la même situation malgré nos architectures DATA différentes : RAID1 chez toi, SHR-1 chez moi. On pourrait alors, dans un second temps, chercher proprement ce qui peut être allégé sans risque dans tes 1,9 Gio occupés, avec l'objectif de permettre à l'upgrade 7.4 que tu souhaites déjà réaliser de démarrer. Et si elle passe, refaire les mêmes relevés après l'upgrade permettrait simplement d'observer si DSM laisse la partition système logique à ~2,3 Gio ou s'il sait exploiter les p1 de 8 Gio déjà présentes.