I've met this issue when try to upgrade octopus 15.2.17 to 16.2.13 last night.
Upgrade process failed at mgr module phase after the new MGR version become to
active state. I tried to enable debug `ceph config set mgr
mgr/cephadm/log_to_cluster_level debug
` and I saw the message like @xadhoom76
Main error now is
[ERR] MGR_MODULE_ERROR: Module 'cephadm' has failed: Expecting value: line 1
column 1 (char 0)
Module 'cephadm' has failed: Expecting value: line 1 column 1 (char 0)
If we disable cephadm, the health becomes ok.
So is there a way to change the cephadm's version ?
Mar
cephadm is 16.2.11, because the error comes from the upgrade from 15 to 16.
Il giorno lun 13 mar 2023 alle ore 18:27 Clyso GmbH - Ceph Foundation
Member ha scritto:
> which version of cephadm you are using?
>
> ___
> Clyso GmbH - Ceph Foundation Member
>
> Am
which version of cephadm you are using?
___
Clyso GmbH - Ceph Foundation Member
Am 10.03.23 um 11:17 schrieb xadhoo...@gmail.com:
looking at ceph orch upgrade check
I find out
},
The things in "ceph orch ps" output are gathered by checking the contents
of the /var/lib/ceph// directory on the host. Those
"cephadm." files get deployed normally though, and aren't usually
reported in "ceph orch ps" as it should only report things that are
directories rather than files. You
looking at ceph orch upgrade check
I find out
},
"cephadm.8d0364fef6c92fc3580b0d022e32241348e6f11a7694d2b957cdafcb9d059ff2": {
"current_id": null,
"current_name": null,
"current_version": null
},
Could this lead to the issue?
I find out with ceph orch ps
cephadm.8d0364fef6c92fc3580b0d022e32241348e6f11a7694d2b957cdafcb9d059ff2
srvcephprod04 stopped4m ago -
I cannnot find anything interesting in the cephadm.log
now the error is
HEALTH_ERR
Module 'cephadm' has failed: 'cephadm'
Idea how to fix it ?
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to
that looks like it was expecting a json structure somewhere and got a blank
string. Is there anything in the logs (ceph log last 100 info cephadm)? If
not, might be worth trying a couple mgr failovers (I'm assuming only one
got upgraded, so first failover would go back to the 15.2.17 one and then
