Friday the 13th Massive Upgrade

volkerdi · 07-17-2012, 12:39 AM

Quote:

Originally Posted by QuasarDonkey

This update has brought me nothing but major breakage.

Can't say you weren't warned.

Quote:

Now truecrypt won't mount any containers. Here's the syslog from the same time I tried mounting:

Code:

Jul 17 04:44:48 slackbook udevd[1377]: failed to create queue file: No such file or directory 
Jul 17 04:44:48 slackbook udevd[1377]: failed to create queue file: No such file or directory

I'm fairly certain that those particular udev warnings are meaningless to the point where it would be almost better to comment out the line that produces them (which is, of course, reached by a goto statement). A more likely candidate is the wacky version of mount that was enabled in the first build of the util-linux package. Now that we've gone back to the usual version of mount, are things working any better?

QuasarDonkey · 07-17-2012, 01:21 AM

No, it hasn't really helped. Thanks though. Basically truecrypt seems to lock up. But the output of mount shows:

Code:

truecrypt on /tmp/.truecrypt_aux_mnt1 type fuse.truecrypt (rw,nosuid,nodev,allow_other)

I can use mount to finish the job of mounting /tmp/.truecrypt_aux_mnt1 to wherever.

I think it could be something particular to my configuration. I do remember this happening about 6 months ago on a different system with -current. Specifically that swapon and truecrypt freeze. That was right before I got this system, so I never bothered fixing it.

I guess I'll start out fresh again, since I can't say for sure that I haven't caused these recent problems by tinkering. If the mount problems persist, I'll do some debugging, and see where it's getting stuck.

I'm sure I'll find a way of coercing Slackware to behave.

chrisretusn · 07-17-2012, 04:05 AM

Quote:

Originally Posted by cwizardone

Looks like VirtualBox has been hit by the Friday the 13th Upgrade

VirtualBox 4.1.18 working just fine here on Slackeware64-current

michelino · 07-17-2012, 05:51 AM

Quote:

Originally Posted by allend

+1 for me

I believe the problem is a symlink in the /boot/initrd-tree/lib64. I see

when the symlink should point to ld-2.15.so
Googling the error brought up this. http://lists.debian.org/debian-glibc.../msg00092.html

For me, this probably is the result of the buildup of cruft from repeated upgrades.

Not for me

Code:

root@michelino:~# ls -lh /boot/initrd-tree/lib64/ld-linux-x86-64.so.2 
lrwxrwxrwx 1 root root 9 lug 15 19:53 /boot/initrd-tree/lib64/ld-linux-x86-64.so.2 -> ld-2.9.so*

so, correct symlink but panic again with generic (obviously everything goes right with huge kernel)

TobiSGD · 07-17-2012, 05:56 AM

Quote:

Originally Posted by michelino

Not for me

Code:

root@michelino:~# ls -lh /boot/initrd-tree/lib64/ld-linux-x86-64.so.2 
lrwxrwxrwx 1 root root 9 lug 15 19:53 /boot/initrd-tree/lib64/ld-linux-x86-64.so.2 -> ld-2.9.so*

so, correct symlink but panic again with generic (obviously everything goes right with huge kernel)

The symlink should point to ld-2.15.so, not to ld-2.9.so. Correct that and it should work.

BroX · 07-17-2012, 06:21 AM

Quote:

Originally Posted by cwizardone

Looks like VirtualBox has been hit by the Friday the 13th Upgrade,

No problems here either with 4.1.18 running a win7 guest.

D1ver · 07-17-2012, 06:50 AM

I pointed the installer at my favorite -current mirror for the Slackware home media server that I'm building. Installation and configuration is going smooth as silk.

I did notice something a little weird when I was creating my initrd.
The example lilo code has the following label

Code:

grep label /boot/README.initrd
label =  3.2.23 | tr -d . | tr -d - )

Typo?

allend · 07-17-2012, 08:16 AM

Quote:

Sounds like the mkinitrd problems are limited to upgraded installs.

Quote:

just checked that, in my initrd-tree the link is pointing to the correct file. I wonder why this is the case for me, but not for others?

