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

I demand that Nix may or may not have written...

> 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...
[snip]
>>>>> 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.)

I suppose that I'll have to have a look sometime...

> 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]
>>>>> (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 :)

I noticed it when cdsymlinks was removed.

>> [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 :) )

That's the big advantage, yes. It's just that 6 is odd these days :-)

>>> 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.

ATM, yes.

> (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...

This does need consistent default device naming across reboots (modulo system
reconfiguration), of course, for emergency stuff, lest anybody get carried
away with making everything dynamic.

> 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.)

Hmm...

>> 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 :/

That sounds a lot like what happens here ;-)

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

Hmm. I'm still using sysvinit. (Well, it works, or at least it did at the
last reboot.)

>>>>> 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...

Hmm. I'd arrange module loading to avoid problems there too (and I do have
one spare machine which normally boots from SCSI disk).

>>> 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. You mentioned parallel-port IDE, and I don't use that.

>>> (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?

That'd happen anyway :-)

> 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.

Here, I'd attach a disk as slave on the primary IDE channel, copy across,
remove the original HD, make the new disk master, boot from CD (or something)
*then* create the boot block. (Or I'd play with lilo's configuration to get
it to write to hdb with the intent of booting from it as hda.)

I don't see any advantage there in /dev/disk/by-hieroglyph.

> (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.

Examination of /etc/fstab or the output of mount tells me enough, and I tend
to keep similar partitioning arrangements across machines.

[snip]
>>> 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, [...]

So did what I had prior to some upgrade prior to the last reboot of the
affected machine and still do for hd*. Now, for USB mass storage and similar
things, *yes*, use IDs and the like...

>>> 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. [...]

It's rememering to do this at filesystem creation time, or taking the system
down to add them later. (I've not bothered to do either.)

>>> 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.

libata and friends replacing the "old" IDE drivers? Or is there some option
that I've missed...

> I don't know why you're reading all this we-hate-the-existing-device-tree
> stuff into udev.

It's "we hate enumeration because it is broken" when it's been *working*
properly here. It's "let's break enumeration (even more) by doing things in
parallel" when doing things in series provided useful event ordering. (Or at
least that's what it looks like from here.)

Don't say "but adding devices could cause renaming". If I add a CD-ROM drive
at hdb, I would exZappect hdc to become cdrom1. But I didn't expect some
device names possibly being swapped after a reboot...

> Note that the devfs udev rules that really rearrange /dev are
> *deprecated*...

That /dev/disk/* stuff reminded me of devfs.

--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian, | s zap,tartarus,org | Northumberland
| RISC OS | @ | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Ingres is not a necessary precursor to Egress.
.

Relevant Pages

  • Re: SBS Server crash Unexpected - Error ID 6008
    ... If so, start in Safe Mode, delete all page files and reboot, then recreate your pagefile and reboot one more time ... Hard ware vendor has check hardware log, Raid Controller Log, but no hardware ... Loading Kernel Symbols ... in paging file or disk controller error. ...
    (microsoft.public.windows.server.sbs)
  • Re: /etc/udev/rules.d and permissions in /dev/usb
    ... >> udev running and things is shipped with the kernel and built into it... ... >> I fitted a new disk last week and moved my old /usr over onto it with dd. ... LVM partition names. ...
    (uk.comp.os.linux)
  • Re: New Lenny to Squeeze install problems on ASUS eee
    ... Your computer has to be running the more current kernel before udev ... Because you are installing the kernel in the same run you can force udev to accept the upgrade by creating a specific file. ... Start dist-upgrade (aptitude full-upgrade) ... Reboot into the new kernel, ...
    (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)
  • Re: Hibernate a single process (aka checkpointing)
    ... > writes the entire contents of RAM to disk, ... > such a way that it can be continued later, even if I reboot in between ... The problem is the kernel keeps information about the process as ...
    (comp.os.linux.development.apps)