MS_Totor

tu as bien rebooter apache cd /usr/syno/etc/rc.d/ S97apache-sys.sh stop S97apache-sys.sh start S97apache-user.sh stop S97apache-user.sh start sinon la modif n'est pas prise en compte

ok tu n'es pas le seul on dirais, et cela vient bien de php.ini et open_basedir probleme également ici http://forum.synolog...t=23331&start=0 un ajout sans doute du à un copier/coller sauvage qui n'a rien à faire là /etc:/source/busybox-1.1.0/synocmds/get_key_value.c (82) Buffer is too small: un fichier correct pour syno vi /usr/syno/etc/php.ini open_basedir = /usr/syno/synoman:/etc:/var/run:/tmp:/var/spool/php:/volume1/@tmp/php:/var/services/web:/var/services/photo:/var/services/blog:/var/services/homes:/volume1/web:/var/packages/MailStation/target/roundcubemail j'ai envoyé un mail au support

je n'ai pas fait de migration tu n'aurais pas un soucis dans php.ini et pas les bons chemins pour open_basedir ? quels sont les droits sur index.php

salut idem je n'ai pas ce groupe, quelle version de firmware utilises tu ? des paquets ipkg install

salut n'essayes pas de transf

quoi il

j'ai enfin réussi à mettre une debian chrooté sur mon 1010+ et hop une debian 5.04 avec tout ce qu'il faut en modules kernel et plus un truc bridé, une clé usb 4 go pour la mémoire flash en sus je fais quelques tests jusqu'à ce soir ca a l'air stable, le chipset est bien reconnu maintenant après pas mal de déboires ces derniers temps, x86 c'est quand même beaucoup ouvert à la bricole

laisses tomber pour l'instant c'est tombé dans ma boite mail à l'instant ils reconnaissent enfin que les sources (patch kernel) qui ont servi pour le firmware 2.3 ne sont pas celles disponible en GPL (944b) et ont évoluées, bref le soupçon de patchs ajoutés aux kernel est bien réel.... mais ils n'ont pas voulu me donner la liste des patch....grrrrrr pour la date de sortie, c'est leur propos il faut attendre la release d'une prochaine version de firmware pour valider pleinement la série 2.3 . comme cela a été le cas par le passé, le temps des bugs mineurs ou nouveaux à corriger après la saison de bêta test, et alors ils rendrons publique la nouvelle série de source GPL. Bref tu peux compiler ce que tu veux sauf les modules kernel avec la série 944 bonne journée PS: à moins bien sur que tu ne saches prendre un module déjà compilé dans le fichier pat 1141 et de là que tu sache reconnaitre la signature complète du kernel en dé-compilant le module, perso là, je ne sais pas le faire et toi ?

bonjour, pas de quoi si tu progresse fais moi signe que je mette à jour mes tablettes je compilais sans problème pour tous les modèles en 2009, mais depuis l'arrivée des firmware > 939, les sources GPL 944b sont un soucis pour beaucoup en gros on peut compiler des paquets sans accroche si on respecte les dépendances de librairies du paquet, mais seul les modules kernel posent soucis, c'est aussi le cas pour les séries à base de proco atom sur les derniers modèles... c'est aussi la raison pour laquelle on ne trouve plus de paquets sur ipkg pour les modules kernel de dispo, alors qu' en 2009 oui.... vu l'aberration kamikaze en usage des kernels que font certains sur leur syno sous garantie, il est possible que synology ait décidé de stopper l'hémorragie de syno en mode "briked". autre info: le uname -r sur le syno ne represente rien de concret, car les dev ne respectent pas le fait d'afficher la version des patch installés, (pour leurrer tout le monde) mais ne donne que 2.6.24, tout comme un cat /proc/cpuinfo sur le 1010+ encore une erreur , au lieu de D510, ca affiche K510 etc.... bref c'est pas du tout réellement GPL les synos d'où mon conseil de bien relire la section patch des sources gpl, car on est plus proche des kernel 2.6.24.3 ou 2.6.24.3.xxx........ dans le makefile au lieu de figer à 2.6.24, par défaut tentes de mettre la version complète, ex: 2.6.24.3 donc renseigner minor etc.. voila dans mes recherches j'en étais à ce point là, et pas essayer de changer la version kernel dans le makefile, pour faire pointer "peut être" la compilation en incluant les patchs. .voir aussi, prendre un module existant dans le dernier fichier pat, et voir comment il a été compilé si cela est possible, je ne sais pas le faire pour l'instant car je n'ai pas eu le temps de chercher. bref à partir d'un module kernel compilé, peut on savoir avec quel kernel il a été fait, via une signature interne en hexa etc... ?

