Hi again, further updates about the issue. It seems the difference is in relation to the new ssh.py that replaced the previous functionality in PR 42051<https://github.com/ceph/ceph/pull/42051>. As mentioned initially, I'm getting these problems trying to bootstrap quincy on a clean install of proxmox. It works on a clean debian installation in a vm but I have not been able to understand the difference. Bootstrapping quincy 17.2.3 on a new debian vm and then trying to add the proxmox host gives the same error about not being able to reach the host but gave me some additional information. ----- mgr.quincy-mon1.xxx [DBG] Sleeping for 60 seconds mgr.quincy-mon1.xxx [DBG] Opening connection to root@xxxxxxxxxxxxxxx with ssh options '-F /tmp/cephadm-conf-24 -i/tpm/ceph-identity-djkg' mgr.quincy-mon1.xxx [DBG] _run_cephadm : command = check-host mgr.quincy-mon1.xxx [DBG] _run_cephadm : args = ['--expect-hostname', 'pvexxxx'] mgr.quincy-mon1.xxx [DBG] args: check-host --expect-hostname pvexxxx mgr.quincy-mon1.xxx [DBG] Opening connection to root@xxxxxxxxxxxxxxx with ssh options '-F /tmp/cephadm-conf-24 -i/tpm/ceph-identity-djkg' mgr.quincy-mon1.xxx [DBG] Running comman: which python3 mgr.quincy-mon1.xxx [DBG] Connection to pvexxxx failed. Process exited with non-zero exit status 127 mgr.quincy-mon1.xxx [DBG] _reset_con close pvexxxx mgr.quincy-mon1.xxx [ERR] Unable to reach remote host pvexxxx. Process exited with non-zero exit status 127 Traceback (most recent call last): File "/usr/share/ceph/mgr/cephadm/ssh.py", line 143, in _execute_command r = await conn.run('sudo true', check=True, timeout=5) File "/lib/python3.6/site-packages/asyncssh/connection.py", line 3637, in run return await process.wait(check, timeout) File "/lib/python3.6/site-packages/asyncssh/process.py", line 1257, in wait self.returncode, stdout_data, stderr_data asyncssh.process.ProcessError: Process exited with non-zero exit status 127 During handling of the above exception, another exception occured ----- Any ideas or suggestions on how to troubleshoot further? Thanks ________________________________ Sent: 01 August 2022 16:26 Subject: Re: Failure to bootstrap cluster with cephadm - unable to reach (localhost) Hi all, Some updated information on my issue. I have now tried to bootstrap a cluster using images v17.2.2 (original attempt), v17.2.1, v17.2.3 and 16.2.10. All Quincy container images failed but the Pacific image had no problem, worked like a charm. Was there any change between Pacific and Quincy related to how hosts are added or with the container network that could point me towards an explanation? I think I'll attempt an update the cluster from Pacific to Quincy, see if that works and see if it's possible to add Quincy hosts to the cluster afterwards. Thanks _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |