SDK Updating SSH device config kills all deployment targets

Bug Reports
#1

REPRODUCIBILITY: 100%
OS VERSION: 4.4.0.58/64 - sdk on ubuntu 20
HARDWARE: Volla/Xperia 10ii
UI LANGUAGE: en
REGRESSION: ummm.

DESCRIPTION:

Regardless which target (even ones using devices I did not touch) get these errors:

16:36:41: The process "/home/mwa/SailfishOS/bin/sfdk" exited with code 1.
Error while building/deploying project harbour-stopmotion (kit: SailfishOS-4.4.0.58-aarch64 (in Sailfish SDK Build Engine))
When executing step "RPM Deploy"

PRECONDITIONS:

I had one device where pub key was deployed, but I had somehow configured it with passwords. Today, I updated the ssh config (to be identical to another phone using a passwordless key).

STEPS TO REPRODUCE:

  1. add a device, authorize with PW instead of keys. (worked fine since April)
  2. change ssh config on device (don’t permit password, switch to keys)

EXPECTED RESULT:

After adding the device from scratch, expect it to work with the SDK

ACTUAL RESULT:

ALL RUN deployments now fail.

Removing a target and adding back doesn’t help.

Removing devices and adding them does not help.

#2

Amazing. Removing all targets and all devices does not help. Classic. What a pain in the… so I waste an evening re-installing this thing instead of debugging ALL THE OTHER bugs. Sigh.

#3

What does this mean:

The kit SailfishOS-4.4.0.58-aarch64 (in Sailfish SDK Build Engine) has configuration issues which might be the root cause for this problem.

'issues, is something that soccer dads have when then can’t get fuel for the SUV. What I’m experiencing are error messages that have NO MEANING. Argh.

1 Like
#4

Get’s better and better. Delete all cache/config and SDK directory foo. Try to re-install from scratch:

As usual errors ‘en masse’ and the final indignity:

All settings files found in directory "/home/mwa/src/sailfish/harbour-stopmotion/harbour-stopmotion.pro.user" were unsuitable for the current version of Qt Creator, for instance because they were written by an incompatible version of Qt Creator, or because a different settings path was used.
#5

Oh, dear. Even worse. Same error. Including one device that was not changed at all. I’m friggin stuck.

#6

Stranger and stranger. Now, after adding the SFOS 3.4 target device (a vollaphone) back, with the exact same settings sshd_config, same contents for .ssh, same permisssions, etc, I can deploy to 3.4 arm.

No dice with the aarch64 target with the same keys. Which test fine (sftp, rsync, all green). I’m so bloody tired.

#7

No idea how or why. Added a second Volla 64 bit device with the same configuration and it worked. Reverted the SSH config on the initial developer device, added it again, and it works. No idea what that was all about.

#8

It tells you you should check the kit option page under Tools > Options > Kits, where you would likely see a warning icon over the kit, indicating some configuration issues that are not considered fatal for overall use of the kit, but likely breaking some use cases. Further details would be found in the tool tip or so.

#9

I tried everything. Before a complete re-install, I went though removing and adding kits with restarts in between. I also looked at the devices.xml and targets.xml files to see if anything looked odd.

Why one kit (aarch64) and one device’s SSH could interfere with others is a mystery to me.

I believe there are ALWAYS warning icons present on the 3.4 targets.

In the end, I didn’t have time to diagnose so I re-installed and tested devices /kits one after the other. Before adding the original ‘trouble’ maker device back, I reverted it’s sshd_config (which permitted password logins) and then added it.