Re: /etc/udev/rules.d and permissions in /dev/usb

On Tue, 10 Jan 2006, Darren Salt whispered secretively:
> I demand that Nix may or may not have written...
>
>> On Mon, 09 Jan 2006, Darren Salt mused:
>>> I demand that Nix may or may not have written...
>>>> On Fri, 06 Jan 2006, Darren Salt said:
>>>>> I demand that Nix may or may not have written...
>>>>>> It shouldn't do: the coldplugged devices are never unplugged, so the
>>>>>> kernel should never get a REMOVE event for them. [...]
>>>>> After a reboot, two ALSA devices got swapped and two DVD drives also got
>>>>> swapped. I'd been relying on the default order, which had previously
>>>>> been stable, and I don't recall any warning of instability.
>
>>>> The ordering of events is not guaranteed unless you enforce it, except
>>>> inasmuch as child events are guaranteed to be sent after parent events.
>
>>> Useful wrt USB, then...
>
>> For that, and also for things like making sure that partitions only appear
>> after the block devices they are part of.
>
> I was actually thinking about semi-modular kernels - everything required to
> get as far as "late" user-space built-in and various other things left as
> modules.

That's fine; the modules get autoprobed, although I haven't looked into
the mechanism much as I don't use modules at all. (The blog post of
Kay's I posted to earlier has more on that, I think.)

The udevsynthesize/uevent approach actually found a bug in the kernel
module loader; it triggers a massive storm of parallel module loads, and
there was a race in module initialization...

> [snip]
>> It's very, very neat, but the downside is that because the shell now
>> does the initial population, well, if you want ordering, you'll have to
>> call `sort' in udevsynthesize yourself.
>
> Problem: sort is in /usr/bin.

Yeah, you'd have to move it into /bin, or copy it into /lib/udev, or
something.

> OTOH, it looks like the shell is sorting glob
> expansions anyway,

Oh, yes; reading the bash manpage and POSIX I see that globs *are* sorted.
I never knew that. :)

> and I'll need to build and install 2.6.15 to avoid the
> binary 'udevsynthesize'.

Yep. The binary still works, but 2.6.15 don't *need* it anymore.

> [snip]
>>>> (This is why using %e is a bad idea: it's been removed from the
>>>> documentation and deprecated now, because it's such a bad idea to use it.
>>> If that's so then why was it ever added, replacing (for CDROM drives) a
>
>> It was there from the start of udev.
>
> Hmm. I'd not noticed that.

I only really noticed %e when it vanished :)

> [snip]
>>> Were 2.4.x being actively developed for newer hardware, rather than just
>>> maintained, right now I'd be considering going back to it - and, yes,
>>> using devfs.
>
>> You'd be shooting yourself in the foot, I think.
>
> What we really need is 2.7.x. :-)

Nah, 2.6.x seems to work well enough. The changes from 2.6.n to 2.6.n+1
are never so large as to cause me more than a few minutes' annoyance, and
those bugs that have bitten me have been fixed extremely fast ('cos the
developers are running nearly the same kernel as the users now :) )

>> udev is lovely once you get used to it, both elegant and astonishingly
>> powerful and flexible, and now the ugly corners are mostly filed off it
>> should be reasonably easy to avoid breaking userspace [...]
>
> init=/bin/sh (for emergency stuff, i.e. with a static /dev) looks like it'll
> be semi-broken, which isn't good at all.

Not hardly. I just kept my old static /dev around when I installed udev, so
init=/bin/sh works perfectly well; it just doesn't use udev.

(Eventually, when static device numbers go away, this will break too,
but I'd hope that initramfs gets up to speed and a default initramfs
that gets udev running and things is shipped with the kernel and built
into it... I expect that we'll always have *some* static device numbers,
anyway: you need /dev/zero just to run udevd, if it's dynamically linked.)

> I've occasionally used this to fix
> things up a bit when I've just done a reboot a little too early.

.... or when I've put off a reboot too long and that thing what was installed
three months ago turns out not to work and to have totally broken booting :/

(dependency-ordered init scripts make this problem mostly dissolve, though.)

>>>> I personally consider even using the kernel device numbering, %n, to be
>>>> somewhat risky; /dev/disks/by-* makes even that unnecessary now.)
>>> I took one look at it in use and promptly removed the symlink (restoring
>>> the previous state). /dev/hda is adequate, a lot easier to remember, and
>>> (given one IDE controller) nicely *static*.
>
>> That's only true as long as you don't have USB mass storage devices
>
> Not currently a problem, and it won't be a problem anyway unless hd* suddenly
> become sd* (which would be a bug).

Well, it's not a problem for you, but I've got SCSI disks...

>> Boot with one of them plugged in, and whoops, look, the kernel chose to
>> label *it* as `hda'...
>
> If it does, despite the IDE driver being built-in, that'd be a bug.

