I'm hoping to find some guidance on switching a Slack 9.1 system to udev-021. I compiled, installed, and can boot into a udev managed state, but the default permissions that udev uses tend to break things. Another odd thing is that I cannot launch Xterm's or Rxvt under udev management. I've set udev.permissions to set /dev/tty and /dev/ptmx to 0660 and root:tty to mirror the static /dev, and udev is setting the permissions, but the vt's still can hook into the pseudo terminal. I've tried manually chmod'ing those 2 dev's to 0777 and still can't launch, even as root.

So I'm looking for tips at this point. I saw the well written site that someone else posted (I don't have enough posts to post a URL, I just searched for udev) and that is a good explanation on setting up dev rules, but I guess I'm looking for which manual to RTFM on basic /dev permissions.

This last bit really blows my mind. Gxmame can find executables as root, but not as a user. I can launch xmame(.x11/xgl) just fine as either, and there is no other problem I can find so far. Ugh. At least rolling back to a static dev was as easy as not launch udev at boot.

Thanks, and any advice would be appreciated.

I don't remember the URL, but there's a good howto out there from Decibel...

my best suggestions would be check the gentoo forums (forums.gentoo.org), which have a ton of good info.... other than the parts that mention emerge, most things are not distro-specific, since gentoo is a source distribution.

the link to Decibel's howto is all over the gentoo forums also.

btw, i'm a happy gentoo & udev user

Hollywoodb:

Thanks for the tips. I'd probably give Gentoo a go but I'm still a data leper. (dial-up).

I'll start searching in there. Ya know, seeing as I've seen gentoo mentioned in Greg K-H's stuff, you'd think I would have thought of looking there. Oh well, thanks for the reply!

Well, I'm limping along under udev, but I'm further then what I was. I'm going to post what I've got notes-wise in case anyone else is reading this thread. I'd appreciate any feed back. Right now I've got xterms working and am trying to figure out what netscape is complaining about. Mozilla is fine.... sigh. Oh well, it's a learning process. Hope this helps someone.



Process to get udev working on Slack 9.1

1) Acquire the udev packages.

2) Unpack the udev source ball, make and install

3) Copy the start_udev file to /etc/rc.d

4) Edit start_udev so that it does not call an
explicit exit at the end of the script. This
seems to short circuit the calling script.

5) Edit rc.S -- Comment out the devfs section
-- add nodevpts to the mounting of
local filesystems. (i.e. nosmbfs, nonfs, nodevpts)
-- Add the call to start_udev directly below
the mount command
-- Add the command to mount devpts

6) Edit /etc/udev.permissions and udev.rules accordingly.

NOTE: Under udev, I've found that my users *must* be a member of the
group that owns /dev/tty and /dev/ptmx. This wasn't the case with
a static /dev. I'm not sure why this is, but I know that all xterm-
like applications will not launch without it. They will complain
either about missing files, or that there are not enough pty's.
Also, be sure to put sane permissions on /dev/null, /dev/zero,
/dev/urandom. Otherwise, quite a few system shell scripts will
fail/complain. Some programs will show some very odd behavior as
well (e.g. gxmame cannot find a valid xmame excutable.) Of course, for
most, that'd be common sense, but I can overlook things like that.

Thanks for the posts, SmokingPenguin, they are helping!

I, too, am having problems with udev...
I upgraded to kernel 2.6 and installed a udev version from backports.org - 0.09, I believe it was. It worked great, until I upgraded to the latest version in debian/testing (0.21, I think)

Now, I can't access terminals (Konsole fails with "unable to open suitable terminal").
I have no cdrom devices in my /dev tree - k3b detects no devices.
OSS output (ALSA emulation) has stopped working in XMMS. ALSA still works, but I was using OSS to workaround a pausing error.

I'm in the process of doing all the RTFM I can, but I'm having trouble beginning. Any help is appreciated!

--Rounan

Rounan:

