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 just now noticed in the misbehaving systems that /etc/udev/rules.d/70-persistent-cd.rules is not being generated. That is the rule set that actually creates the sym links. I need to figure out what creates that rule set.
The persistent CD rules are created by rc.udev, however, there's no specific check to see if CD rules need to be created, since there are a lot of machines that don't have optical drives and we don't want to hold up the boot process needlessly triggering udev to create them. The solution (hack?) that was used is to try to generate both net and CD rules if there's no existing 70-persistent-net-rules. If you have that file, it's not going to try to create rules for the optical drive.
I'd try removing any existing /etc/udev/rules.d/70-persistent-net.rules and rebooting to see if both of the files get created. If that doesn't work, you might try commenting out the test for the existence of the net rules forcing it to issue the trigger to see if that helps. If it does, possibly we'll need to add an additional check for [ -r /dev/sr0 -a ! -r 70-persistent-cd.rules ], or something along those lines. Let me know what you find out.
I just now noticed in the misbehaving systems that /etc/udev/rules.d/70-persistent-cd.rules is not being generated. That is the rule set that actually creates the sym links. I need to figure out what creates that rule set.
It seems that udev-182 have been declared guilty by the jury namely Patrick, Volkerding and the BDFL, see the end of the long statement about this package in the changelog dated Sun Jul 22 22:38:36 UTC 2012:
Code:
And if anyone knows how to get symlinks working for a hotplugged optical
drive like they did in udev-165, a fix would be most appreciated.
PS I just realized that I am now a member of the 2k club
PS2 Really, 2k=2048, I know...
Last edited by Didier Spaier; 09-04-2012 at 08:50 PM.
Unfortunately no, /media is going to be obsolete now.
However there are few thing you could do, at least for now. Get rid of udisks2 and stick with udisks as long as posible or apply this patch (http://paste.lisp.org/display/129168), but it isn't long-term solution.
Apparently udisks developers decided that instead of implementing certain feature (actually useful one) the right way (read: harder), they simply break standards (FHS in this case) without worrying "what could possibly go wrong?". Sounds familiar? Yes, it's the same systemd-like mindset - "I like it that way, so it'll become new standard. XYZ isn't relevant anymore." I guess only long-term solution is to fork udisks2 and let GNOME (udisks2 will be it's default auto-mounter) , udev+systemd guys live in their Perfect World (TM) alone, while we'll be using saner software in saner way.
Tue Sep 4 21:54:46 UTC 2012
A few more adjustments, but probably not enough to merit calling this a
new RC release. Pretty close now, but please report any bugs!
a/aaa_elflibs-14.0-x86_64-4.txz: Rebuilt.
a/coreutils-8.19-x86_64-1.txz: Upgraded.
Upgraded for some important bugfixes, including possible data loss in
"sort" output.
a/eject-2.1.5-x86_64-3.txz: Rebuilt.
Fixed "eject -T". Thanks to Darrell Anderson.
a/etc-14.0-x86_64-1.txz: Upgraded.
Fixed root $path in /etc/csh.login.new.
Thanks to Goran Lazic.
a/grep-2.14-x86_64-1.txz: Upgraded.
Upgraded for some important bugfixes. This fixes a matching bug when
using a multibyte locale, and merges a more refined patch from upstream
for the false detection of small text files as binary on certain
filesystems (including Btrfs).
a/mkinitrd-1.4.7-x86_64-6.txz: Rebuilt.
Fixed sed substitution for README.initrd.
Thanks to D1ver on LQ.
l/pygobject-2.28.6-x86_64-2.txz: Rebuilt.
Patched type mismatch.
Thanks to wadsworth on LQ.
n/gnutls-3.0.23-x86_64-1.txz: Upgraded.
Upgraded for some important bugfixes.
n/netatalk-2.2.3-x86_64-2.txz: Rebuilt.
Handle atalkd.conf.new and papd.conf.new in doinst.sh.
Thanks to elyk on LQ.
isolinux/initrd.img: Rebuilt.
Fixed size of a full installation in setup (7.3GB).
Added comment=x-gvfs-show to /dev/cdrom line in /etc/fstab.
usb-and-pxe-installers/usbboot.img: Rebuilt.
Fixed size of a full installation in setup (7.3GB).
Added comment=x-gvfs-show to /dev/cdrom line in /etc/fstab.
+--------------------------+
After several dozen reboots this evening, here is what I can share:
I have no idea why on two Slackware 14 systems both sets of persistent rules are not generated and on a third Slackware 14 system both sets of rules are always generated. I have reinstalled packages, diffed various directories, and I can't find anything obvious. The only thing I notice is the good system is on my sda drive and the misbehaving systems are on my sdc drive. A clue? I don't know.
As you noted, the script's persistent-net test will always prevent the generation of a missing persistent-cd rule set. Yet delete the persistent-net rule set and interesting things happen.
On the two misbehaving systems, when I delete both sets of rules and reboot, the persistent-cd rule set is always generated and the persistent-net set is not. Always.
When I delete one or the other set of persistent rules, the next reboot, or manually running of 'udevadm trigger --type=devices --action=add' will generate the missing rule set.
On the two misbehaving systems, I always have to run 'udevadm trigger --type=devices --action=add' twice to obtain both rule sets. Running twice never fails to generate the missing rule set. With both sets missing, running once will only generate the persistent-cd set.
With that said, and after those many reboots, I finally settled on the following changes to the rc.udev script:
Code:
if [ ! -r /etc/udev/rules.d/70-persistent-net.rules ] || [ ! -r /etc/udev/rules.d/70-persistent-cd.rules ]; then
# Test that we can actually write to the directory first:
if touch /etc/udev/rules.d/testfile 2> /dev/null ; then
rm -f /etc/udev/rules.d/testfile
# This should add persistent net/cd rules:
echo "Triggering udev to write persistent rules to /etc/udev/rules.d/"
/sbin/udevadm trigger --type=devices --action=add
# Don't decrease the sleep time!
sleep 3
if [ ! -r /etc/udev/rules.d/70-persistent-net.rules ] || [ ! -r /etc/udev/rules.d/70-persistent-cd.rules ]; then
# Why is this needed twice and why is a sledge hammer needed?
/sbin/udevadm trigger --type=devices --action=add
# Don't decrease the sleep time!
sleep 1
fi
fi
fi
I added the comments to not decrease the sleep times. Seems when I fiddled with decreasing the sleep times then things broke.
I tried a long first sleep time (10 seconds) to no avail. Seems the magic solution to ensure both sets of rules are always generated is to run the udev trigger command twice and to ensure there is a delay/sleep time involved. As this delay should only affect users the first time they boot into Slackware 14, that likely will not be a problem.
One last caveat is when both rule sets need to be generated, sometimes my network card failed to initialize properly. Changing the delay/sleep times did not cure that intermittent event.
The root cause seems to be that running 'udevadm trigger --type=devices --action=add' will only generate one rule set per occurrence.
I'm usually not "that guy", but has anyone considered removing the "Install packages from floppy" option in pkgtool? Please don't burn my house down with the flames that I'm sure are being stoked. lol
Holy crap I got mentioned in a changelog! Even if it was for something entirely trivial, I'm saving a screenshot! 14.0 is still running beautifully here.
I'm usually not "that guy", but has anyone considered removing the "Install packages from floppy" option in pkgtool?
This Pkgtool option supports 3,5" and 5,25" HD floppy disks only. What if I have packages on a DD floppy? It also doesn't detect my modern double-speed USB floppy drive.
Holy crap I got mentioned in a changelog! Even if it was for something entirely trivial, I'm saving a screenshot! 14.0 is still running beautifully here.
It's a good feeling isn't it? Especially when it's in the changelog of the oldest maintained Linux distro. (And perhaps the very best distro! )
I discovered last nite that my Blue Yeti Microphone is not working in 14 RC 4, it was in 13.37 and 14 RC 1 & 2 - the Microphone shows up but is greyed out so it can not be selected. I'm sure this is simple, but simple escapes me most days : )
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
14.0 is still running beautifully here.
It also doesn't detect my modern double-speed USB floppy drive.
