Hi
On 9/25/09, Brendan Moran <bremoran@xxxxxxxxxxxx> wrote:
> Hi,
> I'm trying to migrate an armeb embedded Linux build from a static /dev
> to udev. I now have the system coming up with udev enabled, but the
> first thing that udev does is disable my console connection. Before the
> console starts endlessly spewing "file not found" messages,
Ow. Often that means you've either deleted or removed access
permissions to /dev/null. Maybe the same has happened to /dev/tty or
something as well. It suggests that your rules are failing to assign
permissions to these devices, so udev is giving them default
permissions which are too restrictive.
> udev prints
> a line like this
>
> tty ttyAMA0: uevent: unsupported action-string; this will be ignored
> in a futur
>
> for nearly every device that was in the previous static /dev.
Aha. That's a kernel message, not a udev one. It suggests you're doing this:
udevadm trigger --action=uevent
when you should be doing this:
udevadm trigger --action=add
("udevadm trigger" should also work since --action=add is the default).
> I understand that I can add static rules to udev to fix this, but I also
> want to migrate naming conventions to standard names--ttyAMA0 should be
> ttyS0, etc. I can keep legacy names around with symlinks if necessary.
I suspect this is not relevant to your problems. Udev doesn't delete
the previous contents of /dev. There should only be problems if the
names conflict, so that udev overwrites one of your existing nodes
with something you're not expecting.
(Btw, in case you're not already doing this, the README recommends you
mount /dev as a tmpfs and initialize it by copying all your static
devices from /lib/udev/devices).
> So I'm not quite sure how to get started. I have disabled udev's
> startup for the moment, so I can get into /sys. Is there a guide
> somewhere on how to migrate from a static /dev to udev?
>
> Thanks,
> Brendan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
