Upgrade to problematic

I’m trying to upgrade my Sony XA 2 Plus to Kvarken [] and first it said
“Uninstall the following before proceeding with the Sailfish OS update

Now when I installed obexd-contentfilter-off I remember it wouldn’t complete installation and kept hanging in the install. After a restart obexd-contentfilter-off didn’t work.

So I went to try to uninstall obexd-contentfilter-off but it complained about something like missing rpm or so.

Anyway, after this the update screen said:
“Uninstall the following before proceeding with the Sailfish OS update…”
and a list of 800 (!) programs follows, including PackageKit, SDL2, alsa-lib, basesystem, busybox, ca-certificates, dbus and on and on it goes. My gut tells me not to do this as I guess it could make updating impossible after that.

So I looked what could be the problem with obexd-contentfilter-off and found out ( obexd-contentfilter-off/README.md at master · Olf0/obexd-contentfilter-off · GitHub that it replaces the obexd-contentfilter-helper with obexd-contentfilter-off. Now when I uninstalled obexd-contentfilter ( rpm --e --nodeps obexd-contentfilter-off && rpm -i obexd-contentfilter-helper ) it complained at the second command that the rpm was not found. So now I have neither obexd-contentfilter-off, nor the -helper.

I chose for the rpm procedure as it was not clear to me how to do it with pkconn, zypper/libzyp. My guess is that the missing obexd-contentfilter-* prompts the updater to asking to remove (almost?) all system binaries.

Could anyone kindly help me? I guess maybe it could be restored through using pkconn and/or zypper/libzyp but have no idea how exactly to input the commands.
Thanks in advance.

In order to use rpm -i you need the RPM file downloaded and must give the path to it. That’s why it is complaining.

Note that using rpm is explicitly recommended against by the developer:

  • To restore the original behaviour and state of the OS, simply uninstall this package (but not per the rpm command line utility!).
    Then also remove or disable this repository in order to prevent automatic reinstallation of obexd-contentfilter-off when upgrading the OS.

I recommend following the advice and

  1. verify that you are not affected by [Bug] /usr/libexec/sailfish-osupdateservice osupdate-check sets ssu re if you are fix this first
  2. ssu dr obexd_contentfilter_olf # disable the repo
  3. pkcon refresh # update zypper package cache
  4. pkcon install obexd-contentfilter-helper # install original package
  5. pkcon update # just for good measure
  6. now do the upgrade

Before the upgrade, make sure you don’t have “dangerous” repos enabled, “dangerous” being those that contain packages that replace system packages from Jolla. If you do, disable them as well and refresh the cache.

1 Like

Thank you so much.

  1. During the version check, the 2nd command in the bug report under ‘Resolution’ ( ssu re | rev | cut -f 1 -d ’ ’ | rev ) gives a warning (“WARNING: ssu.ini does not seem to be writable. Setting values might not work.
    And that’s the same version the 1st commands generates, so apparently not affected by the bug.
  2. I have disabled all openrepos- repositories.
    There is one that is not obviously from jolla, and that’s mentaljam-obs. Should I disable that too?
  3. Finished without problems.
  4. Also no problem.
  5. No packages required updates.
  6. I’ll wait for your response to my mentaljam-obs question before starting the upgrade if you don’t mind
    And after a restart, it still complains that I have to uninstall those 800 packages… Why could that be? And what should I do?

That ssu warning is normal/harmless. Just ignore it.

mentaljam-obs AFAIK is the repo used by MLS-manager for the Storeman app. Should be harmless, but you can disable it and remove storeman during the upgrade, and use storeman installer after to recreate it.

Good luck with the upgrade, do keep backups! :slight_smile:

I do not know how to get that “uninstall everything” list updated, but maybe one of the Release Note threads has some info about this.

I thought this statement was explicit enough.

In general: One shall always use pkcon for managing packages on SailfishOS!
If its slightly slim feature set is not sufficient, one may resort to zypper (which has to be installed per pkcon, first).
Only use the very low-level package management tool (rpm on SailfishOS) for queries (i.e., rpm -q …) or if you absolutely have to, which is solely the case at the recovery console (which also shall only be used, when you absolutely have to).

BTW, this also applies to other Linux distributions, e.g. Suse (use zypper, not rpm), RedHat / Fedora (use dnf / yum, not rpm), Debian (use apt / aptitude, not dpkg), Ubuntu (use pkcon / apt, not dpkg) etc.


I still wonder about this assessment, because in my experience one can simply ignore the warning and the SailfishOS update works fine.

Before I erased (rpm -e) obexd-contentfilter-off the updater only said: Uninstall obexd-contentfilter-off, which I did with the rpm command because I had no clue how to do it with pkcon/zypper. Maybe I should have read some more into that, but I also thought I would be able to install the contentfilter helper always back later, but wasn’t able to find the rpm.

After the erase and the failed re-install of the contentfilter helper, that’s when the updater asked to uninstall about everything. So apparently it had updated itself.

It’s strange therefore that it didn’t do it again after ‘repairing’ the contentfilter helper.

But anyway, I’ll do a comprehensive backup (including notes) and try to upgrade anyway. In case that fails I still can re-install the whole Sailfish X again.

Thanks for your kind help.

Thanks, that’s what I’m going to try, after a full backup to SD card.


@olf would you mind to explain why it’s recommended to avoid low level tools such as rpm, dpkg etc? Does pkcon or zypper maintain any other package management than rpm?

Yes, they all use a much more advanced dependency resolver (often simply called “resolver”, e.g. libsolv), which avoids many classical mishaps.

But that is well documented, because it is a principal reason why the higher level tools exist.
Hence, if you want to know the details, search the net.


Quite so. rpm is a tool which handles cog wheels. zypper handles engine, transmission and drive train. They are simply not the same class of tool.

rpm basically manages one package. You can install it, uninstall it, query it etc. But it doesn’t manage dependencies or care at all the state of the package system apart from the package it currently deals with.

zypper has a view of the whole dependency graph, including metadata of packages from different repositories and can ensure the packaging system is consistent, and make decisions that keep it so.

pkcon is an abstraction over many packaging systems, and uses zypper/libzypp in the background, so the same applies.