* udev and /dev/sda1 not found during boot (it's there right after boot)
@ 2004-04-24 7:37 Erik Steffl
2004-04-24 15:55 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Erik Steffl @ 2004-04-24 7:37 UTC (permalink / raw
To: linux-kernel
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).
all the required modules (as far as I can tell) are in /etc/modules.
I see the modules loading and right after the modules are loaded fsck
starts. It checks /dev/hdb6 (root) and it goes on to check /dev/sda1 and
complains that there is no such file. At that point I get a choice to
enter root password for maintenance or ctrl-d to continue booting.
enter root password: I get command prompt, check the /dev/sda1, it's
there, I can do fsck or mount it
ctrl-d: boot continues as usual, /dev/sda1 is mounted
any ideas how to fix this? is it a timing issue (udev didn't create
device yet but fsck is already trying to use it)?
system:
debian unstable
kernel 2.6.5
udev 0.024
/etc/modules:
ip_tables
# -------------- scsi
sd_mod
sr_mod
ide-scsi
sg
scsi_transport_spi
# -------------- cdrom
ide-cd
# -------------- alsa
snd_emu10k1
TIA
erik
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-04-24 7:37 udev and /dev/sda1 not found during boot (it's there right after boot) Erik Steffl
@ 2004-04-24 15:55 ` Greg KH
2004-04-24 20:32 ` Marco d'Itri
2004-05-23 15:56 ` Erik Steffl
0 siblings, 2 replies; 7+ messages in thread
From: Greg KH @ 2004-04-24 15:55 UTC (permalink / raw
To: Erik Steffl; +Cc: linux-kernel
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.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-04-24 15:55 ` Greg KH
@ 2004-04-24 20:32 ` Marco d'Itri
2004-05-23 15:56 ` Erik Steffl
1 sibling, 0 replies; 7+ messages in thread
From: Marco d'Itri @ 2004-04-24 20:32 UTC (permalink / raw
To: Greg KH; +Cc: Erik Steffl, linux-kernel
On Apr 24, Greg KH <greg@kroah.com> 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.
What makes you think this is debian-specific? As you know, the debian
package does not have relevant patches.
I have not been able to reproduce this and I have no clue about how this
could be debugged, so I don't think that opening other duplicated bug
reports is going to help much...
--
ciao, |
Marco | [5950 alBoT3GxM9NbE]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-04-24 15:55 ` Greg KH
2004-04-24 20:32 ` Marco d'Itri
@ 2004-05-23 15:56 ` Erik Steffl
2004-05-23 16:25 ` Greg KH
1 sibling, 1 reply; 7+ messages in thread
From: Erik Steffl @ 2004-05-23 15:56 UTC (permalink / raw
To: Greg KH; +Cc: linux-kernel
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?
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?
kernel 2.6.5, udev 0.024, debian unstable
erik
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-05-23 15:56 ` Erik Steffl
@ 2004-05-23 16:25 ` Greg KH
2004-05-24 3:29 ` Erik Steffl
0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2004-05-23 16:25 UTC (permalink / raw
To: Erik Steffl; +Cc: linux-kernel
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? :)
> 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.
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
suggest you go through the Debian bug reporting process for further
help.
Good luck,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-05-23 16:25 ` Greg KH
@ 2004-05-24 3:29 ` Erik Steffl
2004-05-24 4:58 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Erik Steffl @ 2004-05-24 3:29 UTC (permalink / raw
To: linux-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev and /dev/sda1 not found during boot (it's there right after boot)
2004-05-24 3:29 ` Erik Steffl
@ 2004-05-24 4:58 ` Greg KH
0 siblings, 0 replies; 7+ messages in thread
From: Greg KH @ 2004-05-24 4:58 UTC (permalink / raw
To: Erik Steffl; +Cc: linux-kernel
On Sun, May 23, 2004 at 08:29:26PM -0700, Erik Steffl wrote:
> 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).
It's all up to the init scripts, which are _very_ distro specific.
> 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.
No, it's not a serious problem. The device will show up soon, but it's
not available _right_ after modprobe returns. A lot of async events
need to happen before the node shows up. That is the main change a lot
of different init scripts in distros have had to accommodate (alsa is
one specific example of this.)
> Maybe I am missing something but after the modprobe is done and
> reports success
Wait, how does modprobe report success? All it can return is if the
module loaded or not. Not if a device actually was bound to that driver
or not (see the thread on lkml a week or so ago about how you can
determine this if you really want to.)
Lots of stuff happens in the kernel after modprobe returns successfully,
and for some kinds of drivers the device is not set up until a
measurable amount of time afterwards.
> 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.
Don't randomly sleep, smartly sleep. Sleep until you see the device
node you care about, or you time out after some longer amount of time
has gone by. That's all that is needed to change in your init script
package. As I don't run Debian on any of my boxes anymore, I really
can't be of much help here to try to debug this and change the proper
one to work in this manner.
So to summarize:
- this isn't a kernel issue (so why talk about it on lkml?)
- this isn't a udev issue (it creates the node as fast as it is
told to.)
- this _is_ a startup script issue. Please go bug your distro
to fix it in the manner described above.
Hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-05-24 4:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-24 7:37 udev and /dev/sda1 not found during boot (it's there right after boot) Erik Steffl
2004-04-24 15:55 ` Greg KH
2004-04-24 20:32 ` Marco d'Itri
2004-05-23 15:56 ` Erik Steffl
2004-05-23 16:25 ` Greg KH
2004-05-24 3:29 ` Erik Steffl
2004-05-24 4:58 ` Greg KH
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 read-only IMAP folder(s) and NNTP newsgroup(s).