slackware64-current can't locate libzstd.so.1 during boot
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
slackware64-current can't locate libzstd.so.1 during boot
Just installed slackware64-current and getting these messages during boot:
--------------------------------------------------------------------------------
Sat Feb 13 12:28:34 2021: mount: proc mounted on /proc.
Sat Feb 13 12:28:34 2021: Creating static nodes in /dev.
Sat Feb 13 12:28:34 2021: kmod: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: grep: /run/static-nodes: No such file or directory
Sat Feb 13 12:28:34 2021: grep: /run/static-nodes: No such file or directory
Sat Feb 13 12:28:34 2021: Starting udevd: /sbin/udevd --daemon
Sat Feb 13 12:28:34 2021: /sbin/udevd: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: Triggering udev events: /sbin/udevadm trigger --action=add
Sat Feb 13 12:28:34 2021: /sbin/udevadm: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: /sbin/udevadm: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: /sbin/udevadm: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: Initializing LVM (Logical Volume Manager):
Sat Feb 13 12:28:34 2021: Found volume group "vg01" using metadata type lvm2
Sat Feb 13 12:28:34 2021: Found volume group "vg00" using metadata type lvm2
Sat Feb 13 12:28:34 2021: 0 logical volume(s) in volume group "vg01" now active
Sat Feb 13 12:28:34 2021: 4 logical volume(s) in volume group "vg00" now active
Sat Feb 13 12:28:34 2021: Setting the system clock rate: /sbin/adjtimex --tick 10000 --frequency 0
Sat Feb 13 12:28:34 2021: Setting system time from the hardware clock (UTC): Sat Feb 13 17:28:34 UTC 2021
Sat Feb 13 12:28:34 2021: Testing root filesystem status: read-only filesystem
Sat Feb 13 12:28:34 2021: Checking root filesystem:
Sat Feb 13 12:28:34 2021: fsck from util-linux 2.36.2
Sat Feb 13 12:28:34 2021: /sbin/fsck.xfs: XFS file system.
Sat Feb 13 12:28:34 2021: Remounting root device with read-write enabled.
Sat Feb 13 12:28:34 2021: mount: /dev/mapper/vg00-root mounted on /.
Sat Feb 13 12:28:34 2021: Updating module dependency list for 5.10.15: /sbin/depmod --quick
Sat Feb 13 12:28:34 2021: /sbin/depmod: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
Sat Feb 13 12:28:34 2021: Configuring kernel parameters: /sbin/sysctl -e --system
Sat Feb 13 12:28:34 2021: Checking non-root filesystems:
Sat Feb 13 12:28:34 2021: fsck from util-linux 2.36.2
Sat Feb 13 12:28:34 2021: /dev/sda5: clean, 909/131072 files, 31580/524288 blocks
Sat Feb 13 12:28:34 2021: /sbin/fsck.xfs: XFS file system.
Sat Feb 13 12:28:34 2021: /sbin/fsck.xfs: XFS file system.
Sat Feb 13 12:28:34 2021: /sbin/fsck.xfs: XFS file system.
--------------------------------------------------------------------------------
The file is installed.
root@darkstar:/usr/lib64# ls -l /usr/lib64/libzstd*
lrwxrwxrwx 1 root root 16 Nov 21 00:09 /usr/lib64/libzstd.so -> libzstd.so.1.4.8*
lrwxrwxrwx 1 root root 16 Nov 21 00:09 /usr/lib64/libzstd.so.1 -> libzstd.so.1.4.8*
-rwxr-xr-x 1 root root 713344 Jan 20 16:49 /usr/lib64/libzstd.so.1.4.8*
I presume this is happening because /usr is not mounted at this stage in the boot. I believe I could copy the library to /lib64 but I'm wondering if anyone else is seeing this or if there is a cleaner solution.
That's news to me. I've always built Slackware systems, up through 14.2, with a separate /usr partition and had not any problems. This generally holds true for other distributions as well.
I'm also a separate /usr partition user and the last time this happened was for libsigsegv back in Dec. 28 2018.
Quote:
l/libsigsegv-2.12-x86_64-3.txz: Rebuilt.
Moved shared library into /lib{,64} to avoid problems when /usr is on a
separate partition. Thanks to TommyC7.
But please note: that has never been a recommended configuration (it was
always a bad idea prone to corner-case bugs), and with basically everyone
else moving everything into /usr, no upstream is developing with this
scenario in mind these days. Some of the problems caused by separate /usr
are simply not possible to fix in a straightforward fashion. Consider it a
completely unsupported configuration choice. While it's not my style to
make the installer refuse to allow it, I won't be bending over backwards
to try to fix bugs related to this in the future. If I recall properly,
the original rationale was to make it possible for /usr to reside on a
shared network partition, which might have made sense back when 40MB was
a typical hard drive size. I can think of no good rationale now (and no,
I don't think making /usr read-only helps security in any tangible way).
I sent a patch to "fix" (not sure if we can say it was really broken to begin with) this and it was accepted, but as the message from Mr. Volkerding points out, he won't be bending over backwards to fix bugs related to this in the future.
I somewhat recently provided the patches and the newly rebuilt zstd package in the sticky thread for what people want to see in -current (revision 1, not the second revision we have during the date of this post) with the libraries and binaries under / instead of /usr.
I've left the documentation under their respective /usr directories.
Although I submitted them on LQ.org and via e-mail to Mr. Volkerding, they haven't been accepted and I don't know if they ever will be.
If you still desire them, I provide the package (and a sha256 sum for it) along with the patch to the SlackBuild if you want to build it yourself, here:
Tommy, thank you for the info, the quote and the link. I'll check it out.
I suppose I'll need to adjust how I build my Slackware systems from now on. I understand leaving the flexibility in the installer but this definitely merits a warning or note on the partition selection during install that separating /root from /usr is not supported.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.