flapinou1

Non, pas en rapport avec le certificat "Let's encrypt".

Bonjour, Il y a quelques années, il fallait se connecter régulièrement au compte Synology (https://account.synology.com/) pour éviter une expiration du compte OU une expiration du DDNS (je ne sais plus). Cela parle t-il à quelqu'un ? Est-ce cela est toujours d'actualité ou cette politique a t-elle changée ? Merci.

@Mic13710: Si justement, le problème était résolu après (plus besoin de contourner dans un processus de MAJ après DSM 6.x.x): Pourquoi? Le filelinux system est différent sur DSM 6 par rapport au 5 (la majorité des fichiers binaires de commandes se trouvent intégrées à la busybox dans /bin), du coup le code de xz ayant évolué ou changé -> je n'ai plus eu de soucis sur l'exécution de la commande xz qui est appelé quand on décompresse un fichier .tgz (qui lui même est dans le .PAT) pour une mise à jour du DSM. Ensuite, le Reset: pourquoi pas pour une solution rapide mais la sauvegarde de configuration (fichier .conf) est incomplète et donc impossible de retrouver la même conf d'origine (ca oblige à faire une centaine de copies d'écran pour tout vérifier..). Et c'est toujours stimulant intellectuellement de trouver la vrai raison (expliqué du coup dans mon dernier post). Merci en tout cas!

Bonne nouvelle... problème résolu J'ai donc remplacé le fichier xz de base (du rep système /usr/bin) par un nouveau fichier xz qui pointait en lien vers une busybox. (xz utilise du coup un code différent, celui intégré à la busybox...) Le processus de MAJ ne plantait plus ( sur la commande /usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar). Résultat -> MAJ réussie vers la dernière version DSM 6.1.3-15152 Update 4 sans Reset du nas Je pense que le souci venait soit du package xz-utils (dont Synology n'intégrait pas la dernière version dispo) soit de l'ordre à respecter des MAJ successifs à faire sur un NAS (4-.2 vers 5.0 puis 5.0 vers 5.1 par exemple...) qui s'il n'est pas respecté peut causer du soucis dans les librairies? ou alors Synology a peut-être eu un raté dans sa qualité de recette sur qqes cas particuliers... Pour info, j'ai continué à avoir le même problème sur les versions suivantes une fois installées ... 5.2-5592 .. 5.2-5592.. 5.2-5967 dans le processus de MAJ (à chaque fois j'ai du changé le nouveau xz apporté par la MAJ pour mettre à jour vers une nouvelle version). Problème qui ne se produisait plus sur les DSM 6.x.x car la plupart des commandes (dont xz) étaient en lien vers /bin/busybox. Merci @Fenrir (sans oublier @Mic13710 et les autres ! )

@Fenrir: J'ai testé le xz que j'ai de base sur un autre fichier simple .tar.xz (erreur segFault de temps en temps seulement) et sur un autre gros fichier (une archive quelconque en tar.xz et également erreur segFault très souvent) donc ne provient pas du fichier quoi qu'il arrive. J'ai creusé ta piste de remplacer le XZ par celui de l'archive. Si j'invoque celui dans l'archive (de DSM_DS213j_7321.pat par exemple que tu m'as filé) qui est en lien celui-la vers busybox (lrwxrwxrwx 1 root root 17 Jun 18 2013 xz -> ../../bin/busybox) alors cette commande XZ ne me donne plus aucune erreur: En résumé: - si xz est en fichier de 55Kb et est invoqué , la commande xz plante - si xz est un lien vers busybox, la commande xz marche parfaitement sur hda1.tgz ou autre fichier... J'hésite à remplacer le fichier /usr/bin/xz de mon système par un lien xz vers la busybox car j'ai peur que ca provoque des régressions autre part. Ton avis ? :)

