LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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 09-04-2012, 08:41 PM   #76
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 858

Rep: Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668

Quote:
Originally Posted by Woodsman View Post
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.
 
Old 09-04-2012, 08:47 PM   #77
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,025

Rep: Reputation: 966Reputation: 966Reputation: 966Reputation: 966Reputation: 966Reputation: 966Reputation: 966Reputation: 966
Quote:
Originally Posted by Woodsman View Post
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.
 
Old 09-04-2012, 08:57 PM   #78
WoefulNarvik
LQ Newbie
 
Registered: Apr 2012
Distribution: Slackware, Salix
Posts: 18

Rep: Reputation: Disabled
New updates to current are now available.

ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt
 
Old 09-04-2012, 09:10 PM   #79
Mobile1
Member
 
Registered: Jun 2006
Location: Abbotsford, B.C.
Distribution: Slackware64 14.1
Posts: 102

Rep: Reputation: 6
Not all mirrors are updated yet...but soon and very soon : )
 
Old 09-04-2012, 11:46 PM   #80
kingbeowulf
Member
 
Registered: Oct 2003
Location: WA
Distribution: Slackware64 14.1, Slackware 14.1
Posts: 519

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

There is good blogpost about it - Udisks2: Another Loss For Linux
Starting to look like a case for the need for Adult Supervision...
 
Old 09-05-2012, 12:20 AM   #81
caduqued
Member
 
Registered: Apr 2008
Location: Coventry, United Kingdom
Distribution: Slackware64, Slackware64 13.37, linuxslackware
Posts: 81

Rep: Reputation: 19
Yep, almost there....

Quote:

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.
+--------------------------+
 
Old 09-05-2012, 12:40 AM   #82
sorinm
Member
 
Registered: Jul 2012
Location: RO
Distribution: Slackware64-14.0
Posts: 65

Original Poster
Rep: Reputation: Disabled
Well well... :d aaa_elflibs was rebuilt, this means only one thing, 2 or 3 days untill 14.0 will be released.

Last edited by sorinm; 09-05-2012 at 12:44 AM.
 
Old 09-05-2012, 12:59 AM   #83
sorinm
Member
 
Registered: Jul 2012
Location: RO
Distribution: Slackware64-14.0
Posts: 65

Original Poster
Rep: Reputation: Disabled
If you are running -current , upgrade aaa_elflibs too because in the future you won`t be able since some packages will get upgraded or patched.
 
Old 09-05-2012, 01:02 AM   #84
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,476

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
Hi Pat,

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 hope this helps!
 
Old 09-05-2012, 01:50 AM   #85
damgar
Senior Member
 
Registered: Sep 2009
Location: dallas, tx
Distribution: Slackware - current multilib/gsb Arch
Posts: 1,949
Blog Entries: 8

Rep: Reputation: 201Reputation: 201Reputation: 201
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
 
Old 09-05-2012, 04:08 AM   #86
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
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.
 
Old 09-05-2012, 04:48 AM   #87
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 800

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by damgar View Post
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.
 
Old 09-05-2012, 04:48 AM   #88
jaycee4
Member
 
Registered: Aug 2009
Posts: 42

Rep: Reputation: 7
Quote:
Originally Posted by D1ver View Post
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! )
 
Old 09-05-2012, 05:24 AM   #89
jjthomas
Member
 
Registered: Jan 2004
Location: Tacoma, WA
Distribution: Slackware 14
Posts: 242
Blog Entries: 2

Rep: Reputation: 28
Quote:
Originally Posted by jaycee4 View Post
...And perhaps the very best distro!
Perhaps?

-JJ
 
Old 09-05-2012, 08:48 AM   #90
Mobile1
Member
 
Registered: Jun 2006
Location: Abbotsford, B.C.
Distribution: Slackware64 14.1
Posts: 102

Rep: Reputation: 6
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 : )

Any ideas?
 
  


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
rc4 kernel module azza Programming 1 06-28-2009 03:25 PM
INIT 4(rc4.d) guruvayur Linux - General 1 01-27-2009 04:39 AM
no modem slack 10.2, 2.6.16-rc4 teamjt Linux - Laptop and Netbook 1 02-28-2006 09:45 AM
AES vs RC4 vs TKIP jspsandhu Linux - Security 4 07-19-2005 08:50 AM
RC4 encryption koningshoed Linux - Security 4 01-27-2003 04:00 PM


All times are GMT -5. The time now is 10:51 PM.

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