Problème de connexion avec le serveur Hubic

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Depuis quelques semaines, je n'arrive plus à me connecter en ligne de commande sur mon compte Hubic. A partir d'un navigateur Internet (Firefox), je n'ai pas de problème.
C'est exactement le même souci que celui décrit ici.
Mais comme chez Mageia, on n'a pas de paquetage certificate-mono, je ne sais pas quoi faire.
Cela pourrait venir de la version de mono (j'utilise celle par défaut de Mageia6, mais le problème existait déjà alors que j'étais sous Mageia5).
Quelqu'un peut-il m'aider ?
Merci.
Xuo.

OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Idem pour moi, depuis le passage à Mageia 6, hubiC ne se connecte plus

Je n'ai pas eu le temps de chercher en détails, j'ai juste installé tout les paquet qui conteniennent "mono" dans le nom, mais sans succès.
Par contre sur la même machine j'ai un double boot opensuse 42.3 et la synchro fonctionne.
Sur openSuse mono est en verion 4.6.1 alors que sur Mageia, c'est la 4.2.4, mais je ne sais pas s"il y a un lien de cause à effet.
Par contre sur Mageia 5 la synchro fonctionnait bien chez moi...
@+

Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Dans mon cas, je ne pense pas que ce soit le passage à Mageia6 qui soit le problème.
Je vais essayer de récupérer une version plus récente.
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Les gens sur LinuxMint sont en 4.2.1.
Il n'y a que sur Ubuntu et Debian que le paquetage ca-certificates-mono est disponible. Et il semble bien qu'il soit nécessaire pour faire de l'https.
Si sur Mageia5, il n'y en avait pas besoin, c'est que la version de mono s'en débrouillait. Mais je ne sais pas de laquelle il s'agit.
Je continue à chercher.
Je pense avoir trouvé. C'était la 3.12.1.1. Maintenant, il faut que j'arrive à télécharger quelques dizaines de paquetages, mais pas à la main, un à un. C'est pas gagné.
Xuo.
Édité par xuo Le 29/08/2017 à 22h20

Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Pense tout de même à faire un rapport de bogue. C'est une bonne raison d'inclure un nouveau package.
Yves

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Je ne pourrai faire la manip que ce week-end. Je préfère être devant le pc plutôt que tout faire à distance en ligne de commande.
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'ai quand même essayé. J'ai pu installer la version de mono de Mageia5 mais j'ai l'erreur suivante :
Command failed: An exception was thrown by the type initializer for DBus.Bus.
Je sèche.
Xuo.
Édité par xuo Le 30/08/2017 à 21h22

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'ai ouvert une demande de paquetage sur le bugzilla mais je me suis fais rembarré (https://bugs.mageia.org/show_bug.cgi?id=21656). Donc je ne sais pas comment faire pour régler le problème. Je vais continuer à chercher mais pour le moment je n'ai pas d'idées.
Xuo.

OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Depuis environ une semaine, la synchro ne fonctionne plus non plus sur openSuse.
La connexion fonctionne, mais plus de synchro

Je ne sais pas non plus quoi faire, côté OVH, l'appli n'a pas évolué depuis des années

@+

Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
C'est bizarre de pouvoir se connecter mais de ne pas avoir de synchro. Même avec Lubix la synchro ne se fait pas ?
Ceci dit, c'est vrai que Hubic est vieux mais ça marchait il y a encore quelques semaines. Il y a eu des changements quelque part (je soupçonne mono mais je n'en suis pas certain) qui font que maintenant ça plante. Ca serait bien d'avoir un coup de main de OVH mais il ne faut pas rêver. C'est pour ça que j'avais demandé le même paquetage que sous Ubuntu ou Debian.
Xuo.

OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Je n'ai pas essayé avec Lubix. Il faut que je retrouve cette appli et je ferai un test cette semaine.
@+
NB: xuo, ton lien vers la remonté de bug, n'est pas bon, on retombe sur ce post


Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Je ne sais pas ce qui n'a pas marché pour le lien. Je recommence.
https://bugs.mageia.org/show_bug.cgi?id=21656
Xuo.

OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Bon avec Lubix sous openSuse, c'est OK, mais laborieux.
J'ai l'impression que la synchro ne se fait plus automatiquement, et qu'il faut la lancer manuellement (mais je ne suis pas sur, car ça démarre au bout de 2 ou 3 min alors je n'y suis peut être pour rien).
J'ai lancé le hubic main-loop --verbose pour voir, et apparemment, tout ne va pas bien dans le meilleur des mondes

Caché :
olisuse@fixe:~> hubic main-loop --verbose
[INFO | 05/09/2017 19:20:26 | Ovh.Hubic.Backend.HubicAccountHandler..ctor] Initialize backend: Application=hubic-sync, Version=2.1.0.53, OS=unix 4.4.79.19
[INFO | 05/09/2017 19:20:26 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Application starts (Version: 2.1.0.53-64; Platform: Unix 4.4.79.19)
[DEBUG | 05/09/2017 19:20:26 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Use native FS watcher: True
Command failed: Cannot own dbus.
* Assertion at threadpool-ms.c:776, condition `threadpool' not met
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Threading.ThreadPool.RequestWorkerThread () <0x0004b>
at System.Threading.ThreadPoolWorkQueue.EnsureThreadRequested () <0x00044>
at System.Threading.ThreadPoolWorkQueue.Enqueue (System.Threading.IThreadPoolWorkItem,bool) <0x001a3>
at System.Threading.ThreadPool.QueueUserWorkItemHelper (System.Threading.WaitCallback,object,System.Threading.StackCrawlMark&,bool) <0x000ee>
at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback,object) <0x00032>
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.QueueUserWorkItem (System.Action`1<object>,object) <0x00118>
at System.Reactive.Concurrency.DefaultScheduler.Schedule<System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>> (System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>,System.Func`3<System.Reactive.Concurrency.IScheduler, System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>, System.IDisposable>
<0x00245>
at System.Reactive.Concurrency.Scheduler.Schedule<TState_REF> (System.Reactive.Concurrency.IScheduler,TState_REF,System.Action`2<TState_REF, System.Action`1<TState_REF>>
<0x00147>
at System.Reactive.ScheduledObserver`1<T_REF>.EnsureActive () <0x0020f>
at System.Reactive.ObserveOnObserver`1<T_REF>.OnCompletedCore () <0x0001b>
at System.Reactive.ObserverBase`1<T_REF>.OnCompleted () <0x00039>
at System.Reactive.Linq.Observαble.RefCount`1/_<TSource_REF>.OnCompleted () <0x00030>
at System.Reactive.Subjects.Subject`1<T_REF>.OnCompleted () <0x0017b>
at System.Reactive.Linq.Observαble.AsObservable`1/_<TSource_REF>.OnCompleted () <0x00030>
at System.Reactive.AutoDetachObserver`1<T_REF>.OnCompletedCore () <0x00033>
at System.Reactive.ObserverBase`1<T_REF>.OnCompleted () <0x00039>
at Ovh.Hubic.Sync.RootPathController.Finalize () <0x00022>
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0x00060>
Native stacktrace:
mono() [0x4b2b58]
/lib64/libpthread.so.0(+0x10b10) [0x7ff82c618b10]
/lib64/libc.so.6(gsignal+0x37) [0x7ff82c0828d7]
/lib64/libc.so.6(abort+0x13a) [0x7ff82c083caa]
mono() [0x659169]
mono() [0x65936f]
mono() [0x6594b6]
mono() [0x5a3a8c]
[0x4123721c]
Debug info from gdb:
[New LWP 2896]
[New LWP 2897]
[New LWP 2898]
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/olisuse/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/olisuse/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Id Target Id Frame
* 1 Thread 0x7ff82d120740 (LWP 2895) "Main" 0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
2 Thread 0x7ff82b7ff700 (LWP 2896) "SGen worker" 0x00007ff82c6150bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
3 Thread 0x7ff829532700 (LWP 2897) "Finalizer" 0x00007ff82c618736 in waitpid () from /lib64/libpthread.so.0
4 Thread 0x7ff823d38700 (LWP 2898) "Timer-Scheduler" 0x00007ff82c6170ca in do_futex_wait.constprop () from /lib64/libpthread.so.0
Thread 4 (Thread 0x7ff823d38700 (LWP 2898)):
#0 0x00007ff82c6170ca in do_futex_wait.constprop () from /lib64/libpthread.so.0
#1 0x00007ff82c617171 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x000000000064f2d0 in ?? ()
#3 0x000000000059d3dd in ?? ()
#4 0x000000000059d501 in ?? ()
#5 0x000000000059edf6 in ?? ()
#6 0x000000004120e0c8 in ?? ()
#7 0x0000000000000038 in ?? ()
#8 0x0000000001378bc8 in ?? ()
#9 0x0000000000000bb7 in ?? ()
#10 0x00007ff82b9e3c28 in ?? ()
#11 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7ff829532700 (LWP 2897)):
#0 0x00007ff82c618736 in waitpid () from /lib64/libpthread.so.0
#1 0x00000000004b2c1e in ?? ()
#2 <signal handler called>
#3 0x00007ff82c0828d7 in raise () from /lib64/libc.so.6
#4 0x00007ff82c083caa in abort () from /lib64/libc.so.6
#5 0x0000000000659169 in ?? ()
#6 0x000000000065936f in ?? ()
#7 0x00000000006594b6 in ?? ()
#8 0x00000000005a3a8c in ?? ()
#9 0x000000004123721c in ?? ()
#10 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ff82b7ff700 (LWP 2896)):
#0 0x00007ff82c6150bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000622c3f in ?? ()
#2 0x00007ff82c610744 in start_thread () from /lib64/libpthread.so.0
#3 0x00007ff82c137aad in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ff82d120740 (LWP 2895)):
#0 0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000628db2 in ?? ()
#2 0x000000000063e413 in ?? ()
#3 0x00000000005bc4ab in ?? ()
#4 0x00000000005bd2d4 in mono_domain_finalize ()
#5 0x0000000000424d24 in ?? ()
#6 0x0000000000549dbb in ?? ()
#7 0x0000000041235812 in ?? ()
#8 0x00007ffefb09b0d0 in ?? ()
#9 0x00007ffefb09b0c0 in ?? ()
#10 0x0000000000a96098 in ?? ()
#11 0x00007ffefb09b0c0 in ?? ()
#12 0x000000004115ef30 in ?? ()
#13 0x0000000000abbae0 in ?? ()
#14 0x00007ffefb09aa50 in ?? ()
#15 0x00007ffefb09ac60 in ?? ()
#16 0x00007ffefb09aa80 in ?? ()
#17 0x000000004115f547 in ?? ()
#18 0x0000000000000000 in ?? ()
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Abandon (core dumped)
[INFO | 05/09/2017 19:20:26 | Ovh.Hubic.Backend.HubicAccountHandler..ctor] Initialize backend: Application=hubic-sync, Version=2.1.0.53, OS=unix 4.4.79.19
[INFO | 05/09/2017 19:20:26 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Application starts (Version: 2.1.0.53-64; Platform: Unix 4.4.79.19)
[DEBUG | 05/09/2017 19:20:26 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Use native FS watcher: True
Command failed: Cannot own dbus.
* Assertion at threadpool-ms.c:776, condition `threadpool' not met
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Threading.ThreadPool.RequestWorkerThread () <0x0004b>
at System.Threading.ThreadPoolWorkQueue.EnsureThreadRequested () <0x00044>
at System.Threading.ThreadPoolWorkQueue.Enqueue (System.Threading.IThreadPoolWorkItem,bool) <0x001a3>
at System.Threading.ThreadPool.QueueUserWorkItemHelper (System.Threading.WaitCallback,object,System.Threading.StackCrawlMark&,bool) <0x000ee>
at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback,object) <0x00032>
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.QueueUserWorkItem (System.Action`1<object>,object) <0x00118>
at System.Reactive.Concurrency.DefaultScheduler.Schedule<System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>> (System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>,System.Func`3<System.Reactive.Concurrency.IScheduler, System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>, System.IDisposable>

at System.Reactive.Concurrency.Scheduler.Schedule<TState_REF> (System.Reactive.Concurrency.IScheduler,TState_REF,System.Action`2<TState_REF, System.Action`1<TState_REF>>

at System.Reactive.ScheduledObserver`1<T_REF>.EnsureActive () <0x0020f>
at System.Reactive.ObserveOnObserver`1<T_REF>.OnCompletedCore () <0x0001b>
at System.Reactive.ObserverBase`1<T_REF>.OnCompleted () <0x00039>
at System.Reactive.Linq.Observαble.RefCount`1/_<TSource_REF>.OnCompleted () <0x00030>
at System.Reactive.Subjects.Subject`1<T_REF>.OnCompleted () <0x0017b>
at System.Reactive.Linq.Observαble.AsObservable`1/_<TSource_REF>.OnCompleted () <0x00030>
at System.Reactive.AutoDetachObserver`1<T_REF>.OnCompletedCore () <0x00033>
at System.Reactive.ObserverBase`1<T_REF>.OnCompleted () <0x00039>
at Ovh.Hubic.Sync.RootPathController.Finalize () <0x00022>
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0x00060>
Native stacktrace:
mono() [0x4b2b58]
/lib64/libpthread.so.0(+0x10b10) [0x7ff82c618b10]
/lib64/libc.so.6(gsignal+0x37) [0x7ff82c0828d7]
/lib64/libc.so.6(abort+0x13a) [0x7ff82c083caa]
mono() [0x659169]
mono() [0x65936f]
mono() [0x6594b6]
mono() [0x5a3a8c]
[0x4123721c]
Debug info from gdb:
[New LWP 2896]
[New LWP 2897]
[New LWP 2898]
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/olisuse/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/olisuse/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Id Target Id Frame
* 1 Thread 0x7ff82d120740 (LWP 2895) "Main" 0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
2 Thread 0x7ff82b7ff700 (LWP 2896) "SGen worker" 0x00007ff82c6150bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
3 Thread 0x7ff829532700 (LWP 2897) "Finalizer" 0x00007ff82c618736 in waitpid () from /lib64/libpthread.so.0
4 Thread 0x7ff823d38700 (LWP 2898) "Timer-Scheduler" 0x00007ff82c6170ca in do_futex_wait.constprop () from /lib64/libpthread.so.0
Thread 4 (Thread 0x7ff823d38700 (LWP 2898)):
#0 0x00007ff82c6170ca in do_futex_wait.constprop () from /lib64/libpthread.so.0
#1 0x00007ff82c617171 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x000000000064f2d0 in ?? ()
#3 0x000000000059d3dd in ?? ()
#4 0x000000000059d501 in ?? ()
#5 0x000000000059edf6 in ?? ()
#6 0x000000004120e0c8 in ?? ()
#7 0x0000000000000038 in ?? ()
#8 0x0000000001378bc8 in ?? ()
#9 0x0000000000000bb7 in ?? ()
#10 0x00007ff82b9e3c28 in ?? ()
#11 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7ff829532700 (LWP 2897)):
#0 0x00007ff82c618736 in waitpid () from /lib64/libpthread.so.0
#1 0x00000000004b2c1e in ?? ()
#2 <signal handler called>
#3 0x00007ff82c0828d7 in raise () from /lib64/libc.so.6
#4 0x00007ff82c083caa in abort () from /lib64/libc.so.6
#5 0x0000000000659169 in ?? ()
#6 0x000000000065936f in ?? ()
#7 0x00000000006594b6 in ?? ()
#8 0x00000000005a3a8c in ?? ()
#9 0x000000004123721c in ?? ()
#10 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ff82b7ff700 (LWP 2896)):
#0 0x00007ff82c6150bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000622c3f in ?? ()
#2 0x00007ff82c610744 in start_thread () from /lib64/libpthread.so.0
#3 0x00007ff82c137aad in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ff82d120740 (LWP 2895)):
#0 0x00007ff82c615468 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000628db2 in ?? ()
#2 0x000000000063e413 in ?? ()
#3 0x00000000005bc4ab in ?? ()
#4 0x00000000005bd2d4 in mono_domain_finalize ()
#5 0x0000000000424d24 in ?? ()
#6 0x0000000000549dbb in ?? ()
#7 0x0000000041235812 in ?? ()
#8 0x00007ffefb09b0d0 in ?? ()
#9 0x00007ffefb09b0c0 in ?? ()
#10 0x0000000000a96098 in ?? ()
#11 0x00007ffefb09b0c0 in ?? ()
#12 0x000000004115ef30 in ?? ()
#13 0x0000000000abbae0 in ?? ()
#14 0x00007ffefb09aa50 in ?? ()
#15 0x00007ffefb09ac60 in ?? ()
#16 0x00007ffefb09aa80 in ?? ()
#17 0x000000004115f547 in ?? ()
#18 0x0000000000000000 in ?? ()
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Abandon (core dumped)
Bref, ça tombe en marche de temps à autre, mais c'est toujours mieux que sur Mageia 6 ou la connexion est refusée.
@+

Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)

OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Code BASH :
$ hubic login xxxxx@xxxx /home/ops/hubiC Password [Error] Timeout. Command failed: System.InvalidOperationException: Cannot log in.
Caché :
$ hubic main-loop --verbose
[INFO | 05/09/2017 20:56:24 | Ovh.Hubic.Backend.HubicAccountHandler..ctor] Initialize backend: Application=hubic-sync, Version=2.1.0.53, OS=unix 4.9.40.1
[INFO | 05/09/2017 20:56:25 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Application starts (Version: 2.1.0.53-64; Platform: Unix 4.9.40.1)
[DEBUG | 05/09/2017 20:56:25 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Use native FS watcher: True
Command failed: Cannot own dbus.
* Assertion at threadpool-ms.c:723, condition `threadpool' not met
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Threading.ThreadPool.RequestWorkerThread () <0xffffffff>
at System.Threading.ThreadPoolWorkQueue.EnsureThreadRequested () <0x00047>
at System.Threading.ThreadPoolWorkQueue.Enqueue (System.Threading.IThreadPoolWorkItem,bool) <0x00183>
at System.Threading.ThreadPool.QueueUserWorkItemHelper (System.Threading.WaitCallback,object,System.Threading.StackCrawlMark&,bool) <0x000db>
at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback,object) <0x00033>
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.QueueUserWorkItem (System.Action`1<object>,object) <0x00103>
at System.Reactive.Concurrency.DefaultScheduler.Schedule<System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>> (System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>,System.Func`3<System.Reactive.Concurrency.IScheduler, System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>, System.IDisposable>
<0x00231>
at System.Reactive.Concurrency.Scheduler.Schedule<T_REF> (System.Reactive.Concurrency.IScheduler,T_REF,System.Action`2<T_REF, System.Action`1<T_REF>>
<0x00143>
at System.Reactive.ScheduledObserver`1<TKey_REF>.EnsureActive () <0x001b3>
at System.Reactive.ObserveOnObserver`1<TKey_REF>.OnCompletedCore () <0x0001b>
at System.Reactive.ObserverBase`1<TKey_REF>.OnCompleted () <0x00039>
at System.Reactive.Linq.Observαble.RefCount`1/_<TKey_REF>.OnCompleted () <0x00030>
at System.Reactive.Subjects.Subject`1<TKey_REF>.OnCompleted () <0x0017b>
at System.Reactive.Linq.Observαble.AsObservable`1/_<TKey_REF>.OnCompleted () <0x00030>
at System.Reactive.AutoDetachObserver`1<TKey_REF>.OnCompletedCore () <0x00033>
at System.Reactive.ObserverBase`1<TKey_REF>.OnCompleted () <0x00039>
at Ovh.Hubic.Sync.RootPathController.Finalize () <0x00022>
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono() [0x49ffc5]
/lib64/libpthread.so.0(+0x10bb0) [0x7f18e1d5bbb0]
/lib64/libc.so.6(gsignal+0x38) [0x7f18e19cb818]
/lib64/libc.so.6(abort+0x16a) [0x7f18e19ccf2a]
mono() [0x629129]
mono() [0x62934f]
mono() [0x629496]
mono() [0x588c5b]
[0x41c0d39c]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Abandon (core dumped)
[INFO | 05/09/2017 20:56:24 | Ovh.Hubic.Backend.HubicAccountHandler..ctor] Initialize backend: Application=hubic-sync, Version=2.1.0.53, OS=unix 4.9.40.1
[INFO | 05/09/2017 20:56:25 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Application starts (Version: 2.1.0.53-64; Platform: Unix 4.9.40.1)
[DEBUG | 05/09/2017 20:56:25 | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Use native FS watcher: True
Command failed: Cannot own dbus.
* Assertion at threadpool-ms.c:723, condition `threadpool' not met
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Threading.ThreadPool.RequestWorkerThread () <0xffffffff>
at System.Threading.ThreadPoolWorkQueue.EnsureThreadRequested () <0x00047>
at System.Threading.ThreadPoolWorkQueue.Enqueue (System.Threading.IThreadPoolWorkItem,bool) <0x00183>
at System.Threading.ThreadPool.QueueUserWorkItemHelper (System.Threading.WaitCallback,object,System.Threading.StackCrawlMark&,bool) <0x000db>
at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback,object) <0x00033>
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.QueueUserWorkItem (System.Action`1<object>,object) <0x00103>
at System.Reactive.Concurrency.DefaultScheduler.Schedule<System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>> (System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>,System.Func`3<System.Reactive.Concurrency.IScheduler, System.Reactive.Concurrency.Scheduler/Pair`2<object, System.Action`2<object, System.Action`1<object>>>, System.IDisposable>

at System.Reactive.Concurrency.Scheduler.Schedule<T_REF> (System.Reactive.Concurrency.IScheduler,T_REF,System.Action`2<T_REF, System.Action`1<T_REF>>

at System.Reactive.ScheduledObserver`1<TKey_REF>.EnsureActive () <0x001b3>
at System.Reactive.ObserveOnObserver`1<TKey_REF>.OnCompletedCore () <0x0001b>
at System.Reactive.ObserverBase`1<TKey_REF>.OnCompleted () <0x00039>
at System.Reactive.Linq.Observαble.RefCount`1/_<TKey_REF>.OnCompleted () <0x00030>
at System.Reactive.Subjects.Subject`1<TKey_REF>.OnCompleted () <0x0017b>
at System.Reactive.Linq.Observαble.AsObservable`1/_<TKey_REF>.OnCompleted () <0x00030>
at System.Reactive.AutoDetachObserver`1<TKey_REF>.OnCompletedCore () <0x00033>
at System.Reactive.ObserverBase`1<TKey_REF>.OnCompleted () <0x00039>
at Ovh.Hubic.Sync.RootPathController.Finalize () <0x00022>
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono() [0x49ffc5]
/lib64/libpthread.so.0(+0x10bb0) [0x7f18e1d5bbb0]
/lib64/libc.so.6(gsignal+0x38) [0x7f18e19cb818]
/lib64/libc.so.6(abort+0x16a) [0x7f18e19ccf2a]
mono() [0x629129]
mono() [0x62934f]
mono() [0x629496]
mono() [0x588c5b]
[0x41c0d39c]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Abandon (core dumped)
Bref, beaucoup d'erreur concernant mono, que ce soit sur Mageia ou openSuse.
@+

Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'avais essayé avec la version Mageia5 de mono, mais ça n'avait pas marché non plus. Ce week-end je vais essayer à nouveau pour être sûr que je n'avais pas fait de bêtise.
Xuo.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie