[SDK 3.2.10] App deployment failed; rsync: unexplained error (code 255) at io.c(226)

Applications
#1

When trying to deploy any application either with Qt Creator or with the sfdk tool, it fails with

rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.3]

My computer (running Arch Linux) has rsync version 3.2.3 if that matters, rsync should be backwards compatible, right?. Connecting via SSH and sfdk device exec works fine, after I added added aes256-ctr as a cipher to my ssh configuration.

Does anyone have a clue on how to solve this?

Edit: some more information that I already have posted below:

  • I’m using the VirtualBox build engine.
  • The device is connected over Wi-Fi
SDK 3.2: unable to deploy package to emulator with Docker based build engine
#2

I had the same problem. I’m using Docker build engine. My build engine container could not connect to my device through SSH. After a restart of Docker (sudo service restart docker), everything worked again. I did not debugged deeper into it.

#3

Just like R1tschY wrote, the problem is that your build engine is not able to connect to your device. The rsync version you have installed in your arch linux does not matter, as the connection is done from the build engine which has its own rsync.
How are you connecting to the device, i.e. via USB or WiFi? What’s the IP address of your device? Are you using Docker or VirtualBox build engine?

#4

I’m using VirtualBox as the build engine, connecting to my phone over Wi-Fi. I downloaded an ran a fresh copy of the SDK installer yesterday.

The ip address of my phone usually is in the 192.168.178.20 - 192.168.178.200 range (which was the case yesterday) or in the 192.168.2.0 - 192.168.2.255. I set the USB ip address to 192.168.3.15, to avoid conflicts with the previously mentioned range.

#5

Is it possible that you added the device (in Qt Creator) using one IP address, and then changed the IP address because the address of your phone changed? There is a known bug related to that in the SDK.

#6

I’ve tried removing and readding the device as well and the SSH connection between my device and Qt Creator works just fine (tested by pressing the “Open remote shell” in the device settings, it’s just rsync which fails for some reason.

#7

Would you be so kind and show us the contents of your devices.xml? It’s located in ~/SailfishOS/vmshare. You can also send it to me via PM if you don’t want to show it to the whole world.

#8

It doesn’t contain that much sensitive information, so here you go:

<?xml version="1.0" encoding="UTF-8"?>
<devices>
    <host name="chris-pc"/>
    <engine name="Sailfish OS Build Engine" type="vbox">
        <subnet>10.220.220</subnet>
    </engine>
    <device name="Sailfish OS Emulator 3.3.0.16" type="vbox">
        <index>1</index>
        <subnet>10.220.220</subnet>
        <sshkeypath>ssh/private_keys/Sailfish_OS-Emulator-latest</sshkeypath>
        <mac>08:00:5A:11:00:01</mac>
        <username>nemo</username>
    </device>
    <device name="Xperia X" type="real">
        <ip>192.168.178.113</ip>
        <sshkeypath>$HOME/.ssh/qtc_id</sshkeypath>
        <sshport>22</sshport>
        <username>nemo</username>
    </device>
</devices>

Could the location of the sshkeypath be a problem? I’ve set and deployed it using the Qt Creator SDK’s device wizard. There’s no password on the key file or whatsoever.

I can’t really test anything different right now, since I don’t have physical access to my development machine.

#9

It shouldn’t be. I have exact same sshkeypath and it works fine. Are you sure the IP address is correct?

#10

Yes, I am. I can SSH from my shell into the phone with the given IP address and the button for testing the connection in the SDK works just fine.

#11

Can you connect to your device using command sfdk engine exec ssh -i ~/.ssh/qtc_id nemo@192.168.178.113 ?

#12

I haven’t done this on the original computer (I still haven’t physical access to it yet), but I can reproduce it on a fresh install on OpenSUSE Tumbleweed with a fresh copy of the SDK (this time running in Docker, since VirtualBox is broken). I get the following result:

chris@yangchen:~> sfdk engine exec ssh -i ~/.ssh/qtc_id nemo@192.168.3.15
The authenticity of host '192.168.3.15 (192.168.3.15)' can't be established.
ED25519 key fingerprint is SHA256:X/pfMdww/f71tnKgOlCGCTslVOij3a1s2m1koN9a/f8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.3.15' (ED25519) to the list of known hosts.
ssh_dispatch_run_fatal: Connection to 192.168.3.15 port 22: message authentication code incorrect
Error running command on the build engine: Remote process crashed.

I had the same problem on my own computer (outside the build engine), but I worked around it by forcing certain MACs for my device in ~/.ssh/config:

# USB connections to Sailfish OS
Host 192.168.3.*
  User nemo
  Ciphers aes256-ctr
  MACs hmac-sha2-512
#13

Nice. You could add the same values to /home/mersdk/.ssh/config inside the build engine.

1 Like
#14

Somehow I didn’t think of sshing into the SDK and editing the ssh config there as well at all. Thanks a lot!

This also may explain why the Qt Creator “Test SSH”-button works, while the deployment doesn’t. The Qt Creator’s SSH-connection seems to read my ~/.ssh/config, while the Build Engine uses its own instead.

Is Sailfish OS just shipping only with the older ciphers and MACs that cutting-edge distro’s tend to disable nowadays by default that’s causing this problem?

#15

Too long; Didn’t read; Want solution:

  1. Execute sfdk engine exec to launch into the build engine’s shell
  2. Edit /etc/ssh/ssh_config.sdk as root and add the folloing lines at the end of the file:
      Ciphers aes256-ctr
  MACs hmac-sha2-512
    Note the indentation with 2 spaces! It should look like this:
    # This is the Mer SDK ssh client configuration file
Host *
  […]
  Ciphers aes256-ctr
  MACs hmac-sha2-512
  3. Save, exit your text editor and the mersdk-shell (ctrl+d).
  4. Try deploying with sfdk deploy --manual. It should copy the files. sfdk deploy --sdk is still broken, but manually installing the RPM the first time and each time you change dependencies, in the remaining cases using using sfdk deploy --rsync still works fine.

How I found the solution

Just posting this here since I don’t want to feel like I’ve wasted a few hours.

That didn’t entirely work. After some digging, I found out that SFDK, which is part of Sailfish’s QtCreator fork parses JSON files, of which the one which controls sfdk deploy is located here:

This seems to call the mb2 command in the build engine, which is actually a huge shell script. This shell-script has a function named rsync_as, which instructs rsync to transport over an SSH connection which loads the configuration from /etc/ssh/ssh_config.sdk.

So I’ve added the modifications which I made in ~/.ssh/config on my machine to /etc/ssh/ssh_config.sdk in the build machine.

2 Likes
#16

I was hit by this today. I could have sworn i didn’t change anything (i.e. update) since this worked last.
In your TL;DR you point to a file that doesn’t exist, but the correct name is below.
I also found that i needed to restart the docker container to make it work… but now sfdk deploy --sdk works for me.

#17

Thank you for catching that mistake. I’ve edited my post to fix that issue.

1 Like
#18

It’s almost like the config keeps corrupting itself. :frowning:
A reinstall of the whole SDK was the only thing that fixed it for me last time around, and now, even with the fix from here, redeployed keys and anything else i could think of it still doesn’t let me deploy.
And just to add insult to injury the “test” functionality keeps claiming everything works correctly.

Any word on when this might get fixed in an official update?

#19

@ahappyhuman can you still reproduce this with the latest SDK?

If so, could you please try to SSH from build engine to your device with all the algorithms listed by ssh -G localhost |grep ^macs (executed on the build engine) one by one to see which works and which not?

This should do the trick:

macs=$(sfdk engine exec ssh -G localhost |sed -n 's/^macs //; T; s/,/ /g; p')
for mac in $macs; do
    (set -x; sfdk engine exec ssh -o MACs=$mac nemo@192.168.3.15 true)
done

Please paste your results.

It should be possible to modify your workaround to exclude the algorithm(s) that do not work for you instead of limiting to single one.

Host *
  […]
  MACs -foo