All the apps came back after another reboot. I had tried several prior to this. See my thread Core apps not opening after 4.4 update - #2 by AlanBreen
I’ve rebooted several times, but that didn’t solve the problem. I tried “sfos-upgrade --verify”:
[root@XperiaXA2 nemo]# sfos-upgrade --verify
Notice: Do you want to ensure this SailfishOS 184.108.40.206 installation to be complete and up to date? (y/N) y
Notice: For troubleshooting issues with the upgrade proper, please consult https://jolla.zendesk.com/hc/en-us/articles/360005795474 - Stopping osupdate-check.timer - Stopping aliendalvik.service - Setting SSU to SailfishOS release: Changing release from 220.127.116.11 to 18.104.22.168 Your device is now in release mode! - Fetching and installing the SailfishOS upgrade from 22.214.171.124 to 126.96.36.199 (this may take a while): REFRESHING CACHE AND DOWNLOADING PACKAGES Finished transaction (status=2, runtime=102319ms) NO UPDATES FOUND. Try again later.
Notice: After rebooting, do not miss to run post_sfos-upgrade
then i reboot and try post_sfos-upgrade
[root@XperiaXA2 nemo]# post_sfos-upgrade - Cleaning logfiles of duplicate entries. - systemupdate_188.8.131.52-from-184.108.40.206_2022-03-30t13-57-18.log-dupes.txt: O.K. Summary: Processed 1 untidy log file(s) in /var/log successfully. - Removing outdated Store version info. - Refreshing pkcon's caches: Refreshing cache Starting Refreshing software list Finished - Checking for updates per pkcon: Getting updates Finished No packages require updating to newer versions. [root@XperiaXA2 nemo]#
But browser, e-mail and other programs do not start. To put it more precisely: When trying to start programs, “nothing” happens. As if the query about “sandboxing” should open here, but it is not shown
I ended up re-flashing my X after a disastrous upgrade broke everything.
I haven’t been able to log in to Dropbox to recover my backup, something broken with that facility in 4.4
i try to reinstall the “broken” apps, but
[root@XperiaXA2 nemo]# pkcon install --allow-reinstall sailfish-browser Auflösen Abfragen Änderungen werden getestet Fertig Schwerwiegender Fehler: das zu installierende sailfish-browser-220.127.116.11-1.25.1.jolla.armv7hl erfordert 'libnemotransferengine-qt5.so.2', aber diese Anforderung kann nicht bereitgestellt werden [root@XperiaXA2 nemo]#
Is there really no solution to completely re-flash the device??
Dropbox works only through gmail account linking, if you use it to download/restore backup it will stop working, have to delete it and add again
Is that a new “feature”? I have had a Dropbox account that has worked fine until now
It’s like this since 4.1 apparently, but should work if usb/mmc are not an option (just create a dummy gmail/dropbox account for the restore)
ok… i re-flashed my XA2 and now i try to restore the data from the backup.
But: the restore aborts with the notes No contacts were restored either. What the f*ck! Why did I create a backup?
Does anyone have an idea how I can get the data?
Create the symlink nemo->defaultuser or mount/unzip with approriate tool…
When the update is being downloaded, all the repositiories get switched to 18.104.22.168. Interrupting the download of the update leaves the system in such a state…
It happened to me too when I interrupted downloading the 4.4 update. I realized it when I then tried to download the ofono package from 22.214.171.124 (to replace my patched version that the update was complaining about) and it downloaded it from 126.96.36.199 repo instead, which broke telephony.
I fixed it as follows:
- ssu re 188.8.131.52 (or whatever version you really have)
- ssu ur
- pkcon refresh
Then make sure that the correct version is set by typing:
- ssu re
- ssu repos
This should correct the version to the one you really have and you should be able to redownload broken packages, and then restart and apply the 4.4 update.
Thanks, but a wee bit late . I re-flashed my phone last night . But your help will help some later, thanks for posting here!
But honestly. We’re on SailfishOS version 4.4 and Jolla can’t get a clean update process and the backup tool is a joke too?
Why does the backup abort when encountering an error of ONE part? I have now made a copy of the backup file and edited it with 7Zip: Deleted the “Notes” folder. And then I was able to import the backup. Only the notes are missing.
I think it was no good idea to keep a two way strategy at the moment of the change from nemo to defaultuser. So every update must or should take care that some users still have the old nemo paths, and as we see it doesn’t work in many cases.
So I suggest to reflash all devices that have still nemo as username. I also did so, i think it was at update from 3.4 to 4.0 . I think this spared a lot of time and trouble.
I think I’ve found the reason why the notes can’t be saved or restored!
I looked at the “notes.sql” in the backup-file and it consists mostly of… astronomical orbit data . They come from the “Stellarium” app.
INSERT INTO notes ("pagenr", "color", "body") VALUES (8, '#00b315', '# ssystem_minor.ini new in Stellarium 0.16, with additions for SoCiS2016. # Some clean-up can be done when processing this file for V0.16. # - NEW: split ssystem.ini (planets and moons) available in program folder from ssystem_minor.ini in user data directory. # - all occurrences of tex_halo (not used as of 0.15 and earlier; already removed.) # - all occurrences of texture=nomap.png are redundant (now simply loaded as default) # - all occurences of parent=Sun (default when loading). Keep parent=none for sun. # - lighting=(true|false) will be ignored (processed like previous "true") # - color=1.0,1.0,1.0 (now loaded as default; This influences the halo color and should always have at least one component 1.0.) # Default values in the loader, to be removed from ssystem.ini: # - hidden=false # - halo=true (changed from false: false only SSobserver, EarthObserver and Sun.) # - albedo=0.25 # - roughness=0.90 # - texmap=nomap.png # - parent=Sun # - outgas_intensity=0.10 (comets only) # - outgas_falloff=0.10 (comets only) # - dust_widthfactor=1.50 (comets only) # - dust_lengthfactor=0.4 (comets only) # - dust_brightnessfactor=1.5 (comets only) [c2020f3(neowise)] orbit_good = 1000 absolute_magnitude = 7.5 coord_func = comet_orbit orbit_PericenterDistance = 0.294707 type = comet radius = 5 dust_widthfactor = 1.5 dust_lengthfactor = 0.4 orbit_AscendingNode = 61.0111 slope_parameter = 5.2 name = C/2020 F3 (NEOWISE) orbit_visualization_period = 2539576.6289147907 orbit_Eccentricity = 0.999191 orbit_ArgOfPericenter = 37.2743 orbit_TimeAtPericenter = 2459034.1812962964 dust_brightnessfactor = 1.5 orbit_Inclination = 128.9373 albedo = 0.1 [TeslaRoadster] # Data taken from JPL/HORIZONS type = artificial absolute_magnitude = 25.256 slope_parameter = 0.15 name = Tesla Roadster (Starman) coord_func = comet_orbit radius = 1 oblateness = 0.0 albedo = 1 lighting = true halo = true color = 1.0,1.0,1.0 tex_halo = star16x16.png tex_map = nomap.png orbit_Epoch = 2458167.500000000 orbit_TimeAtPericenter = 2458153.5979641485 orbit_PericenterDistance = 0.9860582813419811 orbit_Eccentricity = 0.2576842367146164 orbit_ArgOfPericenter = 177.3364041029062 orbit_AscendingNode = 317.3183428774018 orbit_Inclination = 1.085063111224933 [1014291998vf31] absolute_magnitude=17.199999999999999 albedo=0.14999999999999999 coord_func=comet_orbit minor_planet_number=101429 name=1998 VF31 orbit_ArgOfPericenter=310.53931 orbit_AscendingNode=221.31431000000001 orbit_Eccentricity=0.1004355 orbit_Epoch=2457600.5 orbit_Inclination=31.297239999999999 orbit_MeanAnomaly=46.178510000000003 orbit_MeanMotion=0.52378363999999999 orbit_SemiMajorAxis=1.5241747000000001 radius=2 slope_parameter=0.14999999999999999 tex_map=nomap.png type=asteroid
Your link refers to flashing an android phone.
My X 10 II already has SFOS 184.108.40.206 installed, so the bootloader is also already unlocked.
Which steps from the linked tutorial are necessary if I want to reflash my X 10 II from a Linux computer?
Step 8 entiteled Flash Sailfish X
I had an interrupted download which probably explains why I had a similar problem.
While @wetab73 correctly denoted …
… this may also happen at any other time, when a new SailfishOS release is available, see:
To avoid any mishaps (by mistyping or mis-guessing the truly installed SailfishOS release) one may use (as described in the bug report) to bring the SailfishOS installation into a consistent state again:
ssu re "$(grep -F VERSION_ID /etc/os-release | cut -s -f 2 -d "=")"
rm -f /var/cache/ssu/features.ini
Then either run
post_sfos-upgrade (if sfos-upgrade is installed),
or manually execute the “Final clean up steps” (specifically killing the store-client followed by removing its cached SailfishOS upgrade release version info),
zypper ref (if zypper is installed)
pkcon refresh (i.e., always when doing this manually instead of using
Wow, what a nasty bug! I have never experienced it myself before yesterday.
Luckily, I quickly reacted and only ofono got broken, which I then replaced with the right version. But as can be seen from other posts in this thread, for other people it had much worse consequences… It’s hard to believe that Jolla hasn’t fixed such an awful bug for so long…
From now on, with every new OS update discovered, I will always check if it didn’t mess with it again.
I one reads this forum regularly, simply switching off the
osupdate-check as described in “Workaround b.” is the appropriate solution IMO (until Jolla has fixed this issue). I definitely do not need any update-reminder (rather the contrary).