LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-17-2012, 12:39 AM   #121
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 874

Rep: Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813

Quote:
Originally Posted by QuasarDonkey View Post
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?
 
3 members found this post helpful.
Old 07-17-2012, 01:21 AM   #122
QuasarDonkey
LQ Newbie
 
Registered: Jul 2012
Location: Ireland
Distribution: Slackware
Posts: 5

Rep: Reputation: Disabled
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.
 
Old 07-17-2012, 04:05 AM   #123
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 485

Rep: Reputation: Disabled
Quote:
Originally Posted by cwizardone View Post
Looks like VirtualBox has been hit by the Friday the 13th Upgrade
VirtualBox 4.1.18 working just fine here on Slackeware64-current
 
Old 07-17-2012, 05:51 AM   #124
michelino
LQ Newbie
 
Registered: Dec 2006
Posts: 24

Rep: Reputation: 0
Quote:
Originally Posted by allend View Post
+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)
 
Old 07-17-2012, 05:56 AM   #125
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by michelino View Post
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.
 
Old 07-17-2012, 06:21 AM   #126
BroX
Member
 
Registered: Oct 2003
Location: Sweden
Distribution: Slackware64-current
Posts: 746

Rep: Reputation: 64
Quote:
Originally Posted by cwizardone View Post
Looks like VirtualBox has been hit by the Friday the 13th Upgrade,
No problems here either with 4.1.18 running a win7 guest.
 
Old 07-17-2012, 06:50 AM   #127
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
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?
 
Old 07-17-2012, 08:16 AM   #128
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 3,465

Rep: Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852Reputation: 852
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]

Last edited by allend; 07-17-2012 at 08:25 AM.
 
1 members found this post helpful.
Old 07-17-2012, 10:04 AM   #129
colorpurple21859
Senior Member
 
Registered: Jan 2008
Location: florida
Distribution: slackware64-current, puppy, ubuntu
Posts: 1,348

Rep: Reputation: 184Reputation: 184
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.
 
Old 07-17-2012, 10:09 AM   #130
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
Quote:
Originally Posted by colorpurple21859 View Post
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.

Last edited by mats_b_tegner; 07-17-2012 at 10:10 AM.
 
Old 07-17-2012, 10:25 AM   #131
BrZ
Member
 
Registered: Apr 2009
Distribution: Slackware
Posts: 495

Rep: Reputation: 81
Unhappy

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.
 
Old 07-17-2012, 10:38 AM   #132
Bindestreck
Member
 
Registered: Jul 2011
Location: Sweden
Distribution: Slackware
Posts: 320

Rep: Reputation: 64
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...
 
Old 07-17-2012, 11:25 AM   #133
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by eXpander_ View Post
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.
 
Old 07-17-2012, 11:32 AM   #134
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 438

Rep: Reputation: Disabled
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.
 
Old 07-17-2012, 01:57 PM   #135
inph
LQ Newbie
 
Registered: Jul 2012
Posts: 9

Rep: Reputation: Disabled
Quote:
Originally Posted by BrZ View Post
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 View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Microsoft forms open source subsidiary on Friday the 13th LXer Syndicated Linux News 0 04-13-2012 06:50 PM
LXer: Linux Gets Gooey on Friday the 13th LXer Syndicated Linux News 0 02-13-2009 10:10 PM
LXer: One of those magic times: On Friday the 13th! LXer Syndicated Linux News 1 02-07-2009 09:43 AM
LQ Security Report - February 13th 2005 Capt_Caveman Linux - Security 4 02-13-2005 09:51 PM
LQ security report - Feb 13th 2004 unSpawn Linux - Security 5 02-13-2004 11:36 AM


All times are GMT -5. The time now is 10:50 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration