linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* udev - udev_config.c:get_dirs() is too forgiving
@ 2004-03-08  6:55 Martin Schwenke
  2004-03-08  9:02 ` Marco d'Itri
  2004-03-09  4:59 ` Martin Schwenke
  0 siblings, 2 replies; 3+ messages in thread
From: Martin Schwenke @ 2004-03-08  6:55 UTC (permalink / raw)
  To: linux-hotplug

While trying to get udev running on a ramdisk on /dev, on my Debian
unstable system, I came across the problem that
udev_config.c:get_dirs() doesn't care if it doesn't know where sysfs
is mounted, so later on udev tries to process absolute paths like
"/block/hda" and spends a lot of time sleeping when various files
don't exist in those directories (causing me to power cycle and boot
from a rescue disk...  or try and get a good night's sleep :-).

This happens when you're in early boot and /proc isn't yet mounted, so
sysfs_get_mnt_path can't find /proc/mounts.  I'd post a patch but
there are several possible "solutions":

1. Patch udev_config.c:get_dirs() to fail loudly (to stderr and syslog)
   and exit if it can't find where sysfs is mounted.

   At the moment it logs, but that doesn't help if you're not running
   syslogd.  Even if you could start syslogd, you don't have a console
   device to log to and the timeouts take so long that you're never
   going to wait around to see the logs anyway...

2. Document the fact that you really need /proc (in very large
   letters).  This would appear to be a minimum, although if (1) is
   done you only need to see it happen once, and then it has
   documented itself...

3. Change start_udev (and probably the regular initscripts) to mount
   /proc if necessary (and probably umount it when finished - the
   insanity that /etc/mtab needs to contain /proc needs to be
   reinforced, even though that means waiting until after / is no
   longer read-only on many systems).

   Note that this solution (which is the one I chose and also seems to
   have been chosen by the udev Debian maintainer) is insane.  If you
   umount /proc after doing the udev initialisation, you risk a new
   device appearing between this time and the time when /proc is
   really mounted - then udev goes into its 10 second trance and you
   don't get your device node.

   Is there a *valid* argument that says no devices can appear during
   this time?

   Maybe this will end up being the straw that breaks the camel's back
   and causes /proc/mounts to finally be made a symlinkable
   replacement for /etc/mtab?

   I'm not sure this can be fixed nicely.  A not-very-nice option is
   to have an initscript that walks through /proc/mounts finding
   things that aren't in /etc/mtab (with exceptions) and doing a
   "mount -f ..." on each of them.

Hmmm...

peace & happiness,
martin



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: udev - udev_config.c:get_dirs() is too forgiving
  2004-03-08  6:55 udev - udev_config.c:get_dirs() is too forgiving Martin Schwenke
@ 2004-03-08  9:02 ` Marco d'Itri
  2004-03-09  4:59 ` Martin Schwenke
  1 sibling, 0 replies; 3+ messages in thread
From: Marco d'Itri @ 2004-03-08  9:02 UTC (permalink / raw)
  To: linux-hotplug

On Mar 08, Martin Schwenke <martin@meltin.net> wrote:

 >   Note that this solution (which is the one I chose and also seems to
 >   have been chosen by the udev Debian maintainer) is insane.  If you
 >   umount /proc after doing the udev initialisation, you risk a new
 >   device appearing between this time and the time when /proc is
 >   really mounted - then udev goes into its 10 second trance and you
 >   don't get your device node.
The real solution is move the init script which mounts /proc and sysfs
before the one which runs udevstart, as it was discussed on debian-devel.
I'm waiting for the initscripts maintainer to do this.

-- 
ciao, |
Marco | [4969 prd9fTVnpXASs]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: udev - udev_config.c:get_dirs() is too forgiving
  2004-03-08  6:55 udev - udev_config.c:get_dirs() is too forgiving Martin Schwenke
  2004-03-08  9:02 ` Marco d'Itri
@ 2004-03-09  4:59 ` Martin Schwenke
  1 sibling, 0 replies; 3+ messages in thread
From: Martin Schwenke @ 2004-03-09  4:59 UTC (permalink / raw)
  To: linux-hotplug

[I'm tempted to not reply to list, but since there are going to be
 a bunch of people trying to figure out how to use udev for /dev,
 replies should probably stay here.]

>>>>> "Marco" = Marco d'Itri <md@Linux.IT> writes:

    Marco> The real solution is move the init script which mounts
    Marco> /proc and sysfs before the one which runs udevstart, as it
    Marco> was discussed on debian-devel.  I'm waiting for the
    Marco> initscripts maintainer to do this.

I've trawled the debian-devel mailing list archives (since I'm not
subscribed) trying to find the thread that you're talking about.  Now
that I've found it, it appears the solution only addresses part of the
problem.

One reason that people have been doing the (mount, use, umount)
shenanigans for things like /proc is they are conventionally listed in
/etc/mtab, which is not on a writable filesystem until fsck is run and
/ is remounted read-write.

Is this convention going to change, or will there be a later script
that fakes the mounts using "mount -f", so they are written to
/etc/mtab?

Thanks...

peace & happiness,
martin



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-03-09  4:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-08  6:55 udev - udev_config.c:get_dirs() is too forgiving Martin Schwenke
2004-03-08  9:02 ` Marco d'Itri
2004-03-09  4:59 ` Martin Schwenke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).