# Failure to upgrade from 2.2.1.18 to 3.0.0.8

Hi all,

I'm trying to upgrade to Sailfish 3.0.0.8 on my Jolla 1 phone. I've got 6.8GB free on my disk but I still get in my /var/log/systemupdate.log

upgrade-system transaction /4522_ebaeeaab from uid 0 finished with failed after 9760ms

Distribution upgrade error: Installation aborted by user

Upgrade completed with code 2

Later on in the logs I also see

sailfish-upgrade-ui-la-system_update_failed_disk_full: en_GB (444 x 204 @ 1320)

which I don't think is the actual error message

I think the first attempt to upgrade may have really had too little disk space but it shouldn't be the case anymore.

What makes this annoying is that I can't enable developer mode anymore. It asks for my security code, asks to accept terms, then it waits a while and returns to the Developer tools page without enabling Developer mode. So I'm stuck using just Shell-Ex for debugging.

Also now using the phone is a bit difficult because the events view seems to be broken and all installs from Jolla store just hang.

Any thoughts on how to proceed or how to get the developer mode working again would be greatly appreciated

edit retag close delete

Have you balanced BTRFS (after resolving the "disk full" situation by deleting files)?

You may do that at the command line (needs root though, IIRC) or per BTRFS balance checker 2 (which is a bit tricky to use).

( 2018-11-21 18:17:13 +0200 )edit

Hello TimoR, I seem to have a very similar issue with my Jolla 1, being unable to enable developer mode included. Should you discover a method to clear the problem, without having to go through a factory set back, I would be happy to hear about it, thx -spectorr

( 2018-11-23 22:47:46 +0200 )edit

Glad to know I'm not the only one. I think resetting the factory settings is the only approach now. Has anyone done that recently with Jolla 1? Can someone confirm if the upgrade path from a very old Sailfish version to 3 still works?

( 2018-11-26 10:51:58 +0200 )edit

@spectorr, you can sure fix a broken tile in the bathroom by tearing down and rebuilding the whole house. And if the hammer is the only tool you know, then that might appear to be the only feasible approach.

BTW, you could also perform a BTRFS-balancer run at the command line of the recovery console.

@TimoR, yes.

( 2018-11-26 20:13:50 +0200 )edit

thx @olf, for my part I am absolutely certain never to have seen less free space than 6.5GB, so I had not expected a file system problem. Having had a closer look, apart from the issues described by TimoR, I find that the email app and its settings wont open, additionally seems Storeman having issues not being able to access its repositories. No patches have been installed previosly, so none have had to be deactivated or removed at any prior os-updates either. I am willing to have a closer look as per your suggestion for a file system fix, altho, to me, it seemed unrelated at first.

( 2018-12-02 16:44:12 +0200 )edit

Sort by » oldest newest most voted

I finally found time to figure out the recovery mode and ran the btrfs balance

btrfs balance start -dusage=5 /mnt


Which relocated 1 chunk. Now I get a different error when upgrading

sailfish-upgrade-ui[628]: Enabled repository: adaptation0, adaptation0
PackageKit[660]: get-repo-list transaction /4558_edbedbbb from uid 0 finished with success after 388ms
sailfish-upgrade-ui[628]: Setting the enabled state of store to false
PackageKit[660]: uid 0 is trying to obtain org.freedesktop.packagekit.system-sources-configure auth (only_trusted:0)
PackageKit[660]: uid 0 obtained auth for org.freedesktop.packagekit.system-sources-configure
PackageKit[660]: repo-enable transaction /4559_cddbbeee from uid 0 finished with success after 34ms
PackageKit[660]: uid 0 is trying to obtain org.freedesktop.packagekit.upgrade-system auth (only_trusted:0)
PackageKit[660]: uid 0 obtained auth for org.freedesktop.packagekit.upgrade-system
packagekitd[660]: adaptation0 is not cached! Do a refresh
packagekitd[660]: aliendalvik is not cached! Do a refresh
packagekitd[660]: apps is not cached! Do a refresh
packagekitd[660]: customer-jolla is not cached! Do a refresh
packagekitd[660]: eas is not cached! Do a refresh
packagekitd[660]: hotfixes is not cached! Do a refresh
packagekitd[660]: jolla is not cached! Do a refresh
packagekitd[660]: xt9 is not cached! Do a refresh
mce[578]: modules/battery-statefs.c: tracker_open(): /run/state/namespaces/Battery/State: open: No such file or directory
packagekitd[660]: Installation space required 0 bytes, available 7301263360 bytes
mce[578]: modules/proximity.c: report_proximity(): state: CLOSED -> OPEN
PackageKit[660]: upgrade-system transaction /4560_dbbcaabd from uid 0 finished with success after 2786ms
sailfish-upgrade-ui[628]: Reverting the enabled state of store to true
PackageKit[660]: uid 0 is trying to obtain org.freedesktop.packagekit.system-sources-configure auth (only_trusted:0)
PackageKit[660]: uid 0 obtained auth for org.freedesktop.packagekit.system-sources-configure
PackageKit[660]: repo-enable transaction /4561_eaaedcad from uid 0 finished with success after 23ms


It still takes very short time and it just automatically reboots afterwards without doing anything. Any more suggestions on what to try?

more

No, you do not get any error at all, anymore: Problem solved! ;)

More seriously, as you are still struggling to update at the command line:

• There is no error message anymore, so BTRFS-balancing solved the original issue.
• The update process you triggered did nothing, because "<repo xyz=""> is not cached! Do a refresh</repo>".

So why don't you try to issue a pkcon refresh (as root) as instructed?
One should also follow Jolla's guide how to upgrade SFOS at the command line (especially the steps after a successful upgrade, see section "Final clean up"). Guides provided here at TJC tend to omit crucial steps (i.e., commands).

If all that fails (including the sections "If it keeps failing" and "Troubleshooting" in Jolla's guide) come back here, I have a few more tricks in store.

( 2018-12-14 21:28:46 +0200 )edit

I can run pkcon refresh from shell-ex and it will prompt for my security code. It seems to run successfully but doesn't really do anything. I also ran the cleanup bits from your link. Meaning, I removed the files.

Upgrading still fails and there's nothing new in the /var/log/systemupdate.log

It's a bit difficult to run things as root as I can't enable the developer mode.

( 2018-12-17 11:47:00 +0200 )edit

@TimoR, without the ability to become root user, it does not make much sense to continue to try upgrading, as most failures will likely be caused by not being root. So lets try to address this issue first.

• Why are you using ShellEx? As it is not a proper Shell, IMO it is only suitable to issue a single command every now and then, but not for any more intensive use or debugging.
Does ToeTerm not install / work for you?
• What do you mean with "it will prompt for my security code"? Do you mean "it asks for the root password" (which is the "ssh password" set in the SFOS settings app) by that? Can you please Cut&Paste the exact message displayed.
• How do you perform your manual upgrading exactly? All guides have a shell and being root user (per devel-su) as prerequisites, which you apparently cannot fulfill (currently). Can you please Cut&Paste which sequence of commands you use.

Side note: An inconvenient, but feasible way would be to become root at the recovery console, mount the system partitions and perform the SFOS upgrade manually there. While the commands to perform the upgrade are the same, the preparation is much more error prone.
So lets first try to analyse and solve your "not becoming root" issue when booted regularly.

( 2018-12-18 17:30:32 +0200 )edit