Might be that the package name of Phonehook is something different than just phonehook. Find the proper package name of the phonehook with rpm -qa | grep phonehook and use that name for the erase-command.
Try installing zypper and linking the /home/.pk-zypp-dist-upgrade-cache to /var/cache/zypp and do su zypper dup to see if that fixes the problem.
I couldnt find anything similar to it.
How is it supposed to install a package in recovery mode ?
Could be also Phonehook or some other variant, it is case sensitive. To install packages in recovery mode you need to have the .rpms on SDCard or SSH them to the phone and then install them with rpm -command
Do you have a link for me? Which version do I need? And why zypper could fix the problem?
Does anybody know what
are ?
1 )
Failed to start Tracker metadata database store and lookup manager.
tracker-store.service: Failed with result 'exit-code'.
tracker-miner-fs.service: Failed with result 'exit-code.
2)
messageserver5.service: Failed with result 'exit-code'.
I did try, but:
[root@(none) /]# zypper dup
Medium not attached: plugin:/ssu?repo=adaptation0
…
Did I miss something?
Tracker ist the indexing tool which among other things presents pictures to gallery, music files to the media app and so on. It shouldn’t fail, but I guess it failing is non-critical.
messageserver5 is the service dealing with SMS and other messages. That’s pretty much a core function.
It does sound like the update didn’t finish and the system is “half-updated” at the moment.
Unless you have a very good reason you want to recover from this state, I’d just reset to factory settings from recovery mode and start anew. Poking around and fixing things is probably going to take more time than starting anew.
But before that, do you have the following files?
/var/log/systemboot.log
/var/log/systemupdate.log
/var/log/zypp/history
Can you put them, and the journal output, on pastebin or some such site so we can look at them in full?
Running the script, ended with the following error:
sqlite3: error while loading shared libraries: libicui18n.so.63: cannot open shared object file: No such file or directory
This error is quite common in the journalctrl. Someone linked .66 to .63 to circumvent the problem. I cannot judge which implications follow linking it like this?
/usr/bin/contacts-tool list
doesnt produce any output unfortunatley
The good reason is saving my stuff. If I would be able to save my
…
How about this error? It seems to be a problem one… Has anybody solved it… except for @blizzz here ?
Now is only 3 times
Here the pastebin logs
I would appreciate, if somebody gives an answert to the post above as well.
For me in the update limbo-state the pkcon update just complained Failed to contact PackageKit: Could not connect: Connection refused and because there was no Internet-connection, version --dup would wait for eternity in REFRESHING CACHE AND DOWNLOADING PACKAGES.
But zypper worked and could finish the incomplete dist-update, so maybe it can help you also. Install at least zypper from these links and if it complains about missing depencies, download install them as well:
https://releases.jolla.com/releases/3.4.0.24/jolla/armv7hl//core/armv7hl/zypper-1.14.6+git4-1.5.1.jolla.armv7hl.rpm
https://releases.jolla.com/releases/3.4.0.24/jolla/armv7hl//core/armv7hl/augeas-libs-1.12.0+git2-1.5.1.jolla.armv7hl.rpm
https://releases.jolla.com/releases/3.4.0.24/jolla/armv7hl//core/armv7hl/readline-8.0+git1-1.4.1.jolla.armv7hl.rpm
Copy them to you phone, if you phone has encrypted /home-partition command following (other if no enctyption, skip to next step):
cryptsetup luksOpen /dev/sailfish/home whatever
mount /dev/mapper/whatever /rootfs/home
Then use chroot /rootfs and install zypper with rpm -Uvh /path/to/the/zypper-rpms/*.rpm -command.
Now command following commands:
mv /var/cache/zypp /var/cache/zypp-old
ln -s /home/.pk-zypp-dist-upgrade-cache /var/cache/zypp
su
zypper dup
rm /var/cache/zypp
mv /var/cache/zypp-old /var/cache/zypp
and then reboot your phone to see if it worked.
my problem seems to be different than yours
Symptons might be different, but is the root cause the same (failed update)? If it is, with zypper you might be able to fix that.
As far as to the logs are concerned, the update has been (semi-)successful. (actually I would like to change the topic of the thread, to doesnt display anything or to doesnt boot to the end
Im seeing this in the logs as well
Failed to start The lipstick UI.
PS Besides the zypper (d)up command fails like:
[root@(none) /]# zypper up
Medium not attached: plugin:/ssu?repo=adaptation0
and so on, with all “packages” from /var/cache/zypp
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 
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.
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.
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.