If you have been upgrading your system, then you are left with a collection of older glibc libraries in /lib64 (Slackware64) or /lib (Slackware32).
The /sbin/mkinitrd script has a function copy_files that copies all necessary glibc files into $SOURCE_TREE (by default /boot/initrd-tree)

Code:

copy_libs() {
  # First copy the essential glibc files:
  find /lib /lib64 -name "ld-*so*" -o -name "libnss_files*so*" -o -name "libnss_compat*so*" 2> /dev/null | xargs -I'{}' cp -P --parents '{}' $SOURCE_TREE/

Just before the initrd image is built, the necessary symlinks are created.

Code:

# Make sure all libraries have symlinks:
/sbin/ldconfig -l $(readlink -f $SOURCE_TREE)/lib/* 2> /dev/null
/sbin/ldconfig -l $(readlink -f $SOURCE_TREE)/lib64/* 2> /dev/null

The problem with an upgrade is that an earlier version file, say 2.9, is parsed after a later version file, at the moment 2.15. So the earlier version file ends up being symlinked. With a clean install, there are no earlier versions, so the problem does not occur.

I noted other incorrect symlinks created for libnss_compat.so.2 and libnss_files.so.2.

I have now cleaned out earlier versions of libraries in /lib64, so hopefully this will not be problem in the future.

I am left wondering what might be the best way to handle this in the future. Should earlier versions of libraries be removed when glibc is upgraded?

[edit]Just demonstrated, yet again, my talent for speaking after the problem has already been addressed!

Quote:

Tue Jul 17 00:21:46 UTC 2012
a/mkinitrd-1.4.7-x86_64-3.txz: Rebuilt.
Issue /sbin/ldconfig differently to avoid linking to old library versions
that might be present on the system.

[/edit]

colorpurple21859 · 07-17-2012, 10:04 AM

what is the correct way to upgrade using slackpkg? I've attempting to upgraded three salckware-current systems. Two broke during upgrading, and I believe one was after the fixes. The third system I upgraded worked with the "download all packages first" set to on. This is the order I usually upgrade in:

slackpkg update
slackpkg install-new
slackpkg upgrade-all

I'm getting ready to upgraded a 13.37 to current, will the before mentioned work, or do I need to follow the upgrade text?
Other then breaking during upgrade everything else seems to be working.

mats_b_tegner · 07-17-2012, 10:09 AM

Quote:

Originally Posted by colorpurple21859

what is the correct way to upgrade using slackpkg? I've attempting to upgraded three salckware-current systems. Two broke during upgrading, and I believe one was after the fixes. The third system I upgraded worked with the "download all packages first" set to on. This is the order I usually upgrade in:

slackpkg update
slackpkg install-new
slackpkg upgrade-all

I'm getting ready to upgraded a 13.37 to current, will the before mentioned work, or do I need to follow the upgrade text?
Other then breaking during upgrade everything else seems to be working.

slackpkg clean-system is also needed sometimes.

BrZ · 07-17-2012, 10:25 AM

My first assumption was wrong. I cleaned syslog and booted twice to be sure the error vanished, but today I saw again:

Quote:

Jul 17 12:01:09 m1 udevd[439]: failed to create queue file: No such file or directory

So, no devtmpfs thing =[

I'll try the new updates and report back.

Bindestreck · 07-17-2012, 10:38 AM

I found another issue, thunar is broken as well:

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Invalid argument. Aborting.
Aborted

This when trying to create a new folder, copy files over e.t.c...

TobiSGD · 07-17-2012, 11:25 AM

Quote:

Originally Posted by eXpander_

I found another issue, thunar is broken as well:

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Invalid argument. Aborting.
Aborted

This when trying to create a new folder, copy files over e.t.c...

I can confirm that. It seems to me that some packages of XFCE are broken (for example, xfce4-power-manager misses a symlink from libnotify.so.1 to libnotify.so), but I would expect that to be fixed with the arrival of XFCE 4.10.

TommyC7 · 07-17-2012, 11:32 AM

Pat has already addressed the xfce issue:

Quote:

Finally, these changes have broken Xfce as it exists in -current at the moment, but I'll try to do something about that soon.

Just wait.

inph · 07-17-2012, 01:57 PM

Quote:

Originally Posted by BrZ

I was having this same error: "udevd[1346]: failed to create queue file: No such file or directory"
Think it was solved by adding "devtmpfs /dev devtmpfs mode=0755,nosuid 0 0" to /etc/fstab, based on LFS instructions. No more errors about failed queue file.

Slackware does not require a devtmpfs entry in fstab:

/etc/rc.d/rc.udev creates a devtmpfs on /dev (udev_root is specified in /etc/udev/udev.conf)

You can verify this with:

Code:

~# cat /proc/mounts | grep devtmpfs
devtmpfs /dev devtmpfs rw,relatime,size=1017380k,nr_inodes=216864,mode=755 0 0

For me at least the "No more errors about failed queue file." errors come from failed firmware loading attempts. I suspect when you checked and saw no errors you had one of those better boot ups where udev firmware loading did not fail.

Quote:

Originally Posted by rworkman

The e100 firmware issue is a kernel bug, and there's nothing we can do about that. It's one of the last drivers to call request_firmware() or some such incorrectly, best I recall. This is from memory, so I may have some details wrong, but you get the idea (or at least some usable search terms to double-check me) :-)

I'm not convinced this is a kernel bug. The e100 request_firmware patches i've found were from ~2008 and in 2.6. Additionally the current 3.2.23-smp e100 driver does not try to load firmware at modprobe time but instead waits for interface up.

According to http://www.spinics.net/lists/hotplug/msg05270.html and http://thread.gmane.org/gmane.linux.network/217729 this is the correct behaviour for udev-176 and onwards.

Looking at the udev changelog: http://git.kernel.org/?p=linux/hotpl...AD;f=ChangeLog

v176 features changes in the way firmware is loaded but there isn't much for v165-175 which relates to firmware other than a tiny selinux patch which doesn't look related.

Code:

# diff -r 165/udev-165/extras/firmware/ 175/udev-175/extras/firmware/
diff -r 165/udev-165/extras/firmware/firmware.c 175/udev-175/extras/firmware/firmware.c
46c46
<       FILE *fsource, *ftarget;
---
>       FILE *fsource = NULL, *ftarget = NULL;
115,116d114
<               default:
<                       rc = 1;
150c148
<       util_strscpyl(misspath, sizeof(misspath), udev_get_dev_path(udev), "/.udev/firmware-missing/", fwencpath, NULL);
---
>       util_strscpyl(misspath, sizeof(misspath), udev_get_run_path(udev), "/firmware-missing/", fwencpath, NULL);
162d159
<                       udev_selinux_setfscreatecon(udev, misspath, S_IFLNK);
166d162
<                       udev_selinux_resetfscreatecon(udev);

My own testing points towards this being a udev v175 (or other new packages in -current) issue.

udev-175-i486-1
huge-3.2.23-smp + udev-175 + other -current packages = e100 firmware fails to load on boot inconsistently (99% fail)
huge-3.2.21-smp + udev-175 + other -current packages = e100 firmware fails to load on boot inconsistently (99% fail)
list of packages installed: http://pastie.org/4273187

udev-165-i486-2
huge-3.2.23-smp + udev-165 + -current before Fri 13th packages = e100 firmware loads every time on boot
huge-3.2.21-smp + udev-165 + -current before Fri 13th packages = e100 firmware loads every time on boot
list of packages installed: http://pastie.org/4273164

Since the e100 module loads and unloads fine it would suggest the issue is with udev v175.

# rmmod e100
# modprobe e100 debug=16
# /etc/rc.d/rc.inet1 eth0_up
# /etc/rc.d/rc.inet1 eth0_up (repeat a few times until the firmware loads)

dmesg output: http://pastie.org/4273006

At this point I'd also guess that due to inconsistent firmware loading that the issue is probably some sort of timeout or that the e100 card isn't ready fast enough when udev tries to load the firmware.

I'll get some logs of udev_log=debug with a failed and successful firmware loading.