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 @blizzzhere ?
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:
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
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.
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.
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?
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.
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
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
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.
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.
