Michal Zatloukal

We've used the questing-stable version, with the edio CLI option added - it may have helped, but doesn't prevent the issue entirely. I'll see if I can try it with latest testing build.

Chiming in to say I've observed inexplicable slowdowns: * We're using clonezilla in a software test lab to restore clean OS images, several times a day in fact. * Even when using the same machine (HP Prodesk 400 G6 SFF - 9th-gen intel core vintage), same image, clonezilla sometimes finishes in 6 minutes, sometimes it can't finish within 30 minute timeout we set for the restore step. * We've observed this with alternative-stable lunar-2023-04-13 but also after upgrading to alternative stable questing-2025-10-17....

Apologies for the delay. From the messages you provided it seems when you tried the ssh connection to your Clonezilla live box, the status was still in the booting process. It is not in the ready mode for user login. Exactly - the issue is that ocs_daemonon is actually not even needed to start ssh service. The ssh service is triggered by the enabled ssh.socket, and is started by even without ocs_daemonon in the kcmd. IMHO, if having SSH running without the parameter is not desired, then the ssh.socket...

I've fixed the issue in my environment by adding a prerun command that sets up user's authorized_keys. I'd rather not rely solely on waiting, I've noticed the machine occasionally spend much longer obtaining IP or initialising iPXE. Still, I think it would be beneficial if the startup process restarted ssh service after processing the usercrypted parameter, if the service is enabled. Or perhaps ship with the ssh service masked (or the socket unit disabled), unmask/enable it when processing the daemonon...

I've fixed the issue in my environment by adding a prerun command that sets up user's authorized_keys. I'd rather not rely solely on waiting, I've noticed the machine occasionally spend much longer obtaining IP or initialising iPXE. Still, I think it would be beneficial if the startup process restarted ssh service after processing the usercrypted parameter, if the service is enabled. Or perhaps ship with the ssh service masked, unmask it when processing the daemonon option, which would only be processed...

I've fixed the issue in my environment by adding a prerun command that sets up user's authorized_keys. I'd rather not rely solely on waiting, I've noticed the machine occasionally spend much longer obtaining IP or initialising iPXE. Still, I think it would be beneficial if the startup process restarted ssh service after processing the usercrypted parameter, if the service is enabled. Or perhaps ship with the ssh service masked, unmask it by processing the daemonon option, which would only be processed...

Yes, I just tested 20250802-questing and it's happening there. FWIW, in this environment, ansible is trying to access clonezilla via SSH immediately after issuing reboot in disk-installed Windows, so if SSH service launch is triggered by access to port 22, it does happen very early. - win_reboot: shutdown_timeout: 600 reboot_timeout: 60 ignore_errors: yes - name: Wait for Clonezilla connection vars: ansible_user: user ansible_password: ... ansible_connection: ssh ansible_ssh_common_args: '-o StrictHostKeyChecking=no'...

Yes, I just tested 20250802-questing and it's happening there. FWIW, in this environment, ansible is trying to access clonezilla via SSH immediately after issuing reboot in disk-installed Windows, so if SSH service launch is triggered by access to port 22, it does happen very early. - win_reboot: shutdown_timeout: 600 reboot_timeout: 60 ignore_errors: yes - name: Wait for Clonezilla connection vars: ansible_user: user ansible_password: ... ansible_connection: ssh ansible_ssh_common_args: '-o StrictHostKeyChecking=no'...