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.
I can confirm this problem with using mkinitrd to create an initrd.gz to use the generic kernel.
Apparently this symlink is required to satisfy kmod
I've seen this issue here, too, but oddly if I chroot into /boot/initrd-tree/ kmod does seem to run without it. But in any case, I've put another mkinitrd package up with a couple of fixes. Hopefully it will do the trick, along with a rebuilt lvm2 package that should fix the glitches in the udev rules for that. Let me know!
Could you try reinstalling the mozilla-nss package to see if that cleans it up? Perhaps there's an installation order problem.
Hi volkerdi!
After installing "mozilla-nss-3.13.5-x86_64-1.txz" all *.so files I deleted before (see my edited post) is back:
Code:
Installing mozilla-nss-3.13.5-x86_64-1...
Verifying package mozilla-nss-3.13.5-x86_64-1.txz.
Installing package mozilla-nss-3.13.5-x86_64-1.txz:
PACKAGE DESCRIPTION:
# mozilla-nss (Network Security Services)
#
# Network Security Services (NSS) is a set of libraries designed to
# support cross-platform development of security-enabled client and
# server applications. Applications built with NSS can support
# SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME,
# X.509 v3 certificates, and other security standards.
#
# Read http://www.mozilla.org/projects/security/pki/nss/overview.html
#
/sbin/ldconfig: /usr/lib64/libplc4.so is not a symbolic link
/sbin/ldconfig: /usr/lib64/libnss3.so is not a symbolic link
/sbin/ldconfig: /usr/lib64/libnssutil3.so is not a symbolic link
/sbin/ldconfig: /usr/lib64/libnspr4.so is not a symbolic link
/sbin/ldconfig: /usr/lib64/libsmime3.so is not a symbolic link
Executing install script for mozilla-nss-3.13.5-x86_64-1.txz.
Package mozilla-nss-3.13.5-x86_64-1.txz installed.
Searching for NEW configuration files
No .new files found.
Why are only some of them getting that "ldconfig warning" ?
That's a good question. In mozilla-nss, they aren't supposed to be symbolic links. They aren't here, but running ldconfig doesn't generate any warnings about that either.
Just a hunch... maybe delete /etc/ld.so.cache and see if running ldconfig again rebuilds it without the warnings?
That's a good question. In mozilla-nss, they aren't supposed to be symbolic links. They aren't here, but running ldconfig doesn't generate any warnings about that either.
Just a hunch... maybe delete /etc/ld.so.cache and see if running ldconfig again rebuilds it without the warnings?
Hi,
I found the problem, and I think it is because of Spotify. To be able to launch Spotify I had to do symlinks from /usr/lib64/seamonkey-2.10.1/ to /usr/lib64, the corresponded files match those from the ldconfig warnings:
So I deleted all the Spotify symlinks and re-added them but from /usr/lib64 instead of /usr/lib64/seamonkey-2.10.1/ because then I will generate the warnings again:
I've seen this issue here, too, but oddly if I chroot into /boot/initrd-tree/ kmod does seem to run without it. But in any case, I've put another mkinitrd package up with a couple of fixes. Hopefully it will do the trick, along with a rebuilt lvm2 package that should fix the glitches in the udev rules for that. Let me know!
I updated with the latest July 15 changes and rebuilt the initrd. The stdout is now cleaner without the udev messages.
I thought 'init 3' has always been the default runlevel?
Yes, init 3 is the default. We're talking about how recent changes in the util-linux package now change the default to clearing the screen after the init process ends. When that happens the user can't scroll back and view the boot process messages. The work-around to that silly new default is to add the --noclear parameter to the agetty command in /etc/inittab.
I asked Pat to mention this in the CHANGES_AND_HINTS.TXT file because right now the only Slackware related help with this change is this forum thread. There are plenty of references around the web and Slackware is not the only distro affected by this change. The CHANGES_AND_HINTS.TXT file is a good place to document this "abrupt" change.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.