Project

General

Profile

Bug #3368

Bug #3372: [various]: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory - may require chrooting

pacman -Syu error breaks pacman - may require chrooting

penaiple - over 1 year ago - . Updated over 1 year ago.

Status:
fixed
Priority:
bug
Assignee:
% Done:

90%


Description

pacman -Syu (yay -Syu) error, breaks pacman and requires chrooting + reinstallation of openssl

[root@nsa ~]# pacman 
pacman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

this requires a chroot or pacstrap in a live OS to reinstall openssl, or backing up /usr/bin/pacman or /usr/lib/libcrypto.so.1.1 beforehand, moving the file(s) back later.

History

#1

Updated by penaiple over 1 year ago

[fed@nsa ~] ~> yay -R openssl-1.1
checking dependencies...

Packages (1) openssl-1.1-1.1.1.s-2

Total Removed Size:  5.51 MiB

:: Do you want to remove these packages? [Y/n] 
:: Processing package changes...
(1/1) removing openssl-1.1                                                                      [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Refreshing PackageKit...
(3/3) disable automatic archlinux-keyring refresh
[fed@nsa ~] ~> yay -S openssl-1.1
yay: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
[fed@nsa ~] ~> sudo cp libcrypto.so.1.1 /usr/lib
[fed@nsa ~] ~> yay -S openssl-1.1
resolving dependencies...
looking for conflicting packages...

Packages (1) openssl-1.1-1.1.1.s-2

Total Installed Size:  5.51 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                  [--------------------------------------------------------] 100%
(1/1) checking package integrity                                                                [--------------------------------------------------------] 100%
(1/1) loading package files                                                                     [--------------------------------------------------------] 100%
(1/1) checking for file conflicts                                                               [--------------------------------------------------------] 100%
error: failed to commit transaction (conflicting files)
openssl-1.1: /usr/lib/libcrypto.so.1.1 exists in filesystem
Errors occurred, no packages were upgraded.
 -> error installing repo packages
[fed@nsa ~] ~> yay -S openssl-1.1 --overwrite "*" 
resolving dependencies...
looking for conflicting packages...

Packages (1) openssl-1.1-1.1.1.s-2

Total Installed Size:  5.51 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                  [--------------------------------------------------------] 100%
(1/1) checking package integrity                                                                [--------------------------------------------------------] 100%
(1/1) loading package files                                                                     [--------------------------------------------------------] 100%
(1/1) checking for file conflicts                                                               [--------------------------------------------------------] 100%
(1/1) checking available disk space                                                             [--------------------------------------------------------] 100%
:: Processing package changes...
(1/1) installing openssl-1.1                                                                    [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Refreshing PackageKit...
(3/3) disable automatic archlinux-keyring refresh

here is a demonstration of what you need to do to prevent/fix this problem.

apparenly, libcrypto.so.1.1 now comes from openssl-1.1, but is required by pacman.
yet the openssl-1.1 package is NOT a pacman dependency (yet), which will break pacman and require you to manually copy over the libcrypto.so.1.1 file into /usr/lib, and reinstall openssl + openssl-1.1 with --overwrite "*".

#2

Updated by reg over 1 year ago

Just wanted to say that I've just run into the same problem.

#3

Updated by direnis over 1 year ago

I fixed it by first pacstrapping "openssl" and "openssl-1.1" to the root, then chrooted and ran mkinitcpio and grub-mkconfig. (I think grub-mkconfig is unnecessary but i ran it just to make sure.)

#4

Updated by nona over 1 year ago

Does this happen with a system without yay? that is: does it happen with Parabola? yay is not part, supported, and possibly not recommended in Parabola. Please, do not create a bug report for something which is not part of Parabola. If you want to know if someone can help you, your first bet is to try to reach the developers of the package or possibly using the forum (not a bug report).

#5

Updated by v3d over 1 year ago

Can confirm this breaks upgrades (with yay), fresh parabola installs and arch migrations (no yay) for me.

Tested in VMs just now.

#6

Updated by nona over 1 year ago

v3d wrote:

Can confirm this breaks upgrades (with yay), fresh parabola installs and arch migrations (no yay) for me.

Tested in VMs just now.

Sorry. Can you rephrase? From the message, it seems that the problem is indeed yay ("breaks upgrades (with yay)"), not Parabola ("fresh parabola installs ... (no yay)"). Thank you.

#7

Updated by bill-auger over 1 year ago

  • Status changed from unconfirmed to in progress
  • Description updated (diff)
  • Subject changed from pacman -Syu (yay -Syu) error, breaks pacman and requires chrooting + reinstallation of openssl to pacman -Syu error breaks pacman - may require chrooting - error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
#8

Updated by bill-auger over 1 year ago

  • Assignee set to bill-auger
#9

Updated by bill-auger over 1 year ago

the current 'pacman' package in libre works now with the new openssl-1.1 package - installing the new 'openssl-1.1' package first before upgrading, (probably) avoids the bug

those who have not yet upgraded openssl can prepare (probably) to avoid the bug:

  # ## openssl 1.1.1.* installed (before upgrading):
  # pacman -Sy openssl-1.1 parabola-keyring && pacman -Su

if ppl need to repair now:

  # ## openssl 3.* installed (after upgrading):
  # pacstrap /path/to/broken/system/ openssl-1.1 parabola-keyring
  # ## -> then reboot then pacman -Syu

but the pacman in libre-testing is the proper fix - can ppl plz test it?

  # ## openssl 1.1.1.* installed (before upgrading):
  # pacman -Sy parabola-keyring
  # pacman -U https://repo.parabola.nu/pool/parabola/pacman-6.0.1-4.parabola4-x86_64.pkg.tar.zst
  # pacman -Su

  # ## openssl 3.* (after upgrading):
  # pacstrap /path/to/broken/system/ parabola-keyring
  # pacstrap /path/to/broken/system/ -U https://repo.parabola.nu/pool/parabola/pacman-6.0.1-4.parabola4-x86_64.pkg.tar.zst
  # ## -> then reboot then pacman -Syu

#10

Updated by bill-auger over 1 year ago

probably also these are affected:

$ parabola-dependents libcrypto.so
direct parabola dependents:
  pcr/assh
  pcr/check-pacman-mtree
  pcr/icinga
  pcr/icinga2
  pcr/icinga2-common
  pcr/ipmiutil
  pcr/kamailio-autheph-modules
  pcr/kamailio-mongodb-modules
  pcr/kamailio-outbound-modules
  pcr/kamailio-websocket-modules
  pcr/libtorrent-extended
  pcr/ocaml-ssl
  pcr/perspectives-server
  libre/ruby
  libre/ruby2.7
  pcr/snapraid
  pcr/tahoe-lafs
  pcr/trousers

#11

Updated by Mampir over 1 year ago

It seems like systemd-cryptsetup is also affected by this issue and I'm not sure how to make it work anymore. Decrypting a volume during initramfs now fails. It fails even after doing a clean installation with openssl-1.1 installed.

I don't see any errors when making the initramfs system, but when booting I get errors during the "Cryptography Setup for crypt" step. Maybe the issue is somehow related to whirlpool and openssl-1.1, but since I still don't understand how to fix this issue yet, I'm pasting my logs here:

Nov 06 15:55:42 parabola systemd[1]: Starting Cryptography Setup for crypt...
░░ Subject: A start job for unit systemd-cryptsetup@crypt.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit systemd-cryptsetup@crypt.service has begun execution.
░░ 
░░ The job identifier is 17.
Nov 06 15:55:42 parabola kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
Nov 06 15:55:43 parabola systemd-cryptsetup[170]: Requested LUKS hash whirlpool is not supported.
Nov 06 15:55:43 parabola systemd-cryptsetup[170]: Failed to load LUKS superblock on device /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx: Invalid argument
Nov 06 15:55:43 parabola kernel: device-mapper: uevent: version 1.0.3
Nov 06 15:55:43 parabola kernel: device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
Nov 06 15:55:43 parabola kernel: audit: type=1130 audit(1667742942.997:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-cryptsetup@crypt comm="systemd" exe="/init" hostname=? addr=? terminal=? res=failed'
Nov 06 15:55:42 parabola audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-cryptsetup@crypt comm="systemd" exe="/init" hostname=? addr=? terminal=? res=failed'
Nov 06 15:55:43 parabola systemd[1]: systemd-cryptsetup@crypt.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An ExecStart= process belonging to unit systemd-cryptsetup@crypt.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 06 15:55:43 parabola systemd[1]: systemd-cryptsetup@crypt.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit systemd-cryptsetup@crypt.service has entered the 'failed' state with result 'exit-code'.
Nov 06 15:55:43 parabola systemd[1]: Failed to start Cryptography Setup for crypt.
░░ Subject: A start job for unit systemd-cryptsetup@crypt.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit systemd-cryptsetup@crypt.service has finished with a failure.
░░ 
░░ The job identifier is 17 and the job result is failed.
Nov 06 15:55:43 parabola systemd[1]: Dependency failed for Local Encrypted Volumes.
░░ Subject: A start job for unit cryptsetup.target has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit cryptsetup.target has finished with a failure.
░░ 
░░ The job identifier is 16 and the job result is dependency.
Nov 06 15:55:43 parabola systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Nov 06 15:55:43 parabola systemd[1]: Reached target System Initialization.
░░ Subject: A start job for unit sysinit.target has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
#12

Updated by Mampir over 1 year ago

If someone is still able to boot from an encrypted LUKS partition, please tell.

#13

Updated by bill-auger over 1 year ago

If someone is still able to boot from an encrypted LUKS partition, please tell.

there is an arch bug report tracking that problem:
https://bugs.archlinux.org/task/76440

i ahve not read the bug report; but i think you can correct that
by installing 'openssl-1.1'

#14

Updated by Mampir over 1 year ago

As I wrote previously, I did install openssl-1.1 and then I made the initramfs image. The logs are with openssl-1.1 installed. All the packages are up to date. Also, I can see that libcrypto.so.1.1 and libcrypto.so.3 are both inside the initramfs image:

# lsinitcpio /boot/initramfs-linux-libre-lts.img | grep libcrypto
usr/lib/libcrypto.so.1.1
usr/lib/libcrypto.so.3

The arch bug report seems like it's not resolved too. I'm still not sure if anyone is able to boot from an encrypted LUKS partition.

#15

Updated by bill-auger over 1 year ago

to be clear - you have both openssl packages installed? and the system will not boot? - this command shows both openssl packages?

$ pacman -Qs openssl
#16

Updated by GNUtoo over 1 year ago

I've tested the advise to install openssl-1.1 to recover a broken system and it worked.

I booted from the install iso and opened my encrypted partition and chrooted inside (if you have other partitions as well you need to mount them too).

For example:

# mount /dev/mapper/<my-partition> /mnt
# mount /dev/sda1 /mnt/boot

I then chrooted inside:

# arch-chroot /mnt

And I did:

# pacman -Syu
# pacman -S openssl-1.1
# mkinitcpio -p linux-libre

I then rebooted and chose linux-libre and it booted fine.

Here pacman worked.

On another system that I didn't reboot yet, pacman didn't work so I did that instead:

# cd /var/cache/pacman/pkg
# gpg --verify openssl-1.1.1.q-1.0-i686.pkg.tar.zst.sig 
gpg: assuming signed data in 'openssl-1.1.1.q-1.0-i686.pkg.tar.zst'
gpg: Signature made jeu. 07 juil. 2022 11:43:07 CEST
gpg:                using RSA key 16194A82231E9EF823562181C8E8F5A0AF9BA7E7
gpg: Good signature from "Andreas Baumann (sign) <mail@andreasbaumann.cc>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1619 4A82 231E 9EF8 2356  2181 C8E8 F5A0 AF9B A7E7
# tar xf openssl-1.1.1.q-1.0-i686.pkg.tar.zst -C /

Then that made pacman work again, so I did that:

# pacman -S openssl openssl-1.1 --overwrite="*" 
# mkinitcpio -p linux-libre

And the warnings during mkinitcpio disapeared and pacman also still worked fine.

#17

Updated by GNUtoo over 1 year ago

I forgot to mention that the broken system used an encrypted partition and that it was running parabola x86_64 (I was told that i686 and armv7h were not affected yet).

#18

Updated by eliotime3000 over 1 year ago

In my case, that bug appeared and I didn't have my partitions encrypted and all that jazz.

Using the installation ISO, what I did is mount my Parabola partition first and pacstrapped openSSL 1.1 (I mean, pacstrap /mnt openssl-1.1), then I applied that mkinitcpio -p linux-libre command in the arch-chroot /mnt stage, unmounted everywthing, rebooted and I saved my Parabola partition in my netbook. I'll make that procedure in my Desktop PC.

Thanks for that advice. I hope that OpenSSL 3.0.x will be patched ASAP.

#19

Updated by Mampir over 1 year ago

bill-auger wrote:

to be clear - you have both openssl packages installed? and the system will not boot? - this command shows both openssl packages?

Yes, they are both installed:

$ pacman -Qs openssl
local/libevent 2.1.12-4
local/openssl 3.0.7-2
local/openssl-1.1 1.1.1.s-2

Also I'm remaking the initramfs image after that:

mkinitcpio -p linux-libre
==> Building image from preset: /etc/mkinitcpio.d/linux-libre.preset: 'default'
  -> -k /boot/vmlinuz-linux-libre -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-libre.img
==> Starting build: 5.18.14-gnu-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [systemd]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-libre.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-libre.preset: 'fallback'
  -> -k /boot/vmlinuz-linux-libre -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-libre-fallback.img -S autodetect
==> Starting build: 5.18.14-gnu-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [systemd]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-libre-fallback.img
==> Image generation successful

When I try to boot I get the same message:

Nov 06 15:55:43 parabola systemd[1]: Failed to start Cryptography Setup for crypt.

In the "journalctl -xb" I can see:

Nov 07 07:33:43 parabola systemd[1]: Starting Cryptography Setup for crypt...
Nov 07 07:33:43 parabola kernel: device-mapper: uevent: version 1.0.3
Nov 07 07:33:43 parabola kernel: device-mapper: ioctl: 4.46.0-ioctl (2022-02-22) initialised: dm-devel@redhat.com
Nov 07 07:33:43 parabola systemd-cryptsetup[167]: Requested LUKS hash whirlpool is not supported.
Nov 07 07:33:43 parabola systemd-cryptsetup[167]: Failed to load LUKS superblock on device /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx: Invalid argument
Nov 07 07:33:43 parabola systemd[1]: systemd-cryptsetup@crypt.service: Main process exited, code=exited, status=1/FAILURE
Nov 07 07:33:43 parabola systemd[1]: systemd-cryptsetup@crypt.service: Failed with result 'exit-code'.
Nov 07 07:33:43 parabola systemd[1]: Failed to start Cryptography Setup for crypt.
Nov 07 07:33:43 parabola systemd[1]: Dependency failed for Local Encrypted Volumes.
Nov 07 07:33:43 parabola systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Nov 07 07:33:43 parabola audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-cryptsetup@crypt comm="systemd" exe="/init" hostname=? addr=? terminal=? res=failed'

#20

Updated by Mampir over 1 year ago

I think the issue might be related to OpenSSL 3 not supporting whirlpool, while OpenSSL 1.1 was supporting it:

$ openssl-1.1 dgst | grep whirlpool
-ssl3-sha1                 -whirlpool                 
$ openssl dgst -list | grep whirlpool
$ openssl version
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)

Also there's this discussion on removing Whirlpool: https://github.com/openssl/openssl/issues/5118

Also, my LUKS partition is using whirlpool.

#21

Updated by wael over 1 year ago

If the case with whirlpool removal holds this will probably break all Libreboot systems with FDE.
At least on my ThinkPad T400 I followed what used to be the official guide on libreboot.org (now the one in Parabola's wiki) and that ends up with the hash spec being whirlpool (as verified on my machine).

#22

Updated by dllud over 1 year ago

The hash algorithm in use by LUKS can be checked with

cryptsetup luksDump /dev/sda1

(change the device accordingly). It will show under Hash spec.

It should be possible to change the hash algorithm with something like:

cryptsetup reencrypt --hash sha512 --keep-key /dev/sda1

Check man cryptsetup-reencrypt for details.

#23

Updated by wael over 1 year ago

dllud wrote:

It should be possible to change the hash algorithm with something like:
[...]
Check man cryptsetup-reencrypt for details.

Do note that cryptsetup-reencrypt isn't guaranteed to work, make sure you have backups.
Arch Wiki warns against possible data loss: https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Re-encrypting_devices

#24

Updated by Mampir over 1 year ago

I can confirm that switching from whirlpool to sha512 fixes the issue. Also installing the new version of the cryptsetup package (currently 2.5.0-4) also brings back whirlpool support. I image the whirlpool support is going to be removed again in the future, so you should probably switch at some point. I switched from whirlpool to sha512 by using:

cryptsetup luksFormat --type luks1 --volume-key-file KEYFILE --uuid UUID -c CIPHER -s KEY_SIZE -h sha512 /dev/...

Be aware that there's LUKS1 and LUKS2. If you are using a Libreboot system, I image you are using probably LUKS1. If you don't specify "--type luks1" it will install LUKS2, which takes bigger space in the beginning of the volume, and this will probably delete some of your data. If you are using LUKS2, you could probably use "cryptsetup reencrypt", but I haven't tested that. In any case, you should backup stuff, if you are not sure what you are doing.

#25

Updated by wael over 1 year ago

Mampir wrote:

"cryptsetup reencrypt", but I haven't tested that. In any case, you should backup stuff, if you are not sure what you are doing.

Just to clarify, that command can be run on-line? Or from a live CD?

#26

Updated by direnis over 1 year ago

bill-auger wrote:

if ppl need to repair now:

>  # ## openssl 3.* installed (after upgrading):
>  # pacstrap /path/to/broken/system/ openssl-1.1 parabola-keyring
>  # ## -> then reboot then pacman -Syu

A little bit late, but just pacstrapping openssl-1.1 alone did not worked for me, i had to chroot and run mkinitcpio and grub-mkconfig. (Had and solved the problem at 5/11/2022)

#27

Updated by bill-auger over 1 year ago

so to be clear, the boot issue was not related to openssl? and affected only system users, and for only 3 days?

the topic of this ticket is pacman+openssl missing libcrypto.so.1.1 - it is a parabola-specific 'bug' ticket - the boot issue should be a new ticket, if not fixed already - that would be a 'forwarded-upstream' ticket, because it affects all arch users as well - parabola would normally not fix those, but for the severity and urgency of preventing the boot failures and borked pacman binaries

#28

Updated by wael over 1 year ago

This is still related to the openssl issue, cryptsetup relies on openssl (listed as a dependency), doesn't matter much what the init system is, whirlpool is unusable now and so any LUKS-encrypted system using whirlpool as the hash spec will have this issue.

#29

Updated by direnis over 1 year ago

when the pacman error was present, i could not boot into my system, it'd throw me into the emercany shell that i cant use my keyboard with. had to force off my system and boot to live iso. everything turned to normal when i fixed the openssl-pacman issue and ran mkinitcpio chrooted.

#30

Updated by GNUtoo over 1 year ago

Is it a good idea if we rebuild cryptsetup and link it to openssl-1.1 ?

That would fix the whirpool issue, but it would require us to blacklist upstream cryptsetup at least until upstream fixes that too.

Or should we just wait for the various Arch Linux to fix it?

After upgrading whirlpool works (I can create LUKS volumes with whirlpool).

So for now we have:

Arch OpenSSL cryptsetup luksFormat -h whirlpool
armv7h 1.1.1.q-1 2.5.0-1 ?
i686 1.1.1.q-1.0 2.4.1-1.0 OK
x86_64 3.0.7-2 2.5.0-4 OK

I used this script for testing:

#!/bin/sh
# GPLv3+
usage()
{
    echo "$0 <path/to/image>" 
    exit 1
}
if [ $# -ne 1 ] ; then
    usage
fi
image="$1" 
size="100M" 
qemu-img create -f raw "${image}" "${size}" 
sudo cryptsetup luksFormat \
    --type luks1 \
    -h whirlpool \
    ${image}

#31

Updated by bill-auger over 1 year ago

Is it a good idea if we rebuild cryptsetup and link it to openssl-1.1 ?

i have new cryptsetup package(s) ready also; but they may not be needed now, since cryptsetup 2.5.0-4 this morning

wael wrote:

This is still related to the openssl issue, cryptsetup relies on openssl

i only want to document this/these seemingly related problems clearly - there seems to be multiple issues, and each appear to now have an independent fix - one involving 'pacman'+'openssl'=various_libcrypt*_errors; and the other involving 'cryptsetup', dropping support for whirlpool-summed FS - these may seem related only due to the timing and severity of the two problems

cryptsetup does not rely on any specific version of openssl, and openssl is probably not the cause of the whirlpool/mount failures - AFAICT, the encrypted boot breakage is fixed by cryptsetup 2.5.0-4, the entire purpose of the pkgrel '4' rebuild/patch (restores whirlpool support) - i added that to the news item earlier - if that holds, then the cryptsetup problem would not be documented, though it would deserve separate bug report, if not yet fixed

i have a new pacman ready which depends on openssl-1.1, so can close this ticket today - pacman, being in 'base', assures that everyone will get the fix - hopefully most parabola users do not upgrade every day (many/most will never hit that boot failure) - if ppl still can not boot, something drastic may be necessary - i have ideas about that already

#32

Updated by bill-auger over 1 year ago

  • Parent task set to #3372
#33

Updated by bill-auger over 1 year ago

  • Subject changed from pacman -Syu error breaks pacman - may require chrooting - error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory to pacman -Syu error breaks pacman - may require chrooting
#34

Updated by bill-auger over 1 year ago

  • % Done changed from 0 to 90
#35

Updated by bill-auger over 1 year ago

  • Status changed from in progress to fixed

Also available in: Atom PDF