udev [ -f /dev/.udev.tdb ] test

Nathan Coulson conathan at gmail.com
Thu Sep 23 22:17:56 PDT 2004

On Thu, 23 Sep 2004 21:30:09 -0700, Kevin P. Fleming
<kpfleming at linuxfromscratch.org> wrote:
> Nathan Coulson wrote:
> > [ -f /dev/.udev.tdb ]  && exit 0
> >
> > It means, if /dev is writeable before udev, and something causes a
> > hotplug event [on a system with /sbin/hotplug].
> This is true.
> > Mostly the people working on the bootcd's have noticed this.  (BTW,
> > there's a sed on the kernel page to prevent hotpug from running until
> > userspace is ready for it)
> That is correct, but many people (myself included) forget to reapply it
> after putting in kernel upgrades.
> > If people want it to stay, I am going to have it output a warning
> > message saying devices have already been initialized.
> For my systems, I have moved to a different initialization technique
> that doesn't have any trouble with this... It's just safer at this point
> (IMO) to throw away any /dev directory contents that got created prior
> to the initscripts running and recreate them, rather than try to get it
> right and just leave /dev alone.
> Personally, I think Alexander's method of storing up early-userspace
> hotplug events until the system is ready to process them is a good idea;
> I can't see any system that builds /dev in an initrd/initramfs and then
> moves it into the "real" root filesystem being very manageable, because
> it means any changes that the admin makes in
> /etc/udev/{rules,permissions}.d have to be mirrored into that
> initrd/initramfs, which is a pain in the butt to do.

I believe a initramfs to setup the environment before calling init
would be a great idea...  but I doubt we would want to move to that at
this time.  (by we, I mean the LFS editors who work on the book. 
Afaik, I dont make those decisions)

So, you'd rather get rid of the check, and always setup a fresh /dev
directory, with a initramfs as a long term solution?

Nathan Coulson (conathan)
nathan at linuxfromscratch org
conathan at gmail com

More information about the lfs-dev mailing list