Re: udev and /dev/sda1 not found during boot (it's there right afterboot)

[Erik Steffl]

Greg KH wrote:
> On Sun, May 23, 2004 at 08:56:43AM -0700, Erik Steffl wrote:
>
> > Greg KH wrote:
> >
> > > On Sat, Apr 24, 2004 at 12:37:41AM -0700, Erik Steffl wrote:
> > >
> > >
> > > > just moved to udev and everything seems to be working OK except of 
> > > > SATA drive (visible as /dev/sda1) when fsck checks it during boot (it 
> > > > works fine right after that).
> > >
> > >
> > > This is a Debian specific bug/issue.  I suggest you file it against the
> > > Debian udev package, as it is not a kernel issue.
> >
> >  why would you think it's debian specific issue?
>
> Because it doesn't happen on my Gentoo or Red Hat based systems? :)

  I was hoping for something that would shed some light on _why_ this 
happens on my (debian) system. The fact that it doesn't happen on your 
systems that happen to be non-debian doesn't mean much... because I 
don't see anything debian specific in debian package (which is the same 
thing debian maintainer wrote, see link below).

> >  btw if I add sleep at the beginning of /etc/init.d/checkfs.sh (runs 
> > fsck for all filesystems) everythings works. Which I guess confirms that 
> > there is some delay between when the module is loaded and when the 
> > device is available in userspace. Is that how udev works? How can this 
> > issue be solved?
>
>
> As you point out, this is all in how udev is handled by the boot
> scripts, if they wait long enough for the device node to show up before
> continuing on or not.  Thereby showing that this is a distro specific
> issue.

  the udev is started (before the modules are loaded and certainly 
before the attempt to fsck), how's that different from any other system? 
what 'handling' are you talking about?

here are relevant startup scripts in /etc/rcS.d on my machine:

S04udev -> ../init.d/udev
S20modutils -> ../init.d/modutils
S30checkfs.sh -> ../init.d/checkfs.sh

> Now the Debian maintainer of udev has said that you should also read the
> README file for udev for more information about this type of issue.  I

  said to whom? not to me, he responded to my previous email saying 
that he cannot see how it would be debian specific issue and that it 
makes no sense to open debian bug report, see previous emails in this 
thread, here' random google URL for his post:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0404.3/0054.html

> suggest you go through the Debian bug reporting process for further
> help.

  it looks like the problem is that after the modprobe is done the 
device is still not available. that _seems_ like a serious problem of 
udev. Maybe I am missing something but after the modprobe is done and 
reports success the device should be available, ortherwise the programs 
have no way to find out what's going on. Adding random sleeps (for how 
long?) doesn't seem like a solution.

	erik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/