pacman ceased to function: libpsl gone?

royb · 2018-03-16 11:42:48

Hi All,

I ran "pacman -Suy", this is what I normally do to keep my system up to date.

When it returned a long (~20) list of packages that would be updated, including a new kernel, I answered "no" to abort and then attempted to selectively update just a few of the packages via:

[root@rubicon ~]# pacman -S chromium curl firefox firefox-i18n-de firefox-i18n-en-gb firefox-i18n-en-us wget

Is this a safe syntax to use?

The selective update ended apparently successfully. However at some point afterwards I noticed that various utilities including pacman would no longer run:

[root@rubicon ~]# pacman -Qi xbitmaps
pacman: error while loading shared libraries: libpsl.so.6: cannot open shared object file: No such file or directory

The pacman cache contains:

[root@rubicon ~]# ls -ltr /var/cache/pacman/pkg/ | grep -i libpsl
-rw-r--r-- 1 root root     51064 Nov 19 21:36 libpsl-0.18.0-2-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root     64700 Dec 18 23:25 libpsl-0.19.1-1-x86_64.pkg.tar.xz

The pacman log says neither libpsl nor pacman itself have been upgraded recently:

[root@rubicon pslwork]# egrep 'upgraded (libpsl|pacman) ' /var/log/pacman.log 
...
[2017-06-19 10:05] [ALPM] upgraded pacman (5.0.1-5 -> 5.0.2-1)
[2017-07-20 18:08] [ALPM] upgraded pacman (5.0.2-1 -> 5.0.2-2)
[2017-08-28 16:13] [ALPM] upgraded libpsl (0.17.0-2 -> 0.18.0-1)
[2017-11-19 21:38] [ALPM] upgraded libpsl (0.18.0-1 -> 0.18.0-2)
[2018-01-08 08:55] [ALPM] upgraded libpsl (0.18.0-2 -> 0.19.1-1)

The pacman.log file ends with:

...
[2018-03-13 18:11] [PACMAN] Running 'pacman -Suy'
[2018-03-13 18:11] [PACMAN] synchronizing package lists
[2018-03-13 18:11] [PACMAN] starting full system upgrade
[2018-03-14 10:21] [PACMAN] Running 'pacman -Suy'
[2018-03-14 10:21] [PACMAN] synchronizing package lists
[2018-03-14 10:21] [PACMAN] starting full system upgrade
[2018-03-14 10:23] [PACMAN] Running 'pacman -S chromium curl firefox firefox-i18n-de firefox-i18n-en-gb firefox-i18n-en-us wget'
[2018-03-14 10:23] [ALPM] transaction started
[2018-03-14 10:23] [ALPM] upgraded chromium (65.0.3325.146-1 -> 65.0.3325.162-1)
[2018-03-14 10:23] [ALPM] upgraded curl (7.58.0-1 -> 7.58.0-2)
[2018-03-14 10:23] [ALPM] upgraded firefox (58.0.2-1 -> 59.0-1)
[2018-03-14 10:23] [ALPM] upgraded firefox-i18n-de (58.0.2-1 -> 59.0-1)
[2018-03-14 10:23] [ALPM] upgraded firefox-i18n-en-gb (58.0.2-1 -> 59.0-1)
[2018-03-14 10:23] [ALPM] upgraded firefox-i18n-en-us (58.0.2-1 -> 59.0-1)
[2018-03-14 10:23] [ALPM] upgraded wget (1.19.4-1 -> 1.19.4-2)
[2018-03-14 10:23] [ALPM] transaction completed
[2018-03-14 10:23] [ALPM] running 'gtk-update-icon-cache.hook'...
[2018-03-14 10:23] [ALPM] running 'systemd-update.hook'...
[2018-03-14 10:23] [ALPM] running 'texinfo-install.hook'...
[2018-03-14 10:23] [ALPM] running 'update-desktop-database.hook'...

I was able to get pacman working by downloading the current libpsl package (libpsl-0.20.0-1-x86_64.pkg.tar.xz), unpacking it to a tmp directory and setting LD_LIBRARY_PATH to search there. This version of the package contains both 5.2 and 6.2 versions of libpsl:

[root@rubicon pslwork]# ls -ltr /var/tmp/pslwork/usr/lib/
total 124
lrwxrwxrwx 1 root root    15 Dec 18 23:24 libpsl.so.5 -> libpsl.so.5.2.0
-rwxr-xr-x 1 root root 54896 Dec 18 23:24 libpsl.so.5.2.0
lrwxrwxrwx 1 root root    15 Feb 25 23:54 libpsl.so.6 -> libpsl.so.6.2.0
lrwxrwxrwx 1 root root    15 Feb 25 23:54 libpsl.so -> libpsl.so.6.2.0
-rwxr-xr-x 1 root root 64352 Feb 25 23:54 libpsl.so.6.2.0
drwxr-xr-x 2 root root  4096 Mar 16 11:51 pkgconfig

pacman is now proposing to update some 45 packages (including libpsl-0.20.0-1 ;-)). Should I go ahead and let it run? Is there some other action/consistency check I can take?

Does anyone have an idea about the possible root cause? pacman (and others e.g. mupdf) were working happily, apparently using libpsl.so.6, when this library suddenly disappeared for no obvious (to me) reason. This occurred directly after a pacman update. Is it possible one of the newly updated packages somehow did this itself, via some "embedded" script/action?

(FYI (full disclosure) IIRC something similar happened on this system last year, probably around 9 months ago ... to long ago to remember the specifics. At that time I wrote it off to random bad luck, but twice is too much coincidence for me :-).)

Thanks in advance!

arojas · 2018-03-16 11:50:48

royb wrote:

Does anyone have an idea about the possible root cause?

Yes, you broke your system by doing a partial upgrade, which is completely unsupported.

progandy · 2018-03-16 11:52:24

The root cause is that you did a partial upgrade.

Edit: Too slow.

Edit: The library did not disappear, but you updated curl, which needs a new version of the library you did not install. In arch packages, the version of a dependency is often omitted and only the package name given, since you are expected to always update everything.

Last edited by progandy (2018-03-16 11:59:35)

noobnoobnoo · 2018-03-16 12:38:33

I'm running into the exact same problem.
I'm fairly new to Arch and the only pacman command I know and used was `pacman -Syu` or `pacman -S {package_name}` or `pacman -Fs {file_name}`. I don't think these commands should cause any problem. Any help appreciated.

V1del · 2018-03-16 12:43:22

If you pacman -Syu , say no, and then install selective packages with -S that is the same as having ran pacman -Sy $package , which as already stated is unsupported. Another possibility that might be less your fault is that you are running outdated mirrors. A pacman.log would clear all doubts.

That said, follow the instructions from the OP, they have managed to recover quite well.

Trilby · 2018-03-16 12:43:41

noobnoobnoo wrote:

I'm running into the exact same problem.

I highly doubt this is true. You have a problem that you may think looks superficially similar, but we can't possibly know as you've not provided any error messages or description of the problem. You should do so in your own thread.

In the off chance that you really do have the exact same problem, the exact same responses already provided above would be applicable.

noobnoobnoo · 2018-03-16 12:43:58

Well, for obvious fix, I downloaded libpsl from Arch repository, put it on LD_LIBRARY_PATH, and installed `pacman -S libpsl --asdeps`. Hmm... I don't know why this problem happened in first place.

eschwartz · 2018-03-16 12:44:37

Well, you absolutely had to have run pacman -Sy at some point or pacman would not upgrade curl without libpsl.

The solution is quite simple though -- reboot to the installation ISO and use pacstrap/pacman --root to do a full system upgrade.

noobnoobnoo · 2018-03-16 12:51:02

I'm so sorry for the hassle... I checked the log and found that you guys are right. pacman -Sy it was. Lesson learned.

Trilby · 2018-03-16 12:54:12

If you don't recall ever using that command, I'd suspect you are using a broken aur 'helper' that is known to do such things behind your back.

noobnoobnoo · 2018-03-16 13:04:51

I checked my .zsh_history to find that it was my dumb mistake. Plus a coincidence that somebody posted a similar issue, making me believe that this is not my mistake. Thanks for your help though.

royb · 2018-03-16 13:39:50

OK. My bad - I didn't realise that wasn't supported/allowed.