Jme suis placé dans un répertoire au niveau de /volume1/homes/ et j'ai fait: DiskStation> xz -vt hda1.tgz > XZ_LOG2 hda1.tgz (1/1) 100 % 112.7 MiB / 411.0 MiB = 0.274 8.3 MiB/s 0:49 DiskStation> xz -vt hda1.tgz > XZ_LOG2 hda1.tgz (1/1) Segmentation fault (core dumped)MiB = 0.258 7.7 MiB/s 0:15 45 s Le premier coup a marché directement, pas le deuxième. Ok @Fenrirpour attendre la réponse de Einsteinium concernant badblocks

On dirait que pcq hda1.tgz est volumineux et prend du temps à décompresser, il se bloque aléatoirement en cours de route avec un segfault. (jusqu'à un success mais après plusieurs tentatives). (Et c'est quelque chose qui posait jamais soucis avec les premières MAJ du DSM). - Par rapport au pb de disque: @Fenrir: La commande badblocks -nvs /dev/sda > /volume1/DIR/sda.log 2>&1 & me donne un message d'erreur "/dev/sda is apparently in use by the system; it's not safe to run badblocks!" (j'ai deux disque WD Red neuf de 1To en Raid Synology SHR, ici sda et sdb). Je sais pas si je peux unmount ou swapoff facilement ... J'avais fait les test SMART étendus du constructeur (copie d'écran) pour chaque disque (sous Windows) sans erreur. -Par rapport au pb de RAM: Comme tu dis, je pense pas qu'il y ait un pb au niveau de la ram, je viens de refaire 3 Memory Test avec Synology Assistant et j'ai aucune erreur (de même jamais eu de crash). - Par rapport au pb de ressources: J'ai qu'un seul paquet d'installé: Cloud Station. En gros, le proc est toujours à quelques % d'utilisation seulement et la RAM à 35% (sur 512MB). Jte met la copie d'écran d'utilisation des ressources courantes sur mon NAS (en triant par ordre croissant d'utilisation du CPU): Quand j'utilise la commande xz -t hda1.tgz, le CPU monte à 100% et la RAM de quelques % seulement en plus.

Ok, j'avais envoyé le Kernel log, fait les tests SMART des 2 DD à fond, et tester la ram ok également. Donc peut-être un pb de librairie? @FenrirJ'ai fait ton test xz -l --verbose --verbose hda1.tgz et en vérifiant ligne par ligne et chiffre par chiffre, j'ai exactement le même résultat que toi. En enchainant sur un xz -t hda1.tgz ou un xz -cd hda1.tgz > SynoUpgrade.tar, j'ai un segmentation fault (core dumped) sur les 2 commandes. Par ailleurs j'ai fait 4 tests: 1) un XZ qui s'exécutait bien avant sur un hda1.tgz d'un vieux DSM_DS213j_3222.pat (puisque j'ai déjà mis à jour mon NAS avec) et maintenant me donne l' erreur: DiskStation> tar -xvf DSM_DS213j_3222.pat DiskStation> xz -t hda1.tgz Segmentation fault (core dumped) 2) J'ai rapatrié ce même hda1.tgz sur Windows et j'ai exécuté sur dos la fonction xz (marche sans problème) après avoir téléchargé xz-utils: C:\Users\Laurent\Desktop\xz-5.0.5-windows\bin_i486>xz -tv hda1.tgz hda1.tgz (1/1) 100 % 61,9 MiB / 250,8 MiB = 0,247 40 MiB/s 0:06 3) Sur le NAS, j'ai executé un XZ sur un autre tar.xz et ca marche: DiskStation> xz -vt xz-5.0.5.tar.xz xz-5.0.5.tar.xz (1/1) 100 % 906.9 KiB / 5,030.0 KiB = 0.180 4) Enfin le test le plus intéressant, c'est que j'ai réussi à faire finalement marcher xz -tv hda1.tgz en retapant plusieurs fois la commande!! (on voit l'indicateur de progress en cours qui s'arrete soit à 1% soit à 12% soit à 33% avant la segmentation fault sauf la dernière qui affiche 100% et qui du coup ne fait pas de segmentation fault) : DiskStation> xz -vt hda1.tgz hda1.tgz (1/1) 1.1 % 728.4 KiB / 4,549.1 KiB = 0.160 xz: hda1.tgz: Compressed data is corrupt 1.1 % 728.4 KiB / 4,549.1 KiB = 0.160 DiskStation> xz -vt hda1.tgz hda1.tgz (1/1) Segmentation fault (core dumped)MiB = 0.280 7.6 MiB/s 0:05 DiskStation> xz -tv hda1.tgz hda1.tgz (1/1) 100 % 61.9 MiB / 250.8 MiB = 0.247 10 MiB/s 0:24 Même principe sur cette copie d'écran: @Mic13710@PiwiLAbruti: je suis d'accord avec vous que un double reset irait plus vite mais c'est aussi par curiosité intellectuelle et la solution aidera un autre gars qui rencontre ce même pb. Par ailleurs, même après un double reset, je suis pas sur à 100% que le pb soit corrigée car les hda1.tgz seront les mêmes, le matos n'aura pas changé et ca fera toujours appel à xz

