Friday the 13th Massive Upgrade

volkerdi · 07-15-2012, 01:17 PM

Quote:

Originally Posted by eXpander_

I also get this, even at boot. And everything is screwed up. Cannot launch volumeicon, glxinfo, glxgears e.t.c.. Gaaaaah

Could you try reinstalling the mozilla-nss package to see if that cleans it up? Perhaps there's an installation order problem.

allend · 07-15-2012, 01:19 PM

Quote:

I found the problem.
There isn't symbolic link /boot/initrd-tree/lib/libz.so.1 -> libz.so.1.2.6

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

Code:

bash-4.2# ldd kmod
        linux-gate.so.1 (0xffffe000)
        libkmod.so.2 => /lib/libkmod.so.2 (0xb76c9000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb76af000)
        libc.so.6 => /lib/libc.so.6 (0xb752f000)
        liblzma.so.5 => /lib/liblzma.so.5 (0xb750a000)
        libz.so.1 => /usr/X11R6/lib/libz.so.1 (0xb74f3000)
        /lib/ld-linux.so.2 (0xb7711000)

@Olek - Thanks for the quick fix!

volkerdi · 07-15-2012, 01:23 PM

Quote:

Originally Posted by allend

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!

Bindestreck · 07-15-2012, 01:24 PM

Quote:

Originally Posted by volkerdi

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.

Bindestreck · 07-15-2012, 01:27 PM

bash-4.2$ cat mozilla-nss-3.13.5-x86_64-1:

...

Code:

usr/lib64/libplc4.so
usr/lib64/libnss3.so
usr/lib64/libssl3.so
usr/lib64/libsmime3.so
usr/lib64/libplds4.so
usr/lib64/libsoftokn3.so
usr/lib64/libnssdbm3.so
usr/lib64/libnssckbi.so
usr/lib64/libnssutil3.so
usr/lib64/libnsssysinit.so
usr/lib64/libfreebl3.so

...

Why are only some of them getting that "ldconfig warning" ?

volkerdi · 07-15-2012, 01:30 PM

Quote:

Originally Posted by eXpander_

bash-4.2$ cat mozilla-nss-3.13.5-x86_64-1:

...

Code:

usr/lib64/libplc4.so
usr/lib64/libnss3.so
usr/lib64/libssl3.so
usr/lib64/libsmime3.so
usr/lib64/libplds4.so
usr/lib64/libsoftokn3.so
usr/lib64/libnssdbm3.so
usr/lib64/libnssckbi.so
usr/lib64/libnssutil3.so
usr/lib64/libnsssysinit.so
usr/lib64/libfreebl3.so

...

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?

mlangdn · 07-15-2012, 01:39 PM

Deleting ld.so.cache and running ldconfig again made no difference for me - except I only have three showing up. Not as many as eXpander.

Bindestreck · 07-15-2012, 01:49 PM

Quote:

Originally Posted by volkerdi

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:

/usr/lib64/libnss3.so.1d
/usr/lib64/libnssutil3.so.1d
/usr/lib64/libsmime3.so.1d
/usr/lib64/libplc4.so.0d
/usr/lib64/libnspr4.so.0d

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:

ln -s /usr/lib64/libnss3.so /usr/lib64/libnss3.so.1d
ln -s /usr/lib64/libnssutil3.so /usr/lib64/libnssutil3.so.1d
ln -s /usr/lib64/libsmime3.so /usr/lib64/libsmime3.so.1d
ln -s /usr/lib64/libplc4.so /usr/lib64/libplc4.so.0d
ln -s /usr/lib64/libnspr4.so /usr/lib64/libnspr4.so.0d

I dont understand though why one cannot make symlinks from seamonkey-2.10.1?

Now, for the volumeicon thing, something about libnotify:

Code:

bash-4.2$ volumeicon
volumeicon: error while loading shared libraries: libnotify.so.1: cannot open shared object file: No such file or directory

Anyone else having problem with volumeicon? Can you even compile it?

Anyway, thanks for help!

*EDIT:

Ok, I'm not sure what happened during the current updates,,, anyway I just symlinked again

:
ln -s /usr/lib64/libnotify.so.4.0.0 libnotify.so.1

Now volumeicon works...

Woodsman · 07-15-2012, 03:15 PM

Quote:

Me either, which is why I disabled that in /etc/inittab. If you move your .new file over the annoying behavior will cease.

Thanks Pat.

Yet Another Improvement from some upstream egghead?

Pat, would you please add a note about this change in CHANGES_AND_HINTS.TXT? Thanks much if you do.

mlangdn · 07-15-2012, 03:33 PM

I had forgotten about Spotify. I don't even use it, so I nuked it and all the symlinks. No more ldconfig errors. Thanks eXpander.

Celyr · 07-15-2012, 03:34 PM

Quote:

Originally Posted by samac

Oh gracious BDFL

Small request with regard to the changelog text.

Would it be possible to list all the removed packages and all the added packages at the start of the changelog?

I feel that this would make upgrading easier and lead to less threads about broken systems on LQ.

samac

If you set downloadall to on and you use this sequence:
slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system

You will never break your slackware.
So IMO it's useless to get a changelog sorted

BroX · 07-15-2012, 03:51 PM

Quote:

Originally Posted by Woodsman

Thanks Pat.

Yet Another Improvement from some upstream egghead?

Pat, would you please add a note about this change in CHANGES_AND_HINTS.TXT? Thanks much if you do.

I thought 'init 3' has always been the default runlevel?

Woodsman · 07-15-2012, 03:54 PM

Quote:

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.

ruario · 07-15-2012, 03:56 PM

Quote:

Originally Posted by samac

Would it be possible to list all the removed packages and all the added packages at the start of the changelog?

Code:

wget -qO- ftp://ftp.slackware.com/pub/slackware/slackware-current/ChangeLog.txt | grep ':  Removed\.$'

Code:

wget -qO- ftp://ftp.slackware.com/pub/slackware/slackware-current/ChangeLog.txt | grep ':  Added\.$'

Woodsman · 07-15-2012, 04:02 PM

Quote:

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.