I would point out that the first two lines of output from the selective pacman update are "resolving dependencies" and "looking for conflicting packages" suggesting (to me) that pacman will take care of package relationships/deps.

Is there then a right way to do , for example, an update of chromium (Internet facing user tool with a large exposed attack surface), without updating linux or xfce-xyz (perhaps necessitating a reboot or restart of the desktop)? Or is that not possible?

Under partial upgrade link I read about the "checkupdates" script. But when I run it currently it returns with no output, although pacman is suggesting 45 package updates.

To be honest I'm still not sure I understand the root cause: As I understand it:

- pacman was functioning normally.
- The pacman package hasn't been updated since July 2017 (plausible?)
- I run an (incorrect) pacman command to update some "unrelated" packages: curl, wget, chromium, ...
- pacman ceases to function because it cannot load/link to libpsl.so.6

Oh, perhaps I see! Is it that my initial "pacman -Suy" command actually updates stuff? Is this what changed pacman/libpsl? I had been thinking of that as being an initial "check" of what could be updated ... and that answering "no" to "Proceed with installation?" meant that it would make no changes.

On the other hand, the pacman program is itself part of a package, so how could it be changed without there being a package update message/log entry?

In any case thanks again in any case for the quick and helpful responses!

I will now run "pacman -Suy" and answer "yes" ... In fact at this point I'm wondering what the purpose of being able to answer "no" is ...

Scimmia · 2018-03-16 14:02:06

You're thinking of the things you updated as "unrelated". They're not. For instance, pacman uses curl.

Trilby · 2018-03-16 14:08:40

royb wrote:

Is there then a right way to do , for example, an update of chromium (Internet facing user tool with a large exposed attack surface), without updating linux or xfce-xyz (perhaps necessitating a reboot or restart of the desktop)? Or is that not possible?

The kernel itself is one of very few packages which can safely be put in the IgnorePkg list of pacman.conf to ignore updates to it until you are ready (but you will not get any relevant security updates to the kernel until you do chose to update). Other than that, no, this is not really possible with archlinux (technically it is possible to do it as you have above, but it will most likely have horrible results).

eschwartz · 2018-03-16 14:12:31

You are allowed to say no, because the assumption is that you will figure out why you had to say no and then repeat the same thing with a yes instead.

Also, pacman supports features that Arch Linux does not use, but other projects (like MSYS2 on Windows) might.

suggesting (to me) that pacman will take care of package relationships/deps.

It will. If you have package *name* conflicts, as many Arch packages do, then this will abort.
Also, *some* packages at the discretion of the maintainer, may choose to add versioned depends. We tend to dislike those, but it is possible on a technical level...

Last edited by eschwartz (2018-03-16 14:14:58)

Trilby · 2018-03-16 15:37:55

And of course ... https://bbs.archlinux.org/viewtopic.php … 9#p1766789

royb · 2018-03-16 15:55:16

Trilby wrote:
> And of course ... https://bbs.archlinux.org/viewtopic.php … 9#p1766789

Meaning what, exactly?

TheChickenMan · 2018-03-17 15:47:26

V1del wrote:

If you pacman -Syu , say no, and then install selective packages with -S that is the same as having ran pacman -Sy $package , which as already stated is unsupported. Another possibility that might be less your fault is that you are running outdated mirrors. A pacman.log would clear all doubts.
That said, follow the instructions from the OP, they have managed to recover quite well.

I also ran into this issue (twice) this week on computers running Archlinux32.
My "normal" Arch computers did not seem affected. I'm guessing was the out of date mirror thing.

ace_ang · 2018-03-18 01:20:16

I also made the mistake of selecting the packages and ended up with the same error of missing libpsl.so.6. I ended up manually installing the package and pacman worked again and decided to just install everything but encountered the error "file exists in filesystem." I knew I was the reason and decided to use --force to install libpsl, or was that another mistake?

I continued the installation with success this time, rebooted, and everything seems to be well.

Trilby · 2018-03-18 01:43:12

ace_ang wrote:

... and decided to use --force to install libpsl, or was that another mistake?

If it was for the single package, not really. But what if it was, it's too late now. I'd say, on principle, using --force if you aren't sure that it is the right thing to do is in itself a mistake. If you aren't sure ask before you do so next time. Asking afterwards just gives the opportunity for everyone to say "sucks to be you" if it was a bad idea.