So you're relying on the USB driver being a module in order to avoid boot
failures? That's... not very robust.

>> (I'm not sure if the kernel will do this now, but it's quite within its
>> rights, and it *does* do this with SCSI devices. The way to fix this is to
>> use properties of the medium or the device as device naming
>> characteristics, which is what /dev/disk/ is for.)
>
> Why, when I'm building in what should be exactly enough to provide a useful
> system?

Because, um, it's nice to *not* have to hack at the system like mad when
you move disks around? I fitted a new disk last week and moved my old
/usr over onto it with dd. Total changes needed to /etc/fstab: *none*,
even though the block device /usr was on had changed. udev changed
/dev/disk/by-uuid appropriately, and that was that.

(Admittedly, if I'd been using LVM on that machine, device-mapper would have
spotted the move instead...)

> [snip]
>>>> The file which contains rules to generate the
>>>> /dev/disk/by-{id,label,path,uuid} stuff.
>
>>> Oh, *that* lump of ugliness...
>
>> s/ugliness/loveliness/
>
> No, ugliness. It's far too long-winded.

Personally, I like it for much the same reason that I like LVM's volume
naming: it's easier to remember. I can never remember which partition on
a non-LVMed disk something is on; all the names look the same and none
are descriptive: but /dev/disk/by-label/usr is nice and
easy. /dev/disk/by-uuid is useful for exactly the same reason that the
ability to name uuids in /etc/fstab is useful.

(/dev/disk/by-path and /dev/disk/by-id have more obscure use cases, but they
do exist.)

>> They're names for your *disk media* or *disk devices* which *never change*,
>> no matter how you might move your disks around. This is useful whenever you
>> add or remove disks,
>
> But not more useful for me, AFAICS. Therefore, why change?

You don't have to, but it allows stable device naming, which has been a
distant dream for Linux since basically forever, and an
urgent-must-be-solved problem since the first primitive hotplugging
infrastructure turned up in 2.4.

>> adds no overhead if you don't do that much,
>
> Adding labels is overhead. Not *much* overhead, but still more than what I
> would do now.

Um, what? It's a userspace program creating a half-dozen nodes with a
size approaching zero on a tmpfs filesystem. The time taken by udevd to
parse the rules for things they don't match is pretty much zero: it stores
a compiled representation of them.

(So yes, I suppose you're losing perhaps 300 bytes of swappable memory
in udevd to the persistenct-device-naming rules. How simply awful.)

>> and should eventually enable the removal of stuff like by-label and by-uuid
>> mounting from mount entirely (it has never really belonged there IMNSHO;
>> it's not mount's job to parse the insides of filesystems, just to ask the
>> kernel to mount them).
>
> Oh good. Back to hda, then :-)

Um, nobody's making hda go away. I don't know why you're reading all
this we-hate-the-existing-device-tree stuff into udev. Note that the
devfs udev rules that really rearrange /dev are *deprecated*...

--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
.

Relevant Pages

  • Re: Re: "Waiting for root file system..." hang solved
    ... bug, a kernel package bug, a udev bug, or operator error. ... you upgraded the kernel and the new kernel ... Just installed Etch but on first boot after installation I got the "Waiting for root file system..." ... kernel modules are loaded before udev daemon is started though...... ...
    (Debian-User)
  • Kernel panic with geom_multipath + ZFS
    ... I'm under the illusion that I've found a bug in the FreeBSD kernel, ... has 12 disks, totalling at 60 disks. ... ejecting one of the disks causes a kernel panic. ... confirm this is a bug?" ...
    (freebsd-stable)
  • RE: could not find filesystem /dev/root
    ... stock vanilla kernel: FC5 is heavily relying on modules, ... kernel was compiled with everything built-in and no modules. ... This is definitely changing the order in which drivers and disks are ... though people will tell you that udev is supposed ...
    (Linux-Kernel)
  • Re: Optical Dell Mouse - seems standard doesnt work on xorg
    ... Thomas Douillard wrote: ... I don't know who I must blame (hal, udev, the ... looks like a kernel ... an kernel and if that works, report a bug. ...
    (Debian-User)
  • Re: Creating /dev/md* device files
    ... > devices made with mknod don't survive a reboot!?! ... > research udev and find out how to get md devices to consistantly show up. ... using initrd and modules other than recompiling the kernel, ... Well you found the same bug I found doing it that way. ...
    (Debian-User)