MAJ impossible du NAS !

[PiwiLAbruti]

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.

[Mic13710]

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.

[Fenrir]

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

[flapinou1]

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

[Fenrir]

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

[Einsteinium]

@Fenrir ouaip c’est la même :

badblocks -nvs /dev/sdX > /volume1/DIR/sdX.log 2>&1 &

[flapinou1]

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

[Fenrir]

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

[flapinou1]

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

 

[Fenrir]

À 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)

[Einsteinium]

@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.

[flapinou1]

@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

[Fenrir]

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).

[flapinou1]

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

[Fenrir]

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.

[Mic13710]

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é.

[flapinou1]

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

[magic.phip]

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

[Fenrir]

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/

[magic.phip]

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

[magic.phip]

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

[Mic13710]

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.

[magic.phip]

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

[DaffY]

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 !!

 

[magic.phip]

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