I just double-checked, and my konsole launches. As I posted in my notes, I have to give my users explicit permission to use /dev/tty and /dev/ptmx via having them in a group that owns those devices. (i.e. root, my account, etc are all members of group tty, which owns the devices.) Even if I set /dev/tty and /dev/ptmx to 777, xterm would still bomb out with a "too few pty's" error. Right now I am noting what rules I need to put into udev.rules so that my sound is user accessable from boot. It looks like the process will take some time to get udev.rules and udev.permissions tweaked properly. Heh, most likely about the time I am done tweaking, my distro will provide an out of the box one. Oh well, I've learned a little bit about psuedo-terminals through this... and I definately want to dig into the hotplug tools further.

Never ends.... I like it that way though. No stagnation, always new stuff to play with and break. Like the hour I just put into loading the ATI 3.7.6 Drivers. removepkg wasn't able to completely clean out the 3.2.8 module, and 3.7.6 wouldn't make another due to a fglrx.ko being present.... sigh.

I have sound accessible from user- group audio and 666 permissions.

For ttys, I have them owned by group tty, and my user is in the tty group, 666 permissions. Do I need 777? (at work so I can't try X-based tweaks)

Why would udev fail to populate my CDrom drives? At present, there are NO devices in /dev or /udev associated with my cdrom drives.
Any ideas?

--Rounan

Rounan:

I'm at work right now as well, but I'll check my udev configuration files for anything that I've forgotten to mention.

On the CD issue, are you getting any /dev/hdx's that would point to the drives? Are you using ide-scsi emulation? If you are then check for /dev/scd#'s and any odd /dev/sg#'s. I am getting a /dev/cdrom sym link, but my first cd is /dev/hdc, which is setup in udev.rules to be symlinked to /dev/cdrom. This is the default from the udev-21 package.

I remember that my /dev/pts directory is set as 0655 root:root I believe, which seemed to be the default. Also, I have the devpts filesystem mounting *after* udev mounts. I did this by adding nodevpts to the mount command in my startup scripts that mounts the local filesystems (/proc, /, etc.) Then I load the start_udev script, then issue the mount devpts command.

When I get home, I'll post some of my config files for you. Maybe we can both figure out what the heck is really happening here.

Good Luck!

Heh. Just tried to SSH into the box, and of course since I can't open ttys, I can't get a remote shell. Blast...

My two IDE HDs are correctly identified as hda and hdb, and all partitions are detected. they appear in /dev as hda, hda1... etc, and these are symlinks to their locations in the /dev/ide directory. But this directory has only 1 bus, 2 targets - I'm probably remembering that wrong. point is, there's no evidence that my second IDE channel exists.

I'm not using scsi emulation, and there are no scsi devices in my /dev.

Do I need to setup my hdc/hdd in udev.rules? How would I go about this? the udev.rules and udev.permissions lack man pages.

I remember compiling in /dev/pts support, and I have a /dev/pts directory, but it's empty. What IS /dev/pts?

I wish I could SSH in so I could check my config scripts... will post on that later.

--Rounan

From what I've found, /dev/pts is where the dynamicly generated psuedo-terminals get created. The controlling device is /dev/ptmx. I can't recall offhand, but I believe the kernel help for the devpts filesystem is where I found the description of this setup. I'll do some digging and post any info I find. I think I'm allowed to post URL's now, so that should help.

If the second ide chain isn't showing up, are you loading the correct ide driver for your chipset? You could try looking at dmesg and the log files to see what it is that the kernel *thinks* it's seeing. I was having problems with my nforce2 board, until I saw that if you enable generic ide support, the kernel will always use that instead of the proper, full-featured driver. What tipped me off to this was that I couldn't set DMA on with hdparm on either my CD-RW or my DVD+RW. I'm not sure if any other chipset drivers have this issue, but the viper/nforce driver certainly does.

Of course, since I'm using a SATA HDD on a promise controller, the damn thing shows up as a SCSI drive anyway, so that might be what kept me from having the same problem you are right now. Promise controller was a pain, thankfully it's now fully supported internally in the 2.6.X kernels.

Aha. So /dev/pts is probably the root of my problems. I see... So what would having an empty /dev/pts mean? I know I have the line in my fstab... have to RTFM all I can, I suppose.

I know my IDE drivers are OK, since they were working beautifully with the older version of udev. I have the PIIX driver support compiled into my kernel, and both my HDDs are using udma5. weirdness...

Wierdness is a perfect summation

The reason that /dev/pts would be empty is that there are no pseudo terminals created until an application calls for one, i.e. xterm. Right after I boot, my /dev/pts is empty as well. If I open a xterm, /dev/pts/0 is created. Open another, /dev/pts/1, and so forth. What got me is, it looked like xterm was trying to deal with /dev/ptmx, but rxvt was dealing with /dev/tty. This might just be me misreading the error messages, however.

In either case, the actual psuedo terminals will be created and removed dynamically under the devpts filesystem. Maybe this has more to do with mount the udev controlled /dev then the devpts filesystem then permissions do. I'll experiment a little bit tongiht and let you know.

I did some experimenting and this is what I found regarding the psuedo terminals.

The initial problem that I had (where I couldn't launch an xterm no matter what ownership or permissions I gave /dev/pts, /dev/ptmx, and /dev/tty) were due to loading the devpts filesystem before udev mounted its ramfs based /dev. /dev/pts appeared to be there, with proper permission, but would not allow creation of any psuedo-terminials. I tried reverting the permissions on /dev/ptmx and /dev/tty to 0600 root:root, and loading devpts after mounting udev, and root *was* able to load xterms. All other users could not. I rebooted, and allowed udev to assign the rights of 0660 root:tty to ptmx and tty. I tried my normal user account, and could launch an xterm. I removed the user from the tty group, and could not launch xterm. I then tried permissions of 0666 on ptmx and tty, and was able to launch as a world user.

Therefore, it appears the first real issue is to make sure that the devpts filesystem is mounted AFTER udev mounts its /dev, and then normal permission rules apply to accessing the master (/dev/ptmx and /dev/tty) devices to create the slave psuedo terms. The permissions I have on the /dev/pts directory are 0620 root:root. It appears that since the master devices are owned as root, they are allowed to create the slave devices in /dev/pts/ without any problems.

Here's a snippet of my rc.S file that does the mounting.
<snip>
# mount non-root file systems in fstab (but not NFS or SMB
# because TCP/IP is not yet configured):
### NOTE: This is where /proc & /sys mount, so ...
### Also seems that I'd want to mount devpts after /dev is mounted
/sbin/mount -a -v -t nonfs,nosmbfs,nodevpts

### NOTE: Here's where we want to load udev.
. /etc/rc.d/start_udev # name of the file is from the udev source
### Now mount devpts...
/sbin/mount devpts
<snip>

Also, here's my fstab lines for devpts and sysfs:
devpts /dev/pts devpts gid=5,mode=620 0 0
sys /sys sysfs defaults 0 0

I've noticed that udev seems to be appling the default permissions of 0655 root:root to /dev/pts, and ignoring my fstab options. However, everything works, so I will take my time figuring out the why on that one.

Also I should note that a sysadmin could save a step by giving the users group ownership of /dev/ptmx and /dev/tty, but hey, the default in Slack has them owned by tty, and I figure Patrick probably has a very good reason for it. Maybe I'll figure that out too someday.

Let me know if this new info helps any.

I followed the udev migration instructions at:
http://wiki.archlinux.org/index.php/UdevHowTo

I copied his 00-myrules.permissons file, and followed all his instructions, and I still had the same problem after a few days uptime. When I rebooted, everything was fine. I just rebooted about an hour ago with the hotplug daemon running (which was mentioned in decibel's howto). I've noticed now that in /dev/pts/ when I open a terminal, it creates a new number; when I close a terminal, it disappears.

It remains to be seen if this works. I might go opening terminals like mad to see if they start bombing out.

Oh, I also created a group tty, and did all the chowning and chmoding to make my user part of tty and make tty own /dev/tty. That may have helped too.

Anyway, my $0.02

Sorry that I didn't read the whole thread, but an easy way of getting udev is:

1) Upgrade to Slackware 10.0
2) Download, compile, and install custom 2.6.x kernel
3) Reboot, udev will automatically load

Voila ^_^

Slack 10 includes udev and sane default rules that 'just work' for me.

Edit: Just installing the udev and sysvinit packages that come with Slackware 10 my be enough (or even just udev if you modifiy the init scripts yourself).