Tried to update doesnt boot aynmore

Bug Reports
#23

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.

2 Likes
#24

my problem seems to be different than yours

#25

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.

#26

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

[3.4.0.24] libicui18n.so.63: cannot open shared object file
#27

@nephros

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)

#28

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 :slight_smile:

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
[3.4.0.24] libicui18n.so.63: cannot open shared object file
#29

Did you use chroot, link the /home/.pk-zypp-dist-upgrade-cache with /var/cache/zypp and used su before trying the zypper up?

#30

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?

#31

Good that you managed :slight_smile:

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.

#32

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

#33

Could anyone give a hint about it as well?

#34

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?

#35

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
#36

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

#37

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.

#38

Were any such files/directories supposed to be found in the backup? I didnt have any.

#39

Probably not, but I wanted to make sure. They could have been.

#40

Do you share my suspicion that the root cause has been this library?

#41

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.

#42

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 ?