You are not logged in.
pacman depends on libcrypto.so.1.1 DO NOT upgrade pacman!!
At least for now.
If you do, pacman can't start because this version of the shared library is not installed.
Kind regards,
Rory McGuire
Repository : core
Name : pacman
Version : 5.0.1-5
Description : A library-based package manager with dependency support
Architecture : x86_64
URL : http://www.archlinux.org/pacman/
Licenses : GPL
Groups : base base-devel
Provides : pacman-contrib
Depends On : bash glibc libarchive curl gpgme pacman-mirrorlist
archlinux-keyring
Optional Deps : None
Conflicts With : pacman-contrib
Replaces : pacman-contrib
Download Size : 731.45 KiB
Installed Size : 4530.00 KiB
Packager : Pierre Schmitz <pierre@archlinux.de>
Build Date : Sat 11 Feb 2017 01:49:05 PM SAST
Validated By : MD5 Sum SHA-256 Sum Signature
Mod note: Removed alarmist title. --WorMzy
Last edited by WorMzy (2017-04-24 15:00:31)
Offline
If you updated your entire system like you're supposed to, that version of the library would be installed.
Online
You should get an update for openssl during the same upgrade transaction (currently updating to 1.1.0.e-1). If you didn't, then your mirror is broken.
You can fix your system by updating it from a liveCD.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
There was a problem with today's update in terms of synchronisation, though it did not affect pacman in my case. However, after updating the system, I had a boot failure due to lack of older libraries required for various things. Updating again and rebooting resolved the issue, but clearly I was lucky that pacman was not affected. (Especially since I don't have the liveCD or, for that matter, a CD drive. Presumably I could make a USB instead, though.)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
AFAIK, most of the issues were with a very small lag between repos. Pacman should not be affected except in EXTREMELY rare cases, bad mirrors, or partial updates.
Online
Im ran into the same issue today and e.g. nodejs stopt working. Downgrade openssl from pacman cache worked as an hotfix for me.
How can i prevent this happening again?
I used Pamac, but was there any hint in the output of pacman?
Offline
Im ran into the same issue today and e.g. nodejs stopt working. Downgrade openssl from pacman cache worked as an hotfix for me.
How can i prevent this happening again?
I used Pamac, but was there any hint in the output of pacman?
Completely different issue, and your "hotfix" probably broke a lot of other things.
Online
Norkos wrote:Im ran into the same issue today and e.g. nodejs stopt working. Downgrade openssl from pacman cache worked as an hotfix for me.
How can i prevent this happening again?
I used Pamac, but was there any hint in the output of pacman?Completely different issue, and your "hotfix" probably broke a lot of other things.
It was a valid solution to the issue, if you were able to do so and did a full system upgrade after this.
By the way I always do full system upgrade and still was hit by this issue, multiple packages broke, not just pacman.
Offline
@Scimmia
This was my error: "node: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory"
So yes other issue, but same reason, or?
Hotfix:
Yes, I know, but panic
When the mirror was synced I installed the openssl.1.1 again (from cache) and done than a upgrade (-Syu).
And now everything is fine again (at least it seems so)
Offline
Norkos, that's a related problem - but actually the oposite. The OP here has a pacman upgrade without the corresponding openssl upgrade on his mirror. You received the openssl update but not a new nodejs.
It's all from the small lag Scimmia referred to (more specifically to some mirrors coincidentally last syncing *during* that lag period). The solution remains the same update your system with a recently synced mirror.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I had the same issue as OP: "error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory"
To fix pacman I did the following:
I downloaded openssl from packages and did the following.
cd /tmp
tar xJf ~/Downloads/openssl-1.1.0.e-1-x86_64.pkg.tar.xz
cd /usr/lib
sudo ln -s /tmp/usr/lib/libcrypto.so.1.1 libcrypto.so.1.1
sudo pacman -U /var/cache/pacman/pkg/pacman-5.0.1-4-x86_64.pkg.tar.xz
sudo rm libcrypto.so.1.1
This made my pacman functional again. Lesson learned. Don't update pacman without deps.
Offline
What? you deleted the lib at the last step? That would not work.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It worked because I didn't actually install the library. I created a soft link temporarily in the lib path. Once I fixed pacman and resolved my original error and proceeded with my update pacman cleverly reminded me that I still had the temporary link in place.
I should also clarify that libcrypto.so.1.0 was still in /usr/lib and that is why forcing pacman back to the previous version worked.
Last edited by grism (2017-04-24 21:33:34)
Offline
Oops, quite right. I misread that a bit. That still seems like an odd approach to me, but on second look it seems perfectly fine. I was thinking you put the symlink in place in order to upgrade the openssl package (not to downgrade pacman), then deleted the lib.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Now after the same issue and after recreating links manually to libcrypto and libssl I have a problem:
апр 25 10:36:51 zenbook systemd[1]: Stopped Simple Desktop Display Manager.
апр 25 10:36:51 zenbook systemd[1]: Started Simple Desktop Display Manager.
апр 25 10:36:51 zenbook sddm[1262]: /usr/bin/sddm: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.2d' not found (required by /usr/lib/libQt5Network.so.5)
апр 25 10:36:51 zenbook sddm[1262]: /usr/bin/sddm: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.2d' not found (required by /usr/lib/libQt5Network.so.5)
апр 25 10:36:51 zenbook systemd[1]: sddm.service: Main process exited, code=exited, status=1/FAILURE
апр 25 10:36:51 zenbook systemd[1]: sddm.service: Unit entered failed state.
апр 25 10:36:51 zenbook systemd[1]: sddm.service: Failed with result 'exit-code'.
$ sudo pacman -Q openssl
openssl 1.1.0.e-1
How can I fix it?
Last edited by ZeroLinux (2017-04-25 07:45:18)
Offline
You have a thread, don't hijack and crosspost: https://wiki.archlinux.org/index.php/Co … _hijacking
https://wiki.archlinux.org/index.php/Co … ss-posting
Offline
You have a thread, don't hijack and crosspost: https://wiki.archlinux.org/index.php/Co … _hijacking
https://wiki.archlinux.org/index.php/Co … ss-posting
Thanks. I am desperate. I'll try to avoid
Offline
You should get an update for openssl during the same upgrade transaction (currently updating to 1.1.0.e-1). If you didn't, then your mirror is broken.
You can fix your system by updating it from a liveCD.
Thanks, there was a part of my Dockerfile that only had `pacman -Sy` in it that explains that. I had checked on my main system after I saw the error and the update looked the same so I avoided it, and posted issue on forum.
With Docker I can just re-run the build, I posted in order to warn others and to find out what happened.
Thanks!
Offline
I crashed my system, so that every sudo, pacman or ssh command returns a
pacman: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
pacman: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
I fixed it by linking:
$ su root
$ cd /usr/lib
$ ln -s /var/lib/archbuild/multilib-x86_64/produnis/usr/lib/libcrypto.so.1.0.0 .
$ ln -s /var/lib/archbuild/multilib-x86_64/produnis/usr/lib/libssl.so.1.0.0 .
(where "produnis" is your username)
Last edited by produnis (2017-04-26 18:02:11)
Offline
Wow, that's one of the more horrible things I've seen. Don't do that.
Online
I was able to run pacman und sudo again.
So, what I did after linking:
Terminal 1:
$ pacman -Syu
# (don't press "y" to install, yet)
Terminal 2:
$ rm /usr/lib/libcrypto.so.1.0.0 /usr/lib/libssl.so.1.0.0
Terminal 1:
Typ "y" to perform upgrade
This way I was able to upgarde via pacman, und it restored my system.
Offline
It's all from the small lag Scimmia referred to (more specifically to some mirrors coincidentally last syncing *during* that lag period). The solution remains the same update your system with a recently synced mirror.
Is there any way of checking whether a mirror is recently synced before updating? Is this something I could ask pacman to check, for example?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It's not something that normally matters. Again, it's really not the time from the last sync of the mirror, it's that some mirrors coincientally synced during the period when the repos were not quite right (I think core and/or extra were ahead of community briefly).
Opting for the most recent mirror will not protect one from such problems - it really was just a packaging snafu an not a normal occurrence. For example, if core and/or extra were not lined up with community between 1am and 2am, then at 1:59am, having the most recently synced mirror would actually be the cause of trouble, while having a mirror that had not synced in several hours would protect you from the problem. Those roles might reverse a couple hours later though.
In short, snafus like the one that led to the present problems are inherently unpredictable and are no more likely to affect more recently or less recently synced mirrors: they'd just be affected different times. Once the problem was known, then one would want a mirror that had synced after the problem was resolved, hence the advice to ensure mirrors were "recently" synced.
There are other reasons to keep your mirrors up to date, but that's what tools like reflector are for.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I had the same issue as OP: "error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory"
To fix pacman I did the following:
I downloaded openssl from packages and did the following.
cd /tmp
tar xJf ~/Downloads/openssl-1.1.0.e-1-x86_64.pkg.tar.xz
cd /usr/lib
sudo ln -s /tmp/usr/lib/libcrypto.so.1.1 libcrypto.so.1.1
sudo pacman -U /var/cache/pacman/pkg/pacman-5.0.1-4-x86_64.pkg.tar.xz
sudo rm libcrypto.so.1.1This made my pacman functional again. Lesson learned. Don't update pacman without deps.
Thank you! This took me in the right direction, although I had to also simlink the libssl package as well. I was worried I would have to do a complete reinstall to recover from this.
Offline
It's not something that normally matters. Again, it's really not the time from the last sync of the mirror, it's that some mirrors coincientally synced during the period when the repos were not quite right (I think core and/or extra were ahead of community briefly).
Wouldn't this avoided if pacman would have specify the depency on the right version of openssl?
Offline