@PiwiLAbruti: Tout ca, j'avais testé au début (voir mon premier post à ce sujet), Je précise que j'ai pas de réponse sur l'intégrité, c'est la commande qui teste l'intégrité (donc toujours xz) qui plante de même que celle la quand je l'execute en terminal: DiskStation> xz -cd hda1.tgz > SynoUpgrade.tar Segmentation fault (core dumped) Ca vient de la commande xz qui foire!

Merci @PiwiLAbruti pour ta réponse. Effectivement, j'ai encore essayé mais il n'arrive pas à décompresser le package hda1.tgz. Je pense que ya un bug de la commande xz du package xz-utils (d'où le segfault qui vient généralement d'un dev baclé...) Sep 1 11:59:21 DiskStation updater: updater.c:4987 Decompress hda1.tgz to SynoUpgrade.tar Sep 1 11:59:22 DiskStation updater: updater.c:285 UPDTExecute(285): failed to execute cmd=[/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar], ret = 139 Sep 1 11:59:22 DiskStation updater: updater.c:4873 UPDTExecute(/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar) fail. Sep 1 11:59:22 DiskStation updater: updater.c:6210 Fail to move/extract hda1 and packages!! @Fenrir: Merci pour ton info. Jvais quand même essayer de mettre à jour le package xz-utils qui est à la version 5.0.5 alors qu'on en est à 5.0.8 actuellement. update.c:280 renseignant simplement le numéro de ligne 280 du code où il se trouve (update.c) je pense ? En allant fouiller la release note de xz-utils, y'a eu qqes bug fixs. Ca m'embêterait si le xz plante encore après le double reset étant donné que ça sera le même gros hda.tgz à décompress... Au passage, quand je test manuellement de mon coté l'intégrité de hda1.tgz, bizarre...: DiskStation> xz -t hda1.tgz Segmentation fault (core dumped)

Oui @Fenrir, on dirait que tout vient de failed to execute cmd=[/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar], ret = 139 Il faudrait un spécialiste de la commande xz qui sert à compresser/décompresser. Il arrive pas à décompresser hda1.tgz vers SynoUpgrade.tar et renvoie l'erreur 139? Pas assez de ram? hda1.tgz est gros, une bonne 100aine de Mo je dirais. J'ai pensé à mettre à jour le package xz-utils sait-on jamais (et pas moyen de savoir aussi à quoi correspond ce code 139).

