Im also attaching the original installed packages (listed with rpm -qa)
And also how much free space Im expected to have available on the root partition? Right now its 27% (around 650MB)
From the other topic, you could symlink the so.63, that might work.
If that doesn’t work, you can install the libicu-63.1 next to the libicu-66.1, though it might sound dangerous 
rpm -e libicu --justdb --nodeps
This will remove the package libicu-66.1 from the package-database but will still preserve the files. So all the software that depends on this will still work.
rpm -Uvh https://releases.jolla.com/releases/3.0.3.10/jolla/armv7hl//core/armv7hl/libicu-63.1+git5-1.1.6.jolla.armv7hl.rpm
This will install the older packae, which makes software that still depends on it run again.
After reboot it should get further in the boot process, but because it is partly new system and partly old, it might still not work great. But hopefully enough to get you going again.
1 Like
Did you use chroot, link the /home/.pk-zypp-dist-upgrade-cache with /var/cache/zypp and used su before trying the zypper up?
Removing the lib dependency error, brought back the system to functionality !!!
For me strange, that nobody paid attention to the errors Ive listed above.
Im starting to pay greater attention from now on, of how the backup is being made…
1st try: backup over the gui hasnt succeed… not enough free space (although 3.7GB free, and last update was around 1.5GB … and I didn’t increase significantly my data since than). Im reading tha new backup has problems? Not using gz besides anymore?
Good that you managed
Can you manage to continue the update process again?
Myself I haven’t run into the “not enough space” problem, though on my XA2 there is slightly more space than on the X. For backups I use an SD card, where I also store my music.
What do you mean? Shall I factory reset it?
Many apps dont function. e.g. Browser -> blackscreen.
I just couldnt update anything. Neither apps from store. nor the system via
version --dup
Refreshing: 0%
Error: Medium not attached: plugin:/ssu?repo=adaptation0
nor zypper up
see above error
Could anyone give a hint about it as well?
Unfortunately, the sad journey continues.
After the factory reset, the backup restore breaks in the middle of the gallery extracting … On advice from support I tried to tar --delete some of the backup, in order to achieve a final recovery. What happened was a corrupted backup tar archive… Unfortunately, the only copy I had…
tar: Skipping to next header
tar: Archive contains ‘\347f\003\260\200l\024\306\r&:n’ where numeric off_t value expected
Any help on this new trouble?
Take the original unmangled tar file, unpack it on a Linuxish computer, and tar up the result into a proper tar again. Something like:
$ sudo su # <-- this is important, otherwise permissions and ownership may get messed up. May use plain su if your system does not use sudo.
# mkdir ~/retar
# pushd ~/retar
# tar --numeric-owner -xpf /some/location/corrupt.tar
# #### fix whatever needs fixing in the files
# tar --numeric-owner -cpf /some/location/new.tar ./* ./.??*
Then copy the new tar file to the device, and TEST that is can be unpacked using the OS version of tar (which can be busybox or GNU tar depending on configuration) using something like tar tvf <<new_tar_file.tar>>.
If it shows no errors, give that new tar file to the restore function of the Backup app.
While I really can’t tell for sure, the underlying problem is maybe that the filenames stored in the backup use some unusual encoding in their file names which causes the restore to fail.
So if at all feasible, before re-creating the “new” tar file, check that there aren’t any files with weird characters in their name, and if possible, rename to something more common.
Or, leave them out of the new tar file completely and restore them later manually.
1 Like
I did tried to unpacked on a Linuxish PC and the result was the above. There are files which contain unicode chracters. These have never been a problem so far. Why would that be a problem all of a sudden? I created the backup with the previous version (the one with the black screen), which contained the problem described from above
Following your approach (skipping the problem from below), I was able to recover the backup. It seems that the the unicode library affected the backup mechanism as well…
What did you mean with the above ? I dont have any files in the retar top tree. Im getting
tar: ./.??*: Cannot stat: No such file or directory
This is to catch any files/directories which start with a dot (hidden). A plain * would not pick up those files directories. ./.??* expands to “all files/dirs which start with a dot, and are longer than two characters”. The “longer” part is to exclude the .. directory, which would recurse up one directory which we don’t want.
Were any such files/directories supposed to be found in the backup? I didnt have any.
Probably not, but I wanted to make sure. They could have been.
Do you share my suspicion that the root cause has been this library?
I can’t say. Neither BB tar nor GNU tar use that library directly AFAIK.
It’s usually Qt programs that do. I do not know how the Backup/Restore mechanism do things, but if they go through Qt routines to collect files and create/restore the tar, then that’s possible.
I investigated a little more. Its not the libicui18n.so.63 lib. In the backup tar there is a mp4 file of a big size around 1GB. It brings not only the backup to freeze, but the whole sfos is blocked by it, I have to hard restart it.
The last command in the log is vault-gallery --action import --name Gallery --bin-dir ...
Could you confirm / reject if you have a similar problem ?
Well…
nemo@PGXperia10:~ $ ldd /usr/libexec/jolla-vault/units/vault-gallery | grep cui
libicui18n.so.66 => /usr/lib/libicui18n.so.66 (0xf2420000)
So that is linked against the libicui library. If the wrong one is loaded (e.g. by having that symlinked to the old version) that could in theory crash that binary.
Can’t say if that is what’s happening, or something else is going on.
You can try to call that binary manually, see if it also causes the OS to hang. this post has the full syntax as an example, if it still uses that same syntax, the post is from 2017…
Thank you for this!!! 
It was the last step I needed to recover my Xperia X after a failed update to 3.4.0.24.
After showing the update failed message, the screen would flash white 3-4 times and then stay black on each reboot.
I think the cause of the problem was related to not enough free disk space on the root volume, combined with file system deleted inode references.
What worked for me was to run a file system check in recovery mode and then resize the logical volumes, increasing the root volume from 2.44 GiB (625 extents) to 4.00 GiB (1024 extents) and decreasing the sailfish/home volume from 18.25 GiB (4673 extents) to <16.70 GiB (4274 extents).
The final problem was that there was no Internet connectivity in the shell to repair the update, so I had share the PC connection through USB. On Windows this worked by enabling the Internet Connection Sharing option in the Properties of the Wi-Fi adapter. This changes the static IP adress of the Remote NDIS Network Adapter created for the recovery mode connection to something like 192.168.137.1. In order to make the recovery connection work again, you need to also add the initial IP 10.42.66.67 in the Advanced TCP/IP Settings from the TCP/IPv4 Properties.
After connecting back to the phone, the following commands should be run in the terminal (telnet shell or ssh):
/sbin/ip route add default via 10.42.66.67 - this enables routing and you then have Internet without DNS
echo nameserver 1.1.1.1 > /etc/resolv.conf - this configures the DNS server and fully restores Internet connectivity
This allowed the final steps described by you to manually install the zypper packages and then run zypper dup. After a reboot the phone finally booted and I was able to run a version --dup from the Terminal which completed the update.
This is the end of the /var/log/systemupdate.log file in case anyone finds it useful:
Dec 24 16:54:07 Sailfish sailfish-upgrade-ui[813]: Package: sailfish-devicelock-fpd;1.1.0.1-1.7.3.jolla;armv7hl;jolla, sailfish-devicelock-fpd
Dec 24 16:54:07 Sailfish [RPM][5364]: Transaction ID 5fe4ab8f started
Dec 24 16:54:07 Sailfish [RPM][5364]: erase sailfish-devicelock-fpd-1.0.8-1.5.6.jolla.armv7hl: success
Dec 24 16:54:07 Sailfish kernel: EXT4-fs error (device dm-0): ext4_find_dest_de:1798: inode #17222: block 9778: comm touch: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=33188, rec_len=85, name_len=0
Dec 24 16:54:07 Sailfish kernel: EXT4-fs error (device dm-0): ext4_find_dest_de:1798: inode #17222: block 9778: comm rpm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=33188, rec_len=85, name_len=0
Dec 24 16:54:07 Sailfish [RPM][5364]: install sailfish-devicelock-fpd-1.1.0.1-1.7.3.jolla.armv7hl: failure
Dec 24 16:54:07 Sailfish [RPM][5364]: 1 elements failed, 0 scripts failed
Dec 24 16:54:07 Sailfish [RPM][5364]: Transaction ID 5fe4ab8f finished: -1
Dec 24 16:54:07 Sailfish packagekitd[873]: Install progress update: 634 of 854
Dec 24 16:54:07 Sailfish sailfish-upgrade-ui[813]: Distribution upgrade error: Subprocess failed. Error: RPM failed: touch: /usr/share/lipstick/devicelock/.owner.swap: Input/output error
error: unpacking of archive failed on file /usr/share/lipstick/devicelock/devicelock.conf;5fe4ab8f: cpio: open failed - File exists
error: sailfish-devicelock-fpd-1.1.0.1-1.7.3.jolla.armv7hl: install failed
error: sailfish-devicelock-fpd-1.0.8-1.5.6.jolla.armv7hl: erase skipped
Dec 24 16:54:07 Sailfish packagekitd[873]: Updating regular zypp cache
Dec 24 16:54:08 Sailfish PackageKit[873]: upgrade-system transaction /2941_cbbddbce from uid 0 finished with failed after 308076ms
Dec 24 16:54:08 Sailfish sailfish-upgrade-ui[813]: Upgrade completed with code 2
Dec 24 16:54:08 Sailfish sailfish-upgrade-ui[813]: Reverting the enabled state of store to true
Dec 24 16:54:08 Sailfish PackageKit[873]: uid 0 is trying to obtain org.freedesktop.packagekit.system-sources-configure auth (only_trusted:0)
Dec 24 16:54:08 Sailfish PackageKit[873]: uid 0 obtained auth for org.freedesktop.packagekit.system-sources-configure
Dec 24 16:54:08 Sailfish packagekitd[873]: Creating symlink: /var/cache/pk-zypp-cache -> /home/.zypp-cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository adaptation0 from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository adaptation1 from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository aliendalvik from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository apps from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository customer-jolla from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository hotfixes from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository jolla from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository sailfish-eas from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository store from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Reloading repository xt9 from disk cache
Dec 24 16:54:08 Sailfish packagekitd[873]: Switching target with hot pool: /home/.pk-zypp-dist-upgrade-cache -> /home/.zypp-cache
Dec 24 16:54:08 Sailfish PackageKit[873]: repo-enable transaction /2942_eabbecbc from uid 0 finished with success after 287ms
Dec 24 16:54:08 Sailfish sailfish-upgrade-ui[813]: Reverting the SSU version to 3.3.0.16
Dec 24 16:54:08 Sailfish dbus-daemon[711]: [system] Activating via systemd: service name='org.nemo.ssu' unit='dbus-org.nemo.ssu.service' requested by ':1.11' (uid=0 pid=813 comm="/usr/libexec/sailfish-upgrade-ui")
Dec 24 16:54:08 Sailfish dbus-daemon[711]: dbus-daemon[711]: [system] Activating via systemd: service name='org.nemo.ssu' unit='dbus-org.nemo.ssu.service' requested by ':1.11' (uid=0 pid=813 comm="/usr/libexec/sailfish-upgrade-ui")
Dec 24 16:54:08 Sailfish systemd[1]: dev-cpuctl.mount: Cannot add dependency job, ignoring: Unit dev-cpuctl.mount failed to load: No such file or directory.
Dec 24 16:54:08 Sailfish systemd[1]: Starting SSU service...
Dec 24 16:54:08 Sailfish dbus-daemon[711]: [system] Successfully activated service 'org.nemo.ssu'
Dec 24 16:54:08 Sailfish systemd[1]: Started SSU service.
Dec 24 16:54:08 Sailfish dbus-daemon[711]: dbus-daemon[711]: [system] Successfully activated service 'org.nemo.ssu'
Dec 24 16:54:14 Sailfish PackageKit[873]: daemon quit
Dec 24 16:54:14 Sailfish packagekitd[873]: Source ID 13 was not found when attempting to remove it
Dec 24 16:55:52 Sailfish mce[5006]: modules/battery-udev.c: mcebat_update(): battery_level : 95 -> 94
Dec 24 17:00:57 Sailfish mce[5006]: modules/battery-udev.c: mcebat_update(): battery_level : 94 -> 93
Dec 24 17:03:52 Sailfish systemd[1]: Starting Cleanup of Temporary Directories...
Dec 24 17:03:52 Sailfish systemd[1]: Started Cleanup of Temporary Directories.
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: fb0 reports (possibly inaccurate):
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: vi.bits_per_pixel = 32
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: vi.red.offset = 0 .length = 8
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: vi.green.offset = 8 .length = 8
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: vi.blue.offset = 16 .length = 8
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: framebuffer: 16 (1080 x 1920)
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: sailfish-upgrade-ui-la-system_update_failed: en_GB (715 x 267 @ 1847)
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: sailfish-upgrade-ui-la-system_update_failed_disk_full: en_GB (834 x 356 @ 2748)
Dec 24 17:07:36 Sailfish sailfish-upgrade-ui[813]: sailfish-upgrade-ui-bt-reboot: en_GB (257 x 110 @ 666)
Dec 24 17:07:36 Sailfish mce[5006]: modules/display.c: mdy_stm_set_compositor_availability_changed(): compositor availability change: pending
Dec 24 17:07:36 Sailfish mce[5006]: modules/display.c: mdy_stm_step(): forced brightness sync to: 2
Dec 24 17:07:36 Sailfish mce[5006]: modules/display.c: mdy_stm_set_compositor_availability_changed(): compositor availability change: handled
Dec 24 17:07:36 Sailfish mce[5006]: modules/display.c: mdy_display_state_enter(): current display state = ON
Dec 24 17:07:36 Sailfish systemd[1]: sailfish-upgrade-ui.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 17:07:36 Sailfish mce[5006]: modules/display.c: mdy_flagfiles_osupdate_running_cb(): osupdate_running flag file present: false
Dec 24 17:07:36 Sailfish systemd[1]: sailfish-upgrade-ui.service: Unit entered failed state.
Dec 24 17:07:36 Sailfish systemd[1]: sailfish-upgrade-ui.service: Triggering OnFailure= dependencies.
Dec 24 17:07:36 Sailfish systemd[1]: sailfish-upgrade-ui.service: Failed with result 'exit-code'.```
Links which I found helpful on this journey:
* https://jolla.zendesk.com/hc/en-us/articles/360002996893-Xperia-X-devices-How-to-use-the-Recovery-Mode
* https://jolla.zendesk.com/hc/en-us/articles/360005795474
* https://forum.sailfishos.org/t/xperia-10-sfos-3-4-update-failed-and-now-the-screen-flashes-white-twice-on-boot-and-then-stays-blank/2916
* https://together.jolla.com/question/224620/xperia-x-rokua-update-failed-stuck-in-airplane-mode-after-reboot-selfanswered/?answer=224659#post-id-224659
* https://forum.sailfishos.org/t/xa2-bricked-with-unsuccessful-update-to-3-4-0-22/2345/38
* https://forum.sailfishos.org/t/tried-to-update-doesnt-boot-aynmore/3008/23
* https://jolla.zendesk.com/hc/en-us/articles/201836347#2.3
2 Likes
does anyone know something about these strange urls from zypper error Medium not attached: plugin:/ssu?...?
i manage to get rid of some of those errors with running cp /usr/lib/zypp/plugins/urlresolver/ssu /usr/libexec/zypp/plugins/urlresolver/ found here: XA2 bricked with unsuccessful update to 3.4.0.22