Just1

Bonjour Fenrir et merci pour ton aide. C'est vraiment handicapant que "certains paquets se mettent mal à jour" ! Comme a pu l'expliquer lvdtime, la restauration d'une sauvegarde (fichier sbk) depuis l'interface de DSM ne fonctionne pas. Effectivement, les groupes "Directory Clients" et "Directory Consumers" sont nouveaux et n'existaient pas dans la version précédente de Directory Server. L'interface de DSM ne permet pas de les supprimer. Dans notre cas nous avons deux bases LDAP répliquées sur deux NAS différents, l'un sous DSM 6 (mis à jour) l'autre sous DSM 5 (non mis à jour). Voici ce que nous avons fait pour que tout rentre dans l'ordre : Sur le NAS sous DSM 5 (celui dont le serveur LDAP fonctionne) : Exporter les parties "users" et "groups" au format LDIF avec JXplorer Noter la valeur des "gidNumber" et "uidNumber" lues dans JXplorer dans la partie "synoconf > CurID" de l'arborescence Sur le NAS sous DSM 6 (celui dont le serveur LDAP ne fonctionne plus) : Désinstaller le paquet Directory Server Ré-installer le paquet Directory Server Ouvrir JXplorer Vider le contenu de "groups" et le contenu de "users" (car importer une arborescence sur l'arborescence n'a pas fonctionné pour nous) Éditer les valeurs des paramètres "synoconf > CurID > gidNumber" et "synoconf > CurID > uidNumber" pour leur appliquer les valeurs identiques à celles du serveur LDAP fonctionnel Importer la sauvegarde LDIF des "users" Importer la sauvegarde LDIF des "groups" Éventuellement redémarrer le Directory Server et constater que ça fonctionne (si tout s'est bien passé...) Nous n'avons pas recréé les groupes "Directory Clients" et "Directory Consumers", je ne sais pas quel en sera l'impact. C'est une information très précieuse et on peut à mon avis utiliser le LDIF du *.sbk et se calquer sur ma procédure décrite plus haut pour restaurer n'importe quelle installation. Attention il faudra peut-être éditer manuellement le fichier LDIF pour en extraire la partie "users" et la partie "groups".

Bonjour à tous, Ce matin j'ai mis à jour vers DSM 6.0 un serveur Synology RS812+ qui tournait jusque là sous DSM 5.x . Le serveur LDAP n'est malheureusement plus accessible depuis... Après mise à jour des nombreux paquets incompatibles DSM 6.0, la situation ne s'améliore pas. Lorsque je vais sur la page du paquet Directory Server, la case "activer le serveur LDAP" est cochée. Je décoche et j'applique, puis je recoche et j'applique, et là j'ai un message "Identifiants non valides. Veuillez vérifier votre nom compte et mot de passe." (je suis en mode "provider"). Je suppose qu'il s'agit du FQDN et du mot de passe car il n'y a rien d'autre, mais ces paramètres n'ont jamais été modifiés ! De toute façon je ne vois pas en quoi ils pourraient être "invalides" puisque c'est moi qui les définis. Bref je suis coincé, l'accès aux fichiers est impossible pour tous les utilisateurs ainsi que d'autres services liés au LDAP. Les boules ! Qui peut m'aider ?

Personne n'utilise BubbleUPnP on dirait ! Dommage parce que j'aurais simplement eu besoin que quelques personnes testent et constatent le même problème que moi.

J'ai fait un GIF animé pour présenter mon problème de manière plus graphique, mais décidément je ne trouve nulle part où le joindre à mon message ! Quelqu'un peut-il m'aider ?

Salut à tous. Je suis super content parce que j'ai réussi à me faire une petite installation audio "connectée" sympa avec un téléphone Android reconverti ! Voilà le matériel : Un NAS Synology DS710+ en DSM 5.0-4482 avec "Serveur multimédia" activé --> Serveur DLNA (Digital Media Server, DMS) Un smartphone Android* avec l'application BubbleUPnP** --> Diffuseur DLNA (Digital Media Renderer, DMR) Des enceintes amplifiées reliées au smartphone décrit ci-dessus Plusieurs autres smartphone Android ou iOS exécutant l'application DS Audio --> Contrôleurs DLNA (Digital Media Controller, DMC) Un ou plusieurs PC sous Windows ou Linux qui peuvent accéder à Audio Station par l'interface Web --> Contrôleurs DLNA (Digital Media Controller, DMC) Et le principe : Le smartphone qui fait DMR (appelons-le "smartphone du salon") exécute l'application BubbleUPnP en permanence Avec un autre smartphone (appelons-le "mon smartphone") et DS Audio sur PC, je peux naviguer parmi la bibliothèque du NAS, choisir le "smartphone du salon" comme sortie audio, et lancer la lecture de mes musiques préférées pour les diffuser dans le salon Avec mon PC je peux passer à la musique suivante, changer la liste de lecture, etc. de même qu'avec mon smartphone ou un autre smartphone Mais évidemment si je suis là c'est que je rencontre un problème ! Que ce soit à partir des applications DS Audio sur smartphone ou d'Audio Station sur PC, lorsque je règle le volume pour modifier le volume du Renderer (smartphone du salon), la plage de réglage est limité à environ 20% de la taille totale du slider d'Audio Station (ou de DS Audio, le comportement est le même). Si je dépasse, le volume ne change pas et le curseur revient à sa position initiale. En réalité la plage totale de réglage du volume de mon Renderer [0-100%] est ramenée à [0-20%] sur Audio Station et DS Audio. Cela signifie qu'en mettant le volume à 10%, j'obtiens 50%, et en mettant le volume à 20% j'ai 100% (très fort !). J'ai beau avoir des petits doigts ou une souris précise, j'ai carrément du mal à régler le volume correctement !! C'est là que j'en appelle à la communauté : Y en a-t-il parmi vous qui ont des configurations DLNA qui ressemblent à la mienne ? Avez-vous rencontré ce problème de volume ? Avec BubbleUPnP sous Android ? Avec un autre type Renderer ? Le problème vient-il de chez Synology ou de BubbleUPnP ? Le contrôle du volume est-il sensé respecter un standard de valeurs de niveau ? Merci à vous * Samsung Galaxy Ace avec une ROM Android 4.2.2 (CyanogenMod 10.1) ** BubbleUPnP 1.8.6 avec licence valide, acheté sur Google Play Store Source à propos du DLNA : http://fr.wikipedia.org/wiki/Digital_Living_Network_Alliance

OK je suis rassuré. Allez j'installe ! ----- EDIT : Parfait, mon installation de IPKG est conservée et mes paquets sont listés correctement. Preuve qu'il n'y avait aucune raison de s'inquiéter. Merci Lelolo !

OK merci Lelolo. Sais-tu me dire si ce paquet installe IPKG, et potentiellement écrase une installation existante ? Ou peut-être qu'il vérifie la présence d'IPKG avant d'installer IPKGui ? Ou peut-être que l'installation de IPKG est un pré-requis ? Help me

Pour ma part jusqu'a maintenant - et depuis le DSM 2.3 - je note la qualité et la stabilité globale de la suite logicielle proposée par Synology. J'apprécie également la quantité croissantes de fonctionnalités proposées, que ce soit par intégration dans le DSM ou via des paquets supplémentaires. Je trouve mon compte dans tout ça parce que j'ai accès à des fonctionnalités professionnelles grâce à une simplicité défiant toute concurrence, et des fonctionnalités très "user-friendly" destinées à l'utilisation à la maison. Jusque là je crois que ça évolue plutôt dans le bon sens : quand je vois la différence entre PhotoStation 4 et PhotoStation 6, l'arrivée de TimeBackup, ou le nombre de paquets supplémentaires qui ont été ajoutés l'année dernière, je suis content d'avoir acheté Synology . Pour la petite histoire j'ai acheté un D-Link DNS-320 il y a peu par souci d'économie , plus jamais je ne referai cette erreur ! Tout ce que je souhaite, c'est que cela continue (avec DSM 5 et ses successeurs), et que mon NAS puisse encore recevoir les mises à jour pour quelques années .

Boarf, ça ne concerne pas grand monde on dirait...

Oups, j'ai un peu décroché on dirait En ce qui concerne la transition, est-ce que le basculement se fait simplement ? Y a-t-il des configs à modifier ?

Salut ! Sur mon Syno IPKG est installé ainsi qu'un serveur svn (par le biais d'IPKG). Maintenant il existe un paquet "officiel" SVN (serveur) dans le Centre de paquets. Question : Ai-je un intérêt à basculer mon installation actuelle sur le paquet officiel ? L'administration est-elle plus simple avec cette solution ? Schuusss

Bonjour à tous. Voilà j'ai un Synology DS710+ et IPKG y est installé de longue date. Je viens d'ajouter des au "Centre de paquets" et je vois maintenant apparaître un outil intéressant nommé "IPKGui" qui se veut être une interface graphique pour IPKG. A la manière de "synaptic", ça doit permettre de gérer les paquets installés autrement que par la ligne de commande. L'idée me plaît, mais je n'ai pas voulu installer ce paquet de peur que mon installation actuelle d'IPKG soit écrasée. Quelqu'un a-t-il déjà installé IPKGui ? Ce paquet fait-il une ré-installation systématique de IPKG ? Merci pour votre aide

Pour les prochains visiteurs qui tomberont sur ce topic, sachez qu'il y a déjà des solutions sur ce forum car ce n'est pas un problème isolé. Chaque mise à jour de DSM semble remettre le PATH par défaut (et donc le chemin vers les binaires IPKG n'existe plus). Une solution détaillée - "pour les nuls" - se trouve

Très bon tutoriel, qui m'a permis d'accéder à mon NAS depuis les réseaux qui bloquent le port sortant (enfin ! Ca fait 1 an que je me demande comment faire ça...). Si je peux me permettre 2 remaques : Je n'ai rencontré aucun problème quant à la mise en place de cette solution avec le DSM 4 (DSM 4.0-2198). Certes mes fichiers ne sont pas strictement identiques à ceux proposés, certes je redirige toutes les requêtes HTTP vers le HTTPS, certes j'ai aussi créé un accès pour le protocole WebDAV, mais qu'importe : à mon avis il n'y a aucune contre-indication spécifique au DSM 4.0. Je ne comprends donc pas le message de mise en garde sur ton site Patrick (la description qui suit n'est pas compatible avec la version DSM4.0) Il serait fort bien de tagger ce fil avec des mots clés du genre "travail", "bureau", "réseau bloqué", "proxy". Pour ma part je cherchais à accéder à mon serveur depuis mon travail. Le trafic sortant est filtré, et le port 5000/5001 est donc inaccessible. Me disant que je n'étais pas le premier (ce qui est loin d'être le cas), j'ai cherché des choses comme "Accéder à son NAS depuis son travail" sans rien trouver de concluant. J'ai eu énormément de mal à trouver un tuto, avant de comprendre qu'il fallait que j'utilise le port (port qui n'est jamais bloqué). Bien sûr tout le monde n'est pas dans cette situation de réseau filtré, mais je pense que ce serait donner un gros pouce aux novices que d'ajouter quelques mots clés (ou un nouveau sous-titre) à ce fil. Merci beaucoup Patrick !

Bonne nouvelle, pour ma part la mise à jour vers le DSM 4.0 n'a pas affecté les modifications décrites dans ce tutoriel. Espérons qu'au fil des mises à jour suivante nous puissions tous faire le même constat.

Ca n'empêche que je connais les rudiments de VI pour l'utiliser quand c'est absolument nécessaire. La preuve, en 2 minutes mon problème était résolu. Simplement je ne m'en sers jamais, donc j'ai besoin d'un aide-mémoire

J'utilise nano, et ça me suffit amplement ! (Sauf que nano dépend d'ipkg...)

OK là réponse se trouve sur cette page (entre autres). Pour les nazes comme moi, vous aurez besoin d'avoir des infos sur VI, l'éditeur de fichiers des geeks. Tapez "guide de survie VI" dans un moteur de recherche pour en apprendre plus. Pour ceux qui sont flemmards, voici les instructions. Toutes les parties soulignés sont les commandes ou textes à taper : cd /root vi .profile Placez votre curseur juste après le signe "égal" de l'expression "PATH=" à l'aide des flèches du clavier. Appuyez sur i pour passer en mode insertion. Tapez très exactement /opt/bin:/opt/sbin: Appuyez sur Echap pour quitter le mode insertion. Tapez :wq pour enregistrer et quitter votre fichier modifié (w = "write", q = "quit"). Rebootez votre machine, ou si vous ne voulez pas rebooter, relancez votre bootstrap pour prendre en compte la modification : /etc/rc.local (lance le script de démarrage habituel du Syno) . /root/.profile (exécute le fichier modifié précédemment ; le point en début de commande n'est pas une erreur !) Merci à bud77 qui m'a botté les fesses pour que je cherche par moi-même la solution à mon petit souci

Bonjour à tous, Tout d'abord, et pour faire exception à la règle, je dois souligner que le titre de mon fil n'est pas tout à fait correct. En effet, j'ai installé récemment la version 4.0 du DSM sur mon DS710+, sur lequel était déjà installé le bootstrap. Depuis, je ne peux plus utiliser IPKG ou un paquet associé en tapant directement "ipkg" dans la console. Pourtant, si je lance le binaire ipkg directement depuis son répertoire (/volume1/@optware/bin/ipkg), il fonctionne : j'ai testé un "update" par exemple. Je peux aussi lister tous les paques installés en spécifiant toujours le chemin, mais impossible de le faire fonctionner en tapant "ipkg" si je suis dans un aure répertoire, soit par exemple "/volume1". Mais deux choses me paraissent particulièrement bizarres : Le point de montage /opt existe toujours et pointe bien vers /volume1/@optware Certains paquets continuent à fonctionner correctement. Mes dépôts SVN hébergés sur le NAS sont parfaitement fonctionnels (il est toujours possible de faire des commits par exemple). Je suppose que ce n'est qu'une histoire de variables d'environnement, mais je n'ai aucune idée de ce que je dois faire pour les modifier. Quelqu'un aurait-il une info pour me donner un coup de pouce ? Merci !

Content de voir que ça fonctionne pour vous, même après une mise à jour du DSM !

Ce tutoriel a été originellement posté dans la partie Modifications logicielles du forum. pour plus d'informations. Tutoriel : Arrêt impossible du NAS Description du problème, Diagnostic de panne, et Mise en place d'une solution I) Symptômes Après une demande d’arrêt ou de redémarrage, le NAS se bloque dans sa phase d’arrêt. On peut le constater en voyant que le bouton de mise en route ("power") de la machine clignote, même après plusieurs (très longues) minutes, voire même plusieurs heures d’attente. Le NAS peut éventuellement conserver une activité réseau ou non, en fonction de la configuration de votre machine. Toujours est-il que tous les services sont offline (pas de DSM, pas de partage réseau, etc.), et il n’est donc plus possible de prendre le contrôle. Après avoir attendu 10min et constaté le problème tel que décrit ci-dessus, le seul moyen pour arrêter la machine est de rester appuyé sur le bouton d’alimentation jusqu’à l’extinction complète. => Vous vous êtes reconnu dans cette description des symptômes ? Passez à la partie 2 ! II) Explications et cause probable Si IPKG n’est pas installé sur votre machine, ou si vous ne savez pas s’il est installé, il y a 95% de chances pour que la solution donnée ci-après ne corresponde pas à votre problème. En effet, nous traitons ici d’un problème lié à IPKG, complètement indépendant du DSM et de la version actuelle du système… Votre problème, s’il est lié à IPKG, est sûrement dû au fait que le système n’arrive pas à démonter le point de montage d’IPKG (autrement appelé « Optware »), à savoir /opt . Ce point de montage est créé au démarrage par le script /etc/rc.optware et redirige en réalité vers /volume1/@optware . « Si le système arrive à faire le montage, pourquoi pas le démontage ? », me direz-vous. Prenons un exemple : Vous travaillez sur un document de votre clé USB : un fichier texte est ouvert dans votre éditeur, et vous souhaitez « éjecter » votre clé de l’ordinateur. Dans la plupart des cas, le système refuse en vous signifiant que certains documents sont en cours d’utilisation. En effet, l’éditeur de texte a ouvert un document de la clé ! Il est donc impossible de la « démonter », et pourtant le système a bien réussi à la « monter ». Il en est de même pour IPKG et /opt : il est probable que certains programmes « tierce-partie » s’exécutent dans /opt et ses sous-répertoires. Dans ce cas, le système est incapable de démonter /opt , et refusera purement et simplement de s’arrêter, car un programme en cours d’exécution peut avoir des bonnes raisons de l’être. C’est donc à l’utilisateur d’arrêter manuellement les programmes tiers, puisque l’installation d’IPKG ne prévoit apparemment pas l’arrêt automatique des programmes lors d’une demande d’arrêt du système. Note : Pour le diagnostic et la résolution du problème, vous allez avoir besoin d’un accès console à votre NAS (SSH, ou éventuellement Telnet), mais normalement vous êtes habitué, puisque vous avez déjà installé IPKG Pour vérifier qu’IPKG est installé sur votre machine, connectez-vous via SSH ou Telnet et tapez « ipkg list ». Cette commande renvoie normalement la liste de tous les paquets disponibles au téléchargement ; si c’est la cas, IPKG est installé, et vous pouvez être concerné par le problème décrit dans ce topic. III) Diagnostic de panne 1) Vous pouvez très simplement vérifier que votre problème est bien lié à un « démontage impossible » en regardant dans le fichier /var/log/messages et en cherchant une ligne similaire à kernel: [******.******] force umount failed! mnt_count:* 2) Si une ligne de ce type existe, vous pouvez confirmer vos soupçons en tapant umount /opt si la commande s’exécute correctement, le problème vient d’ailleurs, sinon, vous avez bien un problème de démontage. 3) Tentons donc de remonter au coupable de ce « démontage impossible ». Il est probable que des programmes s’exécutent dans « /opt/ ». Pour le vérifier, tapez : ps |grep "/opt/" |grep -v "grep" Si la commande vous renvoie une ou plusieurs lignes, chacune d'elle correspond à un programme en cours d’exécution sur /opt/ (cause de votre malheur). Sinon, aucun programme ne s’exécute sur /opt/ , et il faudra chercher une autre piste. 4) Enfin, vous pouvez essayer d’arrêter manuellement tous les programmes tournant sur /opt/, puis de démonter le volume : PNAME=`ps |grep "/opt/" |grep -v "grep" |awk -F" " '{ print $1 }'` kill $PNAME umount /opt Si la dernière commande ne renvoie pas d’erreur, tentez un arrêt ou redémarrage de votre Syno : ça devrait fonctionner. Si c’est le cas, passons à la mise en place d’une solution automatisée, à base de scripts. IV) Solution à adopter Notre problème intervient lors de la phase d’arrêt, il nous faut donc un script qui se lance automatiquement lors de l’arrêt. Après avoir fait quelques recherches, il semble que sous Linux il y ait beaucoup de répertoires prévus pour lancer des scripts au démarrage, mais pas beaucoup à l’arrêt. Il ne reste donc que /etc/rc.d/ et /usr/local/etc/rc.d/ qui correspondent à nos besoins (source : wiki FreeBSD). D’après un forum relatif à FreeBSD, il est plus sage de placer ses scripts dans /usr/local/etc/rc.d/ (en considérant que toutes les distributions adoptent le même formalisme). Maintenant que vous savez tout, passons à la mise en place. Nous pouvons considérer qu’il existe deux solutions à notre problème. En plus d’un script d’arrêt général : 1) Pour chaque script S** présent dans « /opt/etc/init.d/ », il faut créer un équivalent K** dédié à l’arrêt du service associé. 2) Pour l’ensemble des scripts S** présents dans « /opt/etc/init.d/ », nous pouvons créer un script générique K99shutdown.sh qui se chargera d’arrêter tous les programmes IPKG en fonctionnement. A mon avis, la solution 2 est plus simple et plus sûre, car elle ne nécessite qu’un seul script, et se base sur l’état réel de la machine au moment de l’arrêt (et non un état supposé). Attention : Certains scripts S** fournis par les paquets contiennent des instructions d’arrêt. Si celles-ci ont d’autres fonctions qu’un simple kill ou killall, il est impératif de placer ces instructions dans un équivalent K** (sans même prendre en compte si le fichier est lancé en mode « start » ou « stop », puisque tous les S** seront lancés avec « start » et tous les K** avec « stop »). V) Les fichiers C’est parti ! Créons un fichier optware.sh avec les droits 755 dans /usr/local/etc/rc.d/ , il nous servira de lanceur pour l’ensemble des scripts de démarrage S** et d’arrêt K** contenus dans /opt/etc/init.d/ . /usr/local/etc/rc.d/ optware.sh (chmod 755) Puis créez un autre fichier K99shutdown.sh avec les droits 755 dans /opt/etc/init.d/ , il scannera tous les programmes s’exécutant dans /opt et les arrêtera. /opt/etc/init.d/ K99shutdown.sh (chmod 755) Enfin, comme décrit précédemment, vérifiez le contenu des /opt/etc/init.d/S** pour supprimer les cas « stop », et créez des équivalents K** qui contiendront les instructions correspondantes. Ouf, maintenant, vous pouvez redémarrer ! N’hésitez pas à me faire des retours sur le fonctionnement de cette solution. Ce post sera mis à jour en conséquence, pour que tous les utilisateurs puissent en bénéficier. Ce tutoriel a été écrit en se basant sur la configuration de mon Synology DS710+, mais doit pouvoir fonctionner pour tous les modèles, et pour toutes les versions de DSM (sauf en cas de refonte profonde de l'architecture système). Merci à bud77, parisbyday et PatrickH du forum, qui m’ont permis d’élaborer cette solution, et donc de vous la faire partager.

J'ai un petit message relatif au tout premier post de ce topic, et qui peut servir à tout le monde : Je n'y connais rien à l'utilisation de VI (je sais à peine enregistrer, et quitter), et pour l'instant je m'en sors très bien dans le monde Linux. Donc tant qu'à faire d'installer IPKG, pour l'utilisateur novice je recommande chaleureusement l'utilisation de NANO, éditeur de texte simple et très facile d'emploi. ipkg install nano

Tutoriel : Arrêt impossible du NAS Description du problème, Diagnostic de panne, et Mise en place d'une solution I) Symptômes Après une demande d’arrêt ou de redémarrage, le NAS se bloque dans sa phase d’arrêt. On peut le constater en voyant que le bouton de mise en route de la machine clignote en bleu, même après plusieurs (très longues) minutes, voire même plusieurs heures d’attente. Le NAS peut éventuellement conserver une activité réseau ou non, en fonction de la configuration de votre machine. Toujours est-il que tous les services sont offline (pas de DSM, pas de partage réseau, etc.), et il n’est donc plus possible de prendre le contrôle. Après avoir attendu 10min et constaté le problème tel que décrit ci-dessus, le seul moyen pour arrêter la machine est de rester appuyé sur le bouton d’alimentation jusqu’à l’extinction complète. => Vous vous êtes reconnu dans cette description des symptômes ? Passez à la partie 2 ! II) Explications et cause probable Si IPKG n’est pas installé sur votre machine, ou si vous ne savez pas s’il est installé, il y a 95% de chances pour que la solution donnée ci-après ne corresponde pas à votre problème. En effet, nous traitons ici d’un problème lié à IPKG, complètement indépendant du DSM et de la version actuelle du système… Votre problème, s’il est lié à IPKG, est sûrement dû au fait que le système n’arrive pas à démonter le point de montage d’IPKG (autrement appelé « Optware »), à savoir /opt . Ce point de montage est créé au démarrage par le script /etc/rc.optware et redirige en réalité vers /volume1/@optware . « Si le système arrive à faire le montage, pourquoi pas le démontage ? », me direz-vous. Prenons un exemple : Vous travaillez sur un document de votre clé USB : un fichier texte est ouvert dans votre éditeur, et vous souhaitez « éjecter » votre clé de l’ordinateur. Dans la plupart des cas, le système refuse en vous signifiant que certains documents sont en cours d’utilisation. En effet, l’éditeur de texte a ouvert un document de la clé ! Il est donc impossible de la « démonter », et pourtant le système a bien réussi à la « monter ». Il en est de même pour IPKG et /opt : il est probable que certains programmes « tierce-partie » s’exécutent dans /opt et ses sous-répertoires. Dans ce cas, le système est incapable de démonter /opt , et refusera purement et simplement de s’arrêter, car un programme en cours d’exécution peut avoir des bonnes raisons de l’être. C’est donc à l’utilisateur d’arrêter manuellement les programmes tiers, puisque l’installation d’IPKG ne prévoit apparemment pas l’arrêt automatique des programmes lors d’une demande d’arrêt du système. Note : Pour le diagnostic et la résolution du problème, vous allez avoir besoin d’un accès console à votre NAS (SSH, ou éventuellement Telnet), mais normalement vous êtes habitué, puisque vous avez déjà installé IPKG Pour vérifier qu’IPKG est installé sur votre machine, connectez-vous via SSH ou Telnet et tapez « ipkg list ». Cette commande renvoie normalement la liste de tous les paquets disponibles au téléchargement ; si c’est la cas, IPKG est installé, et vous pouvez être concerné par le problème décrit dans ce topic. III) Diagnostic de panne 1) Vous pouvez très simplement vérifier que votre problème est bien lié à un « démontage impossible » en regardant dans le fichier /var/log/messages et en cherchant une ligne similaire à kernel: [******.******] force umount failed! mnt_count:* 2) Si une ligne de ce type existe, vous pouvez confirmer vos soupçons en tapant umount /opt si la commande s’exécute correctement, le problème vient d’ailleurs, sinon, vous avez bien un problème de démontage. 3) Tentons donc de remonter au coupable de ce « démontage impossible ». Il est probable que des programmes s’exécutent dans « /opt/ ». Pour le vérifier, tapez : ps |grep "/opt/" |grep -v "grep" Si la commande vous renvoie une ou plusieurs lignes, chacune d'elle correspond à un programme en cours d’exécution sur /opt/ (cause de votre malheur). Sinon, aucun programme ne s’exécute sur /opt/ , et il faudra chercher une autre piste. 4) Enfin, vous pouvez essayer d’arrêter manuellement tous les programmes tournant sur /opt/, puis de démonter le volume : PNAME=`ps |grep "/opt/" |grep -v "grep" |awk -F" " '{ print $1 }'` kill $PNAME umount /opt Si la dernière commande ne renvoie pas d’erreur, tentez un arrêt ou redémarrage de votre Syno : ça devrait fonctionner. Si c’est le cas, passons à la mise en place d’une solution automatisée, à base de scripts. IV) Solution à adopter Notre problème intervient lors de la phase d’arrêt, il nous faut donc un script qui se lance automatiquement lors de l’arrêt. Après avoir fait quelques recherches, il semble que sous Linux il y ait beaucoup de répertoires prévus pour lancer des scripts au démarrage, mais pas beaucoup à l’arrêt. Il ne reste donc que /etc/rc.d/ et /usr/local/etc/rc.d/ qui correspondent à nos besoins (source : wiki FreeBSD). D’après un forum relatif à FreeBSD, il est plus sage de placer ses scripts dans /usr/local/etc/rc.d/ (en considérant que toutes les distributions adoptent le même formalisme). Maintenant que vous savez tout, passons à la mise en place. Nous pouvons considérer qu’il existe deux solutions à notre problème. En plus d’un script d’arrêt général : 1) Pour chaque script S** présent dans « /opt/etc/init.d/ », il faut créer un équivalent K** dédié à l’arrêt du service associé. 2) Pour l’ensemble des scripts S** présents dans « /opt/etc/init.d/ », nous pouvons créer un script générique K99shutdown.sh qui se chargera d’arrêter tous les programmes IPKG en fonctionnement. A mon avis, la solution 2 est plus simple et plus sûre, car elle ne nécessite qu’un seul script, et se base sur l’état réel de la machine au moment de l’arrêt (et non un état supposé). Attention : Certains scripts S** fournis par les paquets contiennent des instructions d’arrêt. Si celles-ci ont d’autres fonctions qu’un simple kill ou killall, il est impératif de placer ces instructions dans un équivalent K** (sans même prendre en compte si le fichier est lancé en mode « start » ou « stop », puisque tous les S** seront lancés avec « start » et tous les K** avec « stop »). V) Les fichiers C’est parti ! Créons un fichier optware.sh avec les droits 755 dans /usr/local/etc/rc.d/ , il nous servira de lanceur pour l’ensemble des scripts de démarrage S** et d’arrêt K** contenus dans /opt/etc/init.d/ . /usr/local/etc/rc.d/ optware.sh (chmod 755) Puis créez un autre fichier K99shutdown.sh avec les droits 755 dans /opt/etc/init.d/ , il scannera tous les programmes s’exécutant dans /opt et les arrêtera. /opt/etc/init.d/ K99shutdown.sh (chmod 755) Enfin, comme décrit précédemment, vérifiez le contenu des /opt/etc/init.d/S** pour supprimer les cas « stop », et créez des équivalents K** qui contiendront les instructions correspondantes. Ouf, maintenant, vous pouvez redémarrer ! N’hésitez pas à me faire des retours sur le fonctionnement de cette solution. Ce post sera mis à jour en conséquence, pour que tous les utilisateurs puissent en bénéficier. Merci à bud77, parisbyday et PatrickH du forum, qui m’ont permis d’élaborer cette solution, et donc de vous la faire partager.

Non non, mon installation IPKG "standard" faisait très bien les choses toutes seules, il n'y avait aucune raison que je change. Et puis démonter un volume pour créer un lien symbolique, ce n'est que contourner le problème, pas le résoudre... En tout cas ton problème est bien lié à IPKG, ça m'étonnait aussi que je sois le seul. Je compte encore faire quelques modifications sur mes scripts, et je ferai un post "résumé", avec : les symptômes constatés, la méthode de diagnostique, et la mise en place de la solution. Sois patient encore 2 ou 3 jours, et tu auras la version "clé en main"

Tout ça c'est normal, de ce que j'ai pu constater. Ça c'est beaucoup moins normal. Tu sembles avoir un périphérique USB connecté (un onduleur peut-être ?), et le port sur lequel il est branché ne peut pas être arrêté, va savoir pourquoi... Pour tester, je pense que si tu débranches les périphériques USB, tu ne devrais pas constater ce problème. Il faudrait chercher du côté de ce code d'erreur "-19" en rapport avec "hub 6-0:1.0". Dans tous les cas, on ne dirait pas que ce soit lié à IPKG. Tu as vu qu'un gars avait le même problème que toi sur le forum officiel Synology ? Peut-être que depuis il a trouvé la solution... (Tiens, il est en RAID5, comme toi Mais ça n'a peut-être aucun rapport.) Peut-être qu'il vaut mieux que tu démarres un nouveau sujet, dans une partie du forum plus adaptée à ton problème.