Merci @Fenrir pour ta réponse rapide: Alors dans var/log/synoservice.log (rien de spécial): May 27 00:51:33 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28176]: service_pause_by_reason.c:27 synoservice: pause [syslog-client] by reason [dsm-upgrade] ... May 27 00:51:33 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28176]: service_pause.c:39 synoservice: [syslog-client] pausing ... May 27 00:51:33 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28176]: service_pause.c:48 synoservice: [syslog-client] is already disable/pause. May 27 00:51:33 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28176]: service_pause.c:89 synoservice: [syslog-client] paused. May 27 00:55:56 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28077]: service_start.c:108 synoservice: [img_backupd] starting ... May 27 00:55:56 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28077]: service_start.c:206 synoservice: [img_backupd] started. Dans var/log/synolog.log (rien de spécial): May 27 00:51:33 DiskStation syslog-ng[733]: Referenced filter rule not found in filter() expression; rule='f_docker' May 27 00:51:33 DiskStation syslog-ng[733]: Referenced filter rule not found in filter() expression; rule='f_docker' May 27 00:51:33 DiskStation syslog-ng[733]: Configuration reload request received, reloading configuration; May 27 00:56:10 DiskStation syslog-ng[733]: Referenced filter rule not found in filter() expression; rule='f_docker' May 27 00:56:10 DiskStation syslog-ng[733]: Referenced filter rule not found in filter() expression; rule='f_docker' May 27 00:56:10 DiskStation syslog-ng[733]: Configuration reload request received, reloading configuration; Dans var/log/synolog/synolog.log (juste le failed de l'update) : info 2017/05/27 00:50:56 admin: Start install [DSM 6.0-8754] automatically. info 2017/05/27 00:51:11 SYSTEM: [Cloud Station] service was stopped. info 2017/05/27 00:51:14 SYSTEM: System successfully stopped [Network Backup Volume Dest ination]. info 2017/05/27 00:51:15 SYSTEM: System successfully stopped [Windows file service]. info 2017/05/27 00:51:16 SYSTEM: System successfully stopped [Apple file service]. info 2017/05/27 00:51:17 SYSTEM: System successfully stopped [SFTP service]. info 2017/05/27 00:51:18 SYSTEM: System successfully stopped [Bonjour Printer Broadcast] . info 2017/05/27 00:51:29 SYSTEM: System successfully stopped [WebDAV (HTTPS) service]. info 2017/05/27 00:51:32 SYSTEM: System successfully stopped [FTPS service]. info 2017/05/27 00:55:56 admin: System successfully started [Network Backup Volume Dest ination]. info 2017/05/27 00:55:59 admin: System successfully started [Windows file service]. err 2017/05/27 00:55:59 admin: Automatically install [DSM 6.0-8754] failed. Par contre dans var/log/messages: May 27 00:51:34 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28077]: Upgrade.cpp:297 Executing [//upd@te/updater -v -x ] May 27 00:51:34 DiskStation updater: updater.c:5694 Start of the updater... May 27 00:51:34 DiskStation updater: updater.c:2695 orgBuildNumber = 5565, newBuildNumber=8754 May 27 00:51:34 DiskStation updater: updater.c:2829 [CheckPackageSize] Find [1] internal volume, external volume count= [0] May 27 00:51:34 DiskStation updater: updater.c:2849 CheckPackageSize, err=0 May 27 00:51:34 DiskStation updater: updater.c:5945 ==== Start flash update ==== May 27 00:51:34 DiskStation updater: updater.c:5977 This is junior, gszDevMtdPartition=[/dev/mtd5] May 27 00:51:34 DiskStation updater: updater.c:6262 number of partitions = [6] May 27 00:51:34 DiskStation updater: updater.c:6267 [RedBoot] 0xF0000000 0x000C0000 0x000B4F54 May 27 00:51:34 DiskStation updater: updater.c:6267 [zImage] 0xF00C0000 0x002D0000 0x0020C230 May 27 00:51:34 DiskStation updater: updater.c:6267 [rd.gz] 0xF0390000 0x00440000 0x0030D56B May 27 00:51:34 DiskStation updater: updater.c:6267 [vendor] 0xF07D0000 0x00010000 0x00010000 May 27 00:51:34 DiskStation updater: updater.c:6267 [RedBoot Config] 0xF07E0000 0x00010000 0x00010000 May 27 00:51:34 DiskStation updater: updater.c:6267 [FIS directory] 0xF07F0000 0x00010000 0x00000600 May 27 00:51:34 DiskStation updater: flashsize = 0x00800000, eraseblock = 0x00010000 May 27 00:51:34 DiskStation updater: Skipping RedBoot.msys due to the checksum matches May 27 00:51:34 DiskStation updater: PATCHINFO: part[RedBoot] file[RedBoot.msys] start = [0xF0000000] size[0x786432] datalen=[0x000B4F54] nblock[0] balance[0] fneedupdate[0] May 27 00:51:34 DiskStation updater: PATCHINFO: part[zImage] file[zImage] start = [0xF00C0000] size[0x2949120] datalen=[0x0020ECA0] nblock[33] balance[12] fneedupdate[1] May 27 00:51:34 DiskStation updater: PATCHINFO: part[rd.gz] file[rd.bin] start = [0xF0390000] size[0x4456448] datalen=[0x00366693] nblock[55] balance[13] fneedupdate[1] May 27 00:51:34 DiskStation updater: UPDTInitPatchInfo(3677): file [vendor] not included in the patch package May 27 00:51:34 DiskStation updater: PATCHINFO: part[vendor] file[vendor] start = [0xF07D0000] size[0x65536] datalen=[0x00010000] nblock[0] balance[0] fneedupdate[0] May 27 00:51:34 DiskStation updater: UPDTInitPatchInfo(3677): file [RedBoot Config] not included in the patch package May 27 00:51:34 DiskStation updater: PATCHINFO: part[RedBoot Config] file[RedBoot Config] start = [0xF07E0000] size[0x65536] datalen=[0x00010000] nblock[0] balance[0] fneedupdate[0] May 27 00:51:34 DiskStation updater: UPDTInitPatchInfo(3677): file [FIS Directory] not included in the patch package May 27 00:51:34 DiskStation updater: PATCHINFO: part[FIS Directory] file[FIS Directory] start = [0xF07F0000] size[0x65536] datalen=[0x00000600] nblock[0] balance[0] fneedupdate[0] May 27 00:51:34 DiskStation updater: szCmd=[/bin/rm -rf /upd@te/b@ckup; /bin/mkdir -p /upd@te/b@ckup] May 27 00:51:34 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd0" of="/upd@te/b@ckup/mtd_RedBoot" bs=16384] May 27 00:51:35 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd1" of="/upd@te/b@ckup/mtd_zImage" bs=16384] May 27 00:51:36 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd2" of="/upd@te/b@ckup/mtd_rd.gz" bs=16384] May 27 00:51:39 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd3" of="/upd@te/b@ckup/mtd_vendor" bs=16384] May 27 00:51:39 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd4" of="/upd@te/b@ckup/mtd_RedBoot Config" bs=16384] May 27 00:51:39 DiskStation updater: UPDTBackupOldPartition(3772): command=[/bin/dd if="/dev/mtd5" of="/upd@te/b@ckup/mtd_FIS directory" bs=16384] May 27 00:51:39 DiskStation updater: UPDTDoPatch: skip updating [RedBoot] May 27 00:51:39 DiskStation updater: updater.c:3918(UPDTDoPatch) Try to Erase MTD Partition(/dev/mtd1), [0/3]... May 27 00:52:30 DiskStation updater: updater.c:3972(UPDTDoPatch) Try to Write MTD Partition(/dev/mtd1), [0/3]... May 27 00:52:36 DiskStation updater: updater.c:3978(UPDTDoPatch) Try to Verify MTD Partition(/dev/mtd1), [0/3]... May 27 00:52:39 DiskStation updater: UPDTDoPatch: Finish updating [zImage] May 27 00:52:39 DiskStation updater: updater.c:3918(UPDTDoPatch) Try to Erase MTD Partition(/dev/mtd2), [0/3]... May 27 00:53:52 DiskStation updater: updater.c:3972(UPDTDoPatch) Try to Write MTD Partition(/dev/mtd2), [0/3]... May 27 00:54:02 DiskStation updater: updater.c:3978(UPDTDoPatch) Try to Verify MTD Partition(/dev/mtd2), [0/3]... May 27 00:54:06 DiskStation updater: UPDTDoPatch: Finish updating [rd.gz] May 27 00:54:06 DiskStation updater: UPDTDoPatch: skip updating [vendor] May 27 00:54:06 DiskStation updater: UPDTDoPatch: skip updating [RedBoot Config] May 27 00:54:06 DiskStation updater: UPDTDoPatch: skip updating [FIS Directory] May 27 00:54:06 DiskStation updater: updater.c:6309 ==== Finish flash update ==== May 27 00:54:06 DiskStation updater: updater.c:4678 already mounted. dev=/dev/md0, path=/tmpRoot May 27 00:54:06 DiskStation updater: updater.c:4781 successfully backup image for System Migration in path (/tmpRoot/.syno/patch). May 27 00:54:06 DiskStation updater: updater.c:5077 Decompress hda1.tgz to SynoUpgrade.tar May 27 00:54:11 DiskStation updater: updater.c:280 UPDTExecute(280): failed to execute cmd=[/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar], ret = 139 May 27 00:54:11 DiskStation updater: updater.c:4859 UPDTExecute(/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar) fail. May 27 00:54:12 DiskStation updater: updater.c:6325 Fail to move/extract hda1 and packages!! May 27 00:54:12 DiskStation updater: UPDTRollBack: skip recoverying [RedBoot] May 27 00:54:12 DiskStation updater: updater.c:4106(UPDTRollBack) SYNOMTDErasePartition(/dev/mtd1)... May 27 00:54:46 DiskStation updater: UPDTRollBack(4126): command=[/bin/dd if="/upd@te/b@ckup/mtd_zImage" of="/dev/mtd1" bs=131072] May 27 00:54:55 DiskStation updater: updater.c:4106(UPDTRollBack) SYNOMTDErasePartition(/dev/mtd2)... May 27 00:55:44 DiskStation updater: UPDTRollBack(4126): command=[/bin/dd if="/upd@te/b@ckup/mtd_rd.gz" of="/dev/mtd2" bs=131072] May 27 00:55:56 DiskStation updater: UPDTRollBack: skip recoverying [vendor] May 27 00:55:56 DiskStation updater: UPDTRollBack: skip recoverying [RedBoot Config] May 27 00:55:56 DiskStation updater: UPDTRollBack: skip recoverying [FIS Directory] May 27 00:55:56 DiskStation updater: updater.c:2531 No need to reset reason for v.5565 May 27 00:55:56 DiskStation updater: updater.c:6462 Failed to accomplish the update! (errno = 26) May 27 00:55:56 DiskStation synoupgrade_SYNO.Core.Upgrade[1].start[28077]: Upgrade.cpp:300 failed to execute updater, r=-1095381132 May 27 00:56:09 DiskStation synoservicecfg: servicecfg_root_object_get.c:115 service config for service [] is not exist

@Fenrir Le système de fichier est en ext4 Le synoupdate.log me donne: DiskStation> cat synoupdate.log ... (répétition toutes les semaines) 2017/05/20 00:51:38 Start of the update... 2017/05/20 00:51:38 Upgrade from version 5.2.0.5565 to version 6.0.3.8754 2017/05/20 00:56:00 Failed to accomplish the update! (errno = 26) 2017/05/27 00:51:34 Start of the update... 2017/05/27 00:51:34 Upgrade from version 5.2.0.5565 to version 6.0.3.8754 2017/05/27 00:55:56 Failed to accomplish the update! (errno = 26) ... As t-on la correspondance du numéro d'erreur qq part ? Merci

Salut @Fenrir Voici ce résultat de la commande df -h que j'ai tappé sous putty: DiskStation> df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.4G 768M 1.5G 34% / /tmp 249M 640K 249M 1% /tmp /run 249M 1.4M 248M 1% /run /dev/shm 249M 0 249M 0% /dev/shm /dev/vg1000/lv 913G 290G 623G 32% /volume1 Donc la partition système n'est pas full ( @Mic13710 ). Qu'est ce qui peut donc bloquer la MAJ à 79% systématiquement ? Au passage, un autre type a eu exactement le même problème de MAJ, il est bloqué à DSM 5.2-5565 update 2 à croire que cette version avait un soucis :

Bonjour, Je relance un coup à tout hasard :) Une âme charitable connaîtrait t-elle cette commande magique qui corrige le pb de la MAJ du DSM ? (proposé par Mic13710 dans son dernier post)