Full SFOS downgrade / SailJail access issues in JBoy [solved]

General
#1

It’s been a while since I’ve familiarised myself with any of the flashing or backup tools for SFOS, probably since first flashing the 2.x.x images to my Xperia X F5121 upon release.

Unfortunately, I need to go back to 2.x.x temporarily to recover data from an abandoned app with no source code released.
I’m currently on 4.5.0.18 and need a refresher on tools and steps to:

  • create a full partition/image backup of the phone’s current state which can be returned to after a downgrade.
  • flashing older 2.x.x images to the device successfully (and in turn, the same for 4.x.x images upon my return)

I did scour this and the older forum for guides on this, but nothing immediately obvious stood out.

Are the most comprehensive and up-to-date guides on this here?

I’d appreciate any guides/resources/tooling to accomplish this.

#2

Just curious what app is that and why not attempt to extract the data that interests you from whatever image you have? Flashing 2.x if you have the image should probably follow same procedure as always, getting a full backup to which you can return painlessly not so much, even with apps that help in backing application data, not many implement this, so you’ll probably have to reinstall/resetup a ton of apps on your return. There is no easy way to make a flashable image of current phone state with everything afaik (like it used to be easy on n900), so it looks like a big endeavour

#3

JBoy or any of the other derivatives from the same author. Most saves were made using the proprietary save-state feature, instead of the more compatible battery save (.sav). No source code was released by the author and the apps ceased to operate since the introduction of SFOS 3.x.x (Error #7 - Folder can’t be opened). The battery saves I did make work across all other emulators on all platforms, but the mechanism used for the save-states (unfortunately, the ones I used more commonly) are not compatible with any other known emulator or any of the GNUboy derivatives.

Unfortunately, I deleted my last SFOS 2.1.x image from all backups just months ago, believing it to never be of any value, before I realised the situation with JBoy.

Now, it looks like I will have to build my own image from source.

I have accomplished some imaging and restoration with the android adb, fastboot and TWRP tools for other OSes like LineageOS.

What about dding the partitions or entire block device? Is this not an option?

#4

Try emulator in the SDK to load the save and save as the second way? After reflash back to 4.4 there will be some rng’d uids in sqlite/dconf/… (this will cause all kinds of issues if you just try to copy back /home/…) There is no easy way to make a full device backup, My Backup from open repos will help with some apps that implement hooks for it, but most don’t. I’ve had a quick look after having to reflash jolla C after almost a decade of usage and getting back to 4.x takes ages, sadly there weren’t any tools like this then, maybe someone figured it out in the meantime and I missed it, but doubt. (then again maybe someone has a working dd’type way so who knows, worth waiting befoe you go 2.x as getting back will sink a lot of time)

#5

I’m not familiar with the SDK, but it sounds like a more viable option. Do you have more info on setting up the developer environment for this and where to get it?

Can the SDK support environment configurations for SFOS 2.x.x apps ?

#6

If you could get your hands on earlier release of sfos sdk you could try to run jboy in 2.x emulator, on phone right now so can’t check if legacy versions are available, but digging that out could save a bit of time (then again 2.0 was close to decade ago, wouldn’t be surprised if links are dead etc)

#7

Btw have you looked through openrepos comments, some people suggest changing busybox cli tools to gnu versions helped for 3.3 sfos (and some patch?) so maybe you can fix the app itself and skip the whole decade timejump?

1080×2520 917 KB

#8

Yes, there are significant time jumps in 2.x.x lifecycle from 2014 to 2019. 2.1.4 and 2.2.0 look to be the most reassuring options, given that any SDKs for those are more likely to still be available.

I did not spot that around the busybox switch. I would be more inclined to consider that first.

#9

The user BlacksheepGER has plenty of old releases: GitHub - black-sheep-dev/sailfish-os-torrents: Collection of torrent files for older Sailfish OS releases.

1 Like
#10

A perl oneliner to fix expected value, worth trying that first, could save hours

#11

@emva Spotted that, but there are no seeders for the older versions: Download older version of SailfishOS - #39 by jimjamz

#12

Yes, that would be quite the concise fix if that was to work. I will look at running that, and then a busybox replacement if the former fails.

1 Like
#13

Sadly, the perl invocation of the sed script does not work for the latest error I receive. I do remember seeing this comment now, when I first encountered the error I have, and realising that the solution offered is for a different error type and use case scenario.

The issue in the OpenRepos comments pertains to ‘Error #3’. It is based on what the author of the comment describes, and the perl solution offered is to bypass the error received when loading a ROM (something I cannot get to - Error #7 occurs upon launching the JBoy app. It’s not even possible to reach the step of opening a ROM, so although I’m about to try replacing the busybox tools, I don’t anticipate this solving Error #7.

1 Like
#14

Maybe 3.3 sfos image/sources/sdk+emulator will be easier to find, should work with the perl trick (3.4 might also and this being last J1 supported version should be seeded more reliably)

#15

Sounds like a classic access issue caused by the introduction of SailJail. You may try adding the usual disabling entry to the app’s desktop file first, before taking this long re-flashing detour.

1 Like
#16

Hi @olf

I missed out on a lot of the changelog since 2.x.x so am not familiar with SailJail and the issues it caused.
After a quick search on the topic, is the only addition to the app’s .desktop file that would be required?:

[X-Sailjail]
Sandboxing=Disabled
1 Like
#17

Yes.

And it’s best done by creating a desktop file of the same name at /etc/sailjail/applications, containing just those lines.

4 Likes
#18

It’s working. Thank you for the support guys, it’s much appreciated.

It just shows that being out of the loop for a few releases, a lot of things have come along and changed/broken a few things that have required a few adjustments/workarounds I’m not familiar with.

You have indeed saved me hours, if not days of work. Many thanks.

3 Likes
#19

@jimjamz, it would be nice to report the steps you took in a comment for JBoy at OpenRepos, likely:

  1. devel-su pkcon remove symlinks-busybox-bash # This might be wrong, I am typing this by faintly remembering! Please check.
  2. devel-su echo -e "[X-Sailjail]\nSandboxing=Disabled" > /etc/sailjail/applications/harbour-jboy.desktop # Is the apps’ desktop file name correct? I have no idea!

And please tell there, what your statement “It’s working.” means: Is the app fully functional again or something else?

2 Likes
#20

@olf I will follow up with a report on the comments over at OpenRepos, and provide the results of my testing. I will also backlink to this topic here.

In the end, removing/replacing the busybox binaries was not required. SailJail seemed to be the issue in its entirety. Adding the .desktop file in /etc/sailjail/applications and updating the .desktop in /usr/share/applications was sufficient enough.

1 Like