PiwiLAbruti Posté(e) le 1 septembre 2017 Posté(e) le 1 septembre 2017 Si tu es pressé, tu perdras moins de temps à réinistaller DSM et à refaire une partie de la configuration qu'à chercher une hypothétique solution. Sinon, ça sort de mes compétences. 0 Citer
Mic13710 Posté(e) le 1 septembre 2017 Posté(e) le 1 septembre 2017 Quand Syno, Fenrir, PiwiLAbruti et moi-même nous disons il faut reseter, inutile de tourner virer autour du pot et risquer au passage de tout casser, faut reseter, point final. 0 Citer
Fenrir Posté(e) le 1 septembre 2017 Posté(e) le 1 septembre 2017 Il y a 4 heures, flapinou1 a dit : Ca vient de la commande xz qui foire! Pas obligatoirement (ça peut venir du disque, du noyau, de la ram, d'une libraire ...) -- Je viens de télécharger la version DSM_DS213j_5967 J'ai copié le fichier hda1.tgz sur mon 710 (DSM 5.2.5967-update 4), aucun problème pour extraire le tar avec xz -cd hda1.tgz > SynoUpgrade.tar, donc l'archive est OK (en tout cas quand c'est moi qui la télécharge) Essaye xz sur la même archive que moi avec : xz -l --verbose --verbose hda1.tgz (il y a 2 fois --verbose, c'est normal) et compare (tu devrais avoir exactement le même résultat) xz -l --verbose --verbose hda1.tgz hda1.tgz (1/1) Streams: 1 Blocks: 27 Compressed size: 112.7 MiB (118,220,660 B) Uncompressed size: 411.0 MiB (430,977,904 B) Ratio: 0.274 Check: CRC32 Stream padding: 0 B Streams: Stream Blocks CompOffset UncompOffset CompSize UncompSize Ratio Check Padding 1 27 0 0 118,220,660 430,977,904 0.274 CRC32 0 Blocks: Stream Block CompOffset UncompOffset TotalSize UncompSize Ratio Check CheckVal Header Flags CompSize MemUsage Filters 1 1 12 0 3,941,072 16,777,216 0.235 CRC32 80bda727 20 cu 3,941,046 9 MiB --lzma2=dict=8MiB 1 2 3,941,084 16,777,216 4,299,820 16,777,216 0.256 CRC32 a81bc2c6 20 cu 4,299,795 9 MiB --lzma2=dict=8MiB 1 3 8,240,904 33,554,432 3,716,536 16,777,216 0.222 CRC32 4c329631 20 cu 3,716,510 9 MiB --lzma2=dict=8MiB 1 4 11,957,440 50,331,648 4,748,080 16,777,216 0.283 CRC32 10e10a7c 20 cu 4,748,053 9 MiB --lzma2=dict=8MiB 1 5 16,705,520 67,108,864 4,326,668 16,777,216 0.258 CRC32 2e977e15 20 cu 4,326,641 9 MiB --lzma2=dict=8MiB 1 6 21,032,188 83,886,080 4,511,104 16,777,216 0.269 CRC32 06f479c3 20 cu 4,511,077 9 MiB --lzma2=dict=8MiB 1 7 25,543,292 100,663,296 4,430,500 16,777,216 0.264 CRC32 49119ba0 20 cu 4,430,476 9 MiB --lzma2=dict=8MiB 1 8 29,973,792 117,440,512 5,261,976 16,777,216 0.314 CRC32 e195517b 20 cu 5,261,949 9 MiB --lzma2=dict=8MiB 1 9 35,235,768 134,217,728 4,168,968 16,777,216 0.248 CRC32 ef247122 20 cu 4,168,942 9 MiB --lzma2=dict=8MiB 1 10 39,404,736 150,994,944 4,678,664 16,777,216 0.279 CRC32 a4268430 20 cu 4,678,639 9 MiB --lzma2=dict=8MiB 1 11 44,083,400 167,772,160 4,742,708 16,777,216 0.283 CRC32 3528847b 20 cu 4,742,683 9 MiB --lzma2=dict=8MiB 1 12 48,826,108 184,549,376 4,469,740 16,777,216 0.266 CRC32 4bf580f3 20 cu 4,469,714 9 MiB --lzma2=dict=8MiB 1 13 53,295,848 201,326,592 4,372,480 16,777,216 0.261 CRC32 a2146507 20 cu 4,372,453 9 MiB --lzma2=dict=8MiB 1 14 57,668,328 218,103,808 2,133,440 16,777,216 0.127 CRC32 5f0b1406 20 cu 2,133,413 9 MiB --lzma2=dict=8MiB 1 15 59,801,768 234,881,024 3,429,484 16,777,216 0.204 CRC32 1506bd88 20 cu 3,429,460 9 MiB --lzma2=dict=8MiB 1 16 63,231,252 251,658,240 4,466,828 16,777,216 0.266 CRC32 17dde1aa 20 cu 4,466,804 9 MiB --lzma2=dict=8MiB 1 17 67,698,080 268,435,456 3,995,764 16,777,216 0.238 CRC32 4356e5a9 20 cu 3,995,738 9 MiB --lzma2=dict=8MiB 1 18 71,693,844 285,212,672 1,522,164 16,777,216 0.091 CRC32 6d1fceec 20 cu 1,522,137 9 MiB --lzma2=dict=8MiB 1 19 73,216,008 301,989,888 4,210,748 16,777,216 0.251 CRC32 bede40cc 20 cu 4,210,724 9 MiB --lzma2=dict=8MiB 1 20 77,426,756 318,767,104 5,562,480 16,777,216 0.332 CRC32 a2272449 20 cu 5,562,453 9 MiB --lzma2=dict=8MiB 1 21 82,989,236 335,544,320 4,555,308 16,777,216 0.272 CRC32 b8bc5c11 20 cu 4,555,281 9 MiB --lzma2=dict=8MiB 1 22 87,544,544 352,321,536 15,155,108 16,777,216 0.903 CRC32 28865a48 20 cu 15,155,083 9 MiB --lzma2=dict=8MiB 1 23 102,699,652 369,098,752 7,303,640 16,777,216 0.435 CRC32 6d371aec 20 cu 7,303,614 9 MiB --lzma2=dict=8MiB 1 24 110,003,292 385,875,968 3,038,972 16,777,216 0.181 CRC32 2e7f8ba3 20 cu 3,038,946 9 MiB --lzma2=dict=8MiB 1 25 113,042,264 402,653,184 3,230,612 16,777,216 0.193 CRC32 8c7de59a 20 cu 3,230,588 9 MiB --lzma2=dict=8MiB 1 26 116,272,876 419,430,400 1,820,196 10,321,920 0.176 CRC32 fb5efa76 20 cu 1,820,169 9 MiB --lzma2=dict=8MiB 1 27 118,093,072 429,752,320 127,356 1,225,584 0.104 CRC32 71d2211e 12 -- 127,338 9 MiB --lzma2=dict=8MiB Memory needed: 9 MiB Sizes in headers: No Minimum XZ Utils version: 5.0.0 Il y a 4 heures, PiwiLAbruti a dit : Si tu es pressé Ça fait 2 ans qu'il a le problème Il y a 3 heures, Mic13710 a dit : Quand Syno, Fenrir, PiwiLAbruti et moi-même nous disons il faut reseter ... Pour ma part je ne cherche plus à résoudre, mais juste à comprendre (et si ça corrige tant mieux), c'est simplement par curiosité intellectuelle 0 Citer
flapinou1 Posté(e) le 2 septembre 2017 Auteur Posté(e) le 2 septembre 2017 (modifié) Il y a 17 heures, Fenrir a dit : Pas obligatoirement (ça peut venir du disque, du noyau, de la ram, d'une libraire ...) 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 Modifié le 2 septembre 2017 par flapinou1 0 Citer
Fenrir Posté(e) le 2 septembre 2017 Posté(e) le 2 septembre 2017 il y a 16 minutes, flapinou1 a dit : J'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. Ça élimine le pb de corruption du fichier il y a 16 minutes, flapinou1 a dit : 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) : Ça élimine le pb de corruption des librairies ou des binaires => Reste 3 problèmes possibles (en limitant aux problèmes réalistes) : problème de disque (un test smart ça ne vérifie pas toute la surface du disque, loin de là) => il faut tester le disque avec badblock - @Einsteinium la commande fonctionne de la même manière en DSM5.2 ? problèmes de ressources : si tu as des paquets installés coupe les (surtout ceux qui consomme des ressources, comme l'antivirus, le proxy, ...) problème de ram : j'en doute sinon tu aurais aussi des crash de temps en temps 0 Citer
Einsteinium Posté(e) le 2 septembre 2017 Posté(e) le 2 septembre 2017 @Fenrir ouaip c’est la même : badblocks -nvs /dev/sdX > /volume1/DIR/sdX.log 2>&1 & 0 Citer
flapinou1 Posté(e) le 2 septembre 2017 Auteur Posté(e) le 2 septembre 2017 (modifié) 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. Modifié le 2 septembre 2017 par flapinou1 0 Citer
Fenrir Posté(e) le 2 septembre 2017 Posté(e) le 2 septembre 2017 il y a 3 minutes, flapinou1 a dit : 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!" Je n'ai jamais utilisé cette commande, donc je laisse @Einsteinium répondre (mais je pense que c'est juste un warning) il y a 5 minutes, flapinou1 a dit : J'avais fait les test SMART étendus Comme déjà indiqué, les tests smart ne regardent que certains indicateurs, ils ne vérifient pas tous les bloques du disque. Test xz en écrivant du l'autre partition (au feeling je pense que ça va fonctionner) : xz -tv hda1.tgz > /volume1/test 0 Citer
flapinou1 Posté(e) le 2 septembre 2017 Auteur Posté(e) le 2 septembre 2017 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 0 Citer
Fenrir Posté(e) le 2 septembre 2017 Posté(e) le 2 septembre 2017 À défaut d'avoir des outils de diag sur les syno, il va falloir récupérer le core dump (par défaut sous linux il est dans /tmp, sauf si syno à modifié le comportement) et l'analyser avec objdump ou gdb en espérant y trouver des infos pertinentes. Si tu veux jouer, tu peux essayer de remplacer XZ de ton nas par celui présent dans l'archive (en faisant une sauvegarde avant ou en jouant avec des liens) 0 Citer
Einsteinium Posté(e) le 2 septembre 2017 Posté(e) le 2 septembre 2017 @Fenrir C’est effectivement un test non destructif, mais dans le cas d’un raid... jamais testé.... Cela sauvegarde/test/restaure le secteur s’il contient des données. Je vais voir à faire un tutoriel avec photo sous peu. 0 Citer
flapinou1 Posté(e) le 4 septembre 2017 Auteur Posté(e) le 4 septembre 2017 (modifié) @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 ? :) Modifié le 4 septembre 2017 par flapinou1 0 Citer
Fenrir Posté(e) le 4 septembre 2017 Posté(e) le 4 septembre 2017 Mon avis (et celui des autres) c'est que tu aurais du réinstaller le nas depuis longtemps. Je reste sur mon avis que avis que xz n'est pas en cause mais que c'est un problème "environnemental" (disque, ram, ressources), sinon la commande ne fonctionnerait jamais. Je ne pense pas que ça fasse de casse (mais je ne peux pas en être certain), sauf s'il se sert de xz pour la partie où il écrit dans la rom, là tout est possible (y compris le pire). 0 Citer
flapinou1 Posté(e) le 8 septembre 2017 Auteur Posté(e) le 8 septembre 2017 (modifié) 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 ! ) Modifié le 8 septembre 2017 par flapinou1 0 Citer
Fenrir Posté(e) le 8 septembre 2017 Posté(e) le 8 septembre 2017 Super nouvelle, même si une réinstallation aurait été nettement plus rapide, au moins ça aura permis de faire un peu joujou dans les entrailles de DSM. 0 Citer
Mic13710 Posté(e) le 9 septembre 2017 Posté(e) le 9 septembre 2017 Le 08/09/2017 à 15:10, flapinou1 a dit : Pour info, j'ai continué à avoir le même problème sur les versions suivantes une fois installées ... Le problème n'est donc pas résolu, même si vous avez trouvé le moyen de le contourner. Il y a certainement autre chose qui charge systématiquement le mauvais fichier, et ce n'est probablement pas dans le .pat du DSM. Je continue de penser qu'un reset serait plus approprié. 0 Citer
flapinou1 Posté(e) le 16 septembre 2017 Auteur Posté(e) le 16 septembre 2017 (modifié) Le 09/09/2017 à 16:56, Mic13710 a dit : Le problème n'est donc pas résolu, même si vous avez trouvé le moyen de le contourner. @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): Le 08/09/2017 à 15:10, flapinou1 a dit : Problème qui ne se produisait plus sur les 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! Modifié le 16 septembre 2017 par flapinou1 0 Citer
magic.phip Posté(e) le 10 février 2018 Posté(e) le 10 février 2018 (modifié) Le 17/09/2017 à 00:03, flapinou1 a dit : @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! @flapinou1, tu es presque mon sauveur ! J'ai exactement le même problème, sauf que je suis en 5.1, et que dans cette version busybox n'intègre pas xz. Du coup la manip magique qui consiste à faire pointer /usr/bin/xz sur /bin/busybox ne marche pas ... Je pense qu'en installant la même version de busybox que celle de la 5.2 ça devrait marcher. La question est: comment récupérer cette version ? Modifié le 10 février 2018 par magic.phip 0 Citer
Fenrir Posté(e) le 13 février 2018 Posté(e) le 13 février 2018 Le 2/10/2018 à 23:53, magic.phip a dit : Je pense qu'en installant la même version de busybox que celle de la 5.2 ça devrait marcher. La question est: comment récupérer cette version ? https://usdl.synology.com/download/DSM/release/ 0 Citer
magic.phip Posté(e) le 14 février 2018 Posté(e) le 14 février 2018 (modifié) Le 08/09/2017 à 15:10, flapinou1 a dit : 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...) Cette partie-ci je n'y arrive pas. J'ai beau chercher dans différentes archives .pat, soit elles contiennent un busybox sans xz (toutes les 5.2), soit elles ne contiennent pas de busybox (à partir de 6.0.1). Donc je ne comprends pas comment @flapinou1 a réussi à faire fonctionner xz dans sa busybox. J'ai essayé avec le xz de la 6.0, mais elle nécessite des versions de librairie que ma version (la 5.1) n'a pas: DiskStation> /tmp/xz /tmp/xz: /lib/libc.so.6: version `GLIBC_2.17' not found (required by /tmp/xz) /tmp/xz: /lib/liblzma.so.5: no version information available (required by /tmp/xz) /tmp/xz: /lib/liblzma.so.5: no version information available (required by /tmp/xz) J'ai donc récupéré ces librairies et utilisé LD_LIBRARY_PATH, ça finit par un segfault: DiskStation> LD_LIBRARY_PATH=/tmp/lib /tmp/xz Segmentation fault (core dumped) J'ai récupéré le xz d'une 5.2, je constate une légère amélioration (25% de succès contre 0%) concernant la commande "xz -vt hda1.tgz > XZ_LOG2", mais celle utilisée pour la mise à jour (/usr/bin/xz -cd /upd@te/hda1.tgz > //SynoUpgrade.tar), elle, échoue quand même à chaque tentative. J'ai stoppé tous les services, pas d'amélioration. Quand j'aurai un peu de temps, je tenterai un chroot contenant le hda1 d'une 6.0 pour voir si xz y démarre correctement. Je remplacerai alors le xz d'origine par celui du chroot. Je ne comprends pas trop comment un double reset pourrait résoudre ce problème, étant donné que c'est la commande /usr/bin/xz elle-même qui échoue. Comment pourrait-elle se comporter mieux après un double reset ? Pour info un autre gars a rencontré exactement le même pb en 6.0: https://forum.synology.com/enu/viewtopic.php?f=267&t=116216 . Malheureusement pour moi, la manip qu'il préconise n'a pas permis de régler le problème chez moi. Modifié le 14 février 2018 par magic.phip 0 Citer
magic.phip Posté(e) le 29 mars 2018 Posté(e) le 29 mars 2018 (modifié) Je doute que ça intéresse grand monde, mais j'ai réussi à m'en sortir sans double reset. J'ai recompilé une busybox à partir des sources avec la toolchain correspondant à mon Syno, en la configurant pour n'y embarquer que les utilitaires d'archivage, et j'ai utilisé le binaire obtenu en guise de xz. La décompression de hda1.tgz qui échouait jusqu'alors s'effectue sans problème. J'ai pu faire une première mise à jour vers une version intermédiaire 5.2, qui elle-même avait également une version de xz non fonctionnelle (seg fault), j'ai donc refait la manip de recopier mon binaire à la place de xz, et là encore ça s'est bien passé. Là je suis en 6.0.3 et j'ai encore le problème, je refais donc la même manip. Modifié le 29 mars 2018 par magic.phip 0 Citer
Mic13710 Posté(e) le 30 mars 2018 Posté(e) le 30 mars 2018 Il y a 8 heures, magic.phip a dit : j'ai réussi à m'en sortir sans double reset. Il y a 8 heures, magic.phip a dit : Là je suis en 6.0.3 et j'ai encore le problème, je refais donc la même manip. 1 mois et demi pour en arriver pratiquement au même point, votre persévérance force le respect. Il y a longtemps que j'aurais jeté l'éponge. Après cette version, il y a la 6.1.6, avec peut-être une étape intermédiaire. Je pense toujours qu'un double reset reste la meilleure solution. 0 Citer
magic.phip Posté(e) le 31 mars 2018 Posté(e) le 31 mars 2018 (modifié) Si ça peut vous rassurer je n'ai pas passé un mois et demi dessus :) Plutôt un mois et demi à ne pas m'en occuper et une bonne soirée à trouver la bonne variable d'environnement pour la cross-compil. L'objectif étant de mettre à jour le DSM en 6.1.6, et d'y être parvenu, je ne considère pas être rendu "pratiquement au même point". J'étais bloqué sur une version, avec mise à jour impossible, ce qui est quand même un comble pour ce type de produit. Préconiser un reset pour permettre une mise à jour, ce n'est pas ce que j'appelle une solution acceptable, d'autant que visiblement, mon NAS a le problème à chaque version ce qui signifierait potentiellement un double reset à chaque mise à jour ... Après, je suis d'accord que même si la version xz de busybox se comporte correctement quelle que soit version la version de DSM, le fait que le binaire de base ne fonctionne sur aucune version chez moi de la 5.1 à la 6.1, montre qu'il y a bien un problème lié à mon matériel et/ou ma config, et qu'un double reset pourrait le résoudre; mais étant donné que je ne suis pas le seul à l'avoir rencontré, et que par ailleurs mon NAS se comporte correctement, je n'en ai aucune garantie. Par curiosité, ce serait intéressant de faire l'essai, mais alors vraiment par curiosité ;) Quoiqu'il en soit, à ce jour j'ai une solution qui marche, et qui pourra peut-être aider d'autres personnes à éviter un double reset. Précision: la cross compil de la busybox n'est à faire qu'une seule fois bien sûr, ensuite ce n'est plus qu'une question de backuper xz et de le remplacer par celui de la bb, donc un peu fastidieux, mais moins qu'un double reset. Modifié le 31 mars 2018 par Mic13710 inutile de répéter le message précédent si ça n'apporte rien de plus à la compréhension 0 Citer
DaffY Posté(e) le 31 mars 2018 Posté(e) le 31 mars 2018 Il y a 7 heures, magic.phip a dit : Précision: la cross compil de la busybox n'est à faire qu'une seule fois bien sûr, ensuite ce n'est plus qu'une question de backuper xz et de le remplacer par celui de la bb, donc un peu fastidieux, mais moins qu'un double reset. Moins qu'un double reset ???? Je viens de lire tout le thread... J'avoue que je ne comprend pas trop... sauf si des données essentielles étaient sur le disque (et dans ce cas en ayant accès aux entrailles du NAS on pouvait les "sortir".) mais je pense que ce fut plus rapide et sécure[le double reset]. Mais c'est un avis personnel (à priori un peu partagé ici aussi) En tout cas je salue la persévérance et la réussite de l'opération. Bravo et chapeau !! 0 Citer
magic.phip Posté(e) le 14 avril 2018 Posté(e) le 14 avril 2018 Le 31/03/2018 à 19:35, daffy a dit : Moins qu'un double reset ???? Je viens de lire tout le thread... J'avoue que je ne comprend pas trop... sauf si des données essentielles étaient sur le disque (et dans ce cas en ayant accès aux entrailles du NAS on pouvait les "sortir".) mais je pense que ce fut plus rapide et sécure[le double reset]. Mais c'est un avis personnel (à priori un peu partagé ici aussi) En tout cas je salue la persévérance et la réussite de l'opération. Bravo et chapeau !! Merci pour le compliment :) Je comprends qu'on puisse trouver l'opération inutile et lourdingue, mais d'une part c'était une question de principe ;) (je n'accepte pas l'idée de perdre toute sa config pour juste une mise à jour), et d'autre part surtout il s'agissait de trouver un moyen de contourner le problème si jamais il se reproduit pour moi ou pour d'autres. Pour résumer, une fois la version de busybox recompilée avec xz dedans (prendre la pièce jointe pour éviter cette étape - version compilée pour DS213j mais vu que c'est de l'ARM ça devrait fonctionner pour mal de modèles), il suffit de faire (en root): mv /usr/bin/xz /usr/bin/xz.backup ln -s (chemin_vers_busybox_recompilée)/busybox /usr/bin/xz (C'est en cela que je trouve que c'est moins fastidieux qu'un double reset). Pour ceux que ça intéresse, pour compiler une busybox, il faut récupérer les sources de busybox (https://git.busybox.net/busybox/), et le cross-compilo correspondant au proc de son Syno (https://sourceforge.net/projects/dsgpl/files/DSM 5.1 Tool Chains/), et ensuite lancer la cross-compil (ici sur du Linux): # Install cross-compilator: sudo mkdir /opt/Cross-Tools-Syno cd /opt/Cross-Tools-Syno/ tar xf /tmp/gcc445_glibc211_softfp_armada370-GPL.tgz # Install bsybox sources: mkdir busybox-1_28_3 cd busybox-1_28_3 tar xf /tmp/busybox-1_28_3.tar.gz # Cross-compil busybox sudo make menuconfig # Unselect all but "Archival utilities" section sudo make CROSS_COMPILE="/opt/Cross-Tools-Syno/usr/local/soft/bin/arm-marvell-linux-gnueabi-" scp busybox user@syno:path_to_new_busybox A l'étape make menuconfig on peut décider de ne garder que la partie "Archival utilities" pour gagner en temps de compilation et en taille de binaire final busybox 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.