Module 'volumes' has failed dependency: /lib/python3/dist-packages/cephfs.cpython-37m-x86_64-linux-gnu.so: undefined symbol: ceph_abort_conn

and dpkg -S /usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0 on the bad node?
 
LANG=CC dpkg -S /usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0 dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0
 
that is rather strange.. did you ever install ceph in some non-package fashion on this system? could you try dpkg -S libceph-common?
 
fabian said:
that is rather strange.. did you ever install ceph in some non-package fashion on this system? could you try dpkg -S libceph-common?
Click to expand...
dpkg -S libceph-common librados2: /usr/lib/ceph/libceph-common.so.2

No, I use the same sources on the entire cluster, I have 3 clusters using that configuration, and one node, that's behaving like this!
I have manually created some symlinks to match those on the working node, so currently the system's running, however, the root-cause for this is far more strange, and I hate to see me re-setup that node...
 
well, it seems you have (at least) one stray library file that is not owned by any package (/usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0). you can likely remove it without any negative consequences, but the question remains how it ended up there (and whether there are others like it).

dpkg is pretty strict about file handling during package installation/upgrades/removal, so it should be virtually impossible to end up in this situation without
- (badly) manually fixing up an interrupted upgrade/package installation
- installing software via some other mechanism rather than via packages
 
You must log in or register to reply here.
Top Bottom
Back