magic.phip

Bonjour, comment fait-on stp ? (Je connais la méthode d'installation manuelle par le gestionnaire de paquets, mais y'-t-il une autre méthode comme une commande en ligne via ssh ?)

Bonjour, désolé si cette question a déjà été posée mais je n'ai pas trouvé: comment faire pour installer une version du paquet docker avec un Syno incompatible ? J'ai un DS216se (Marvell Armada 370), et n'ai pas trouvé de psk accepté par le DSM. J'ai tenté avec celui du DS216+, sans succès. Merci d'avance pour vos aides

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

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.

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.

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.

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