je vais voir d'où vienne les erreurs bridge: Unknown symbol br_handle_frame_hook bridge: Unknown symbol br_fdb_put_hook bridge: Unknown symbol br_fdb_get_hook bridge: Unknown symbol br_handle_frame_hook bridge: Unknown symbol br_fdb_put_hook bridge: Unknown symbol br_fdb_get_hook sur ma debian, j'ai pointé sur un repertoire de destination neutre et simulé l'installation du kernel après le make modules tu fais un modules_install là tu a création du kernel dans ton /repertoire de destination/ lib/modules/2.6.24/kernel/net/bridge/bridge.ko puis cela fais automatiquement un DEPMOD 2.6.24 pour créer les symboles... attention à bien gerer le repertoire de destination, sinon ca ira par défaut dans ton repertoire lib de la station de dev lis ce doc pour mieux piger le trucs des dépendances et le principe du symbole via DEPMOD http://machard.org/t...tml/depmod.html vu le nombre de post ou tu as l'info sur le même genre d'erreur j'ai encore l'impression que le kernel sur syno a été patché, regardes dans les sources du kernel, section patch. désolé de ne pouvoir t'aider plus

salut je n'ai pas tout lu, un petit compl

oui si tu simule le m

j'ai compilé les deux modules avec deux chaines différentes dans les options de kernel voir le lien dans mon profil "quelques tutoriels en cours", tu rajoute /tests au lien pour récupérer l'archive je ne garantie rien n'ayant pas ce modèle sous la main, tu prends un module, tu le renomme en bridge.ko et teste, si il ne passe pas, tu essayes l'autre, renomme et test. merci de faire un retour pour valider ou pas ma chaine de compil.... @+

j'ai fait quelques tutos sur le sujet sur mon petit site, le temps de reprendre pas mal de de choses, et je mettrai le lien direct ici

je pense comme toi pour info, j'avais demandé aussi sur la mailing list de nslu2 et là pas de réponse du tout, la version compilée date de longtemps aussi je me suis donc pris en main et hop

salut sur le système syno le boot se fait via une image placée en mémoire flash, et il faudrait un accès en port série et tftpd etc.. bref pas possible ou du moins pas envie d'aborder des sujets dangereux et je te déconseille de bricoler le kernel en le changeant, mais plutôt en cross-compilant les modules comme tu as commencé à le faire, sinon, tu risque de transformer ton syno en brique inerte et pas bien utile. ton modules est mal compilé, du moins pas avec les bons symboles, donc pas reconnu par le kernel du syno. je ne connais pas le 109+ sur quel base est il, cpu et version kernel c'est bien un ppc8533 ? et kernel 2.6.24 ? j'ai pas mal de chose à faire cet aprèm, mais je tenterais de te compiler le module qui te manque, à toi de le tester et me faire un retour, si jamais il ne passe pas, je tenterais deux méthodes différentes donc deux modules bridge.ko différents

petit rafraichissement de ce tuto sur la s

c'est ce que je dois faire prochainement, mon serveur vmware est presque pleins, du moins son raid, je vais transf

ne cherche pas trop et n'espère pas héberger la partie serveur sur syno, ou qnap,, pas assez de patates, peu de ram, la certification qnap pour vmware est juste qu'ils ont monté des partages nfs sur le qnap et que depuis un serveur ESX ils ont fait des tests en montant des vm sur ces partages rien de plus bref oui n'importe quel nas avec du nfs ou iscsi est capable de faire la même chose. voila à quoi ressemble la procédure qnap http://wiki.qnap.com...re_ESX_Server_3

heu si tu n'as pas vu en dessous le message de retour, j'ai re compilé la busybox pour les i686, donc les processeur d410 et d510 , perso j'ai dorénavant " presque " tous les outils manquants à un linux classique , et pas pressé cela inclus, une très grosse partie des outils du syno natifs que nous connaissons coretutils, findutils, libutils..etc... que nous sommes obligés souvent de piocher dans ipkg..... me reste à peaufiner les options à offrir car certaines sont trop dangereuses, avant de les mettre en ligne via le téléchargement du forum et pour ca j'ai besoin d'un peu de temps, ou d'un coup de main. pour restreindre ce qui est possible de faire sans nuire à la survie de nos synos. la possibilité de re formater les dd des synos en fat 32 pour du linux n'est pas une bonne idée n'est ce pas ?

r

no comment

salut et bienvenue dans l'ar

de loin je te sens un brin moqueur vista powa, mais seven pour ma pomme ressemble fort