ace_ang · 2018-03-18 02:25:12

Yes, it was only for libpsl and it's good to know that it's not another mistake, but if it was, then I would have just searched for another solution, just like how I found I can manually install it, which did solve it but brought another problem, of which I searched for another solution, which I was sure this is a situation where --force is of proper use, just maybe I'm being wrong, which I'm thankful I understood it right.

As for the "sucks to be you," well, that depends really on the question and the action taken. Would you say I suck because I did use --force? I don't think so. But you probably did on me doing the partial upgrade, which is fine, but I don't focus on the problem, I focus on the solution.

Trilby · 2018-03-18 03:07:21

I'm not saying you 'suck' in any way. Only that next time you use '--force' without being sure if it's the right thing to do you might not be as lucky as you were this time. In such a case when you come here for help, there'd be very little we could do for you.

ace_ang · 2018-03-18 03:44:20

My doubts come from me being new even though I was understanding it right at that time when I read the wiki on --force that it's the solution since it will do the same as I did, only the right way, not manually but through pacman.

Not luck since I know I was the cause of the problem, but I do agree on what you're saying.

eschwartz · 2018-03-18 12:52:27

The next version of pacman deprecates --force and delists it from the manpages and help output, and eventually this option will be removed entirely. Keeping this in mind, you may be able to understand why I say that it is *never* the solution to anything.

The way forward for the future is to use --overwrite and specify a glob pattern of the files you know it is okay to replace. This is the equivalent of doing surgery with a broadsword, then upgrading to a surgical scalpel and high-tech nanobots.

ngoonee · 2018-03-18 20:19:43

Eschwartz wrote:

This is the equivalent of doing surgery with a broadsword, then upgrading to a surgical scalpel and high-tech nanobots.

Cue dozens of people claiming the broadsword was easier to handle and involves less typing.

Arch Linux

#1 2018-03-16 11:42:48

pacman ceased to function: libpsl gone?

#2 2018-03-16 11:50:48

Re: pacman ceased to function: libpsl gone?

#3 2018-03-16 11:52:24

Re: pacman ceased to function: libpsl gone?

#4 2018-03-16 12:38:33

Re: pacman ceased to function: libpsl gone?

#5 2018-03-16 12:43:22

Re: pacman ceased to function: libpsl gone?

#6 2018-03-16 12:43:41

Re: pacman ceased to function: libpsl gone?

#7 2018-03-16 12:43:58

Re: pacman ceased to function: libpsl gone?

#8 2018-03-16 12:44:37

Re: pacman ceased to function: libpsl gone?

#9 2018-03-16 12:51:02

Re: pacman ceased to function: libpsl gone?

#10 2018-03-16 12:54:12

Re: pacman ceased to function: libpsl gone?

#11 2018-03-16 13:04:51

Re: pacman ceased to function: libpsl gone?

#12 2018-03-16 13:39:50

Re: pacman ceased to function: libpsl gone?

#13 2018-03-16 14:02:06

Re: pacman ceased to function: libpsl gone?

#14 2018-03-16 14:08:40

Re: pacman ceased to function: libpsl gone?

#15 2018-03-16 14:12:31

Re: pacman ceased to function: libpsl gone?

#16 2018-03-16 15:37:55

Re: pacman ceased to function: libpsl gone?

#17 2018-03-16 15:55:16

Re: pacman ceased to function: libpsl gone?

#18 2018-03-17 15:47:26

Re: pacman ceased to function: libpsl gone?

#19 2018-03-18 01:20:16

Re: pacman ceased to function: libpsl gone?

#20 2018-03-18 01:43:12

Re: pacman ceased to function: libpsl gone?

#21 2018-03-18 02:25:12

Re: pacman ceased to function: libpsl gone?

#22 2018-03-18 03:07:21

Re: pacman ceased to function: libpsl gone?

#23 2018-03-18 03:44:20

Re: pacman ceased to function: libpsl gone?

#24 2018-03-18 12:52:27

Re: pacman ceased to function: libpsl gone?

#25 2018-03-18 20:19:43

Re: pacman ceased to function: libpsl gone?

Board footer