public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] udev hanging
@ 2015-05-15  5:56 Raffaele BELARDI
  2015-05-15 21:56 ` [gentoo-user] " walt
  0 siblings, 1 reply; 4+ messages in thread
From: Raffaele BELARDI @ 2015-05-15  5:56 UTC (permalink / raw
  To: gentoo-user@lists.gentoo.org

I have an amd64 system with an old 3.3.x kernel. Recently (I think after 
last udev update to 217) the boot process became very slow due to "udev 
waiting for uevents to populate /dev". After a minute or so udev prints 
something about a lazy device (a TV tuner) then the boot continues.

Yesterday I tried to update the kernel to 4.0.2. On first boot no udev 
delay. Then I had to reboot into 3.3.x and from then on 4.0.2 does not 
boot any more, it hangs endlessly in the "udev waiting" state. 3.3.x 
still behaves as before (slow but works).

I removed the TV tuner hardware but no change.

Since problems in 4.x started after I booted into 3.x, could it be that 
udev saved some state that makes the 4.x boot process fail?
Any hints to debug this issue?

thanks,

raffaele

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

* [gentoo-user] Re: udev hanging
  2015-05-15  5:56 [gentoo-user] udev hanging Raffaele BELARDI
@ 2015-05-15 21:56 ` walt
  2015-05-18  5:59   ` Raffaele BELARDI
  0 siblings, 1 reply; 4+ messages in thread
From: walt @ 2015-05-15 21:56 UTC (permalink / raw
  To: gentoo-user

On 05/14/2015 10:56 PM, Raffaele BELARDI wrote:
> I have an amd64 system with an old 3.3.x kernel. Recently (I think after 
> last udev update to 217) the boot process became very slow due to "udev 
> waiting for uevents to populate /dev". After a minute or so udev prints 
> something about a lazy device (a TV tuner) then the boot continues.
> 
> Yesterday I tried to update the kernel to 4.0.2...

That kernel version is marked ~amd64 (unstable/testing).  Are you accepting
the ~amd64 keyword in your make.conf?  If you ask for help in this group you
should include that info as part of your question.  You'll get better answers
if you do.

Just as important in the last year or so is whether you are using systemd or
openrc at boot time.

Life never gets simpler over time :(




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

* Re: [gentoo-user] Re: udev hanging
  2015-05-15 21:56 ` [gentoo-user] " walt
@ 2015-05-18  5:59   ` Raffaele BELARDI
  2015-05-18 23:19     ` walt
  0 siblings, 1 reply; 4+ messages in thread
From: Raffaele BELARDI @ 2015-05-18  5:59 UTC (permalink / raw
  To: gentoo-user@lists.gentoo.org

walt wrote:
> On 05/14/2015 10:56 PM, Raffaele BELARDI wrote:
>> I have an amd64 system with an old 3.3.x kernel. Recently (I think after
>> last udev update to 217) the boot process became very slow due to "udev
>> waiting for uevents to populate /dev". After a minute or so udev prints
>> something about a lazy device (a TV tuner) then the boot continues.
>>
>> Yesterday I tried to update the kernel to 4.0.2...
>
> That kernel version is marked ~amd64 (unstable/testing).  Are you accepting
> the ~amd64 keyword in your make.conf?  If you ask for help in this group you
> should include that info as part of your question.  You'll get better answers
> if you do.
>
> Just as important in the last year or so is whether you are using systemd or
> openrc at boot time.
>
> Life never gets simpler over time :(
>

:-[ You're right, that was not a very good request from my side.

System is ~amd64, openrc, udev 219. Rebuilding the kernel with lots of 
changes the boot completed at least once. Now it still hangs in the same 
stage while waiting the NVIDIA video driver instead of the TV tuner 
driver. But pressing CTRL-C it continues without loading the faulty 
driver and at least I'm able to continue debugging.

So the udev hang is in reality an NVIDIA driver problem, so that's what 
I'm working on now.

Anyway I do have the impression that udev keeps a state somewhere, 
because more than once it happened that on first boot with new kernel it 
worked fine, starting from the second boot it had the 'waiting for 
uevents' problem. I tried to delete /etc/udev/hwdb.bin but it didn't change.

raffaele

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

* [gentoo-user] Re: udev hanging
  2015-05-18  5:59   ` Raffaele BELARDI
@ 2015-05-18 23:19     ` walt
  0 siblings, 0 replies; 4+ messages in thread
From: walt @ 2015-05-18 23:19 UTC (permalink / raw
  To: gentoo-user

On 05/17/2015 10:59 PM, Raffaele BELARDI wrote:
> walt wrote:
>> On 05/14/2015 10:56 PM, Raffaele BELARDI wrote:
>>> I have an amd64 system with an old 3.3.x kernel. Recently (I think after
>>> last udev update to 217) the boot process became very slow due to "udev
>>> waiting for uevents to populate /dev". After a minute or so udev prints
>>> something about a lazy device (a TV tuner) then the boot continues.
>>>
>>> Yesterday I tried to update the kernel to 4.0.2...
>>
>> That kernel version is marked ~amd64 (unstable/testing).  Are you accepting
>> the ~amd64 keyword in your make.conf?  If you ask for help in this group you
>> should include that info as part of your question.  You'll get better answers
>> if you do.
>>
>> Just as important in the last year or so is whether you are using systemd or
>> openrc at boot time.
>>
>> Life never gets simpler over time :(
>>
> 
> :-[ You're right, that was not a very good request from my side.
> 
> System is ~amd64, openrc, udev 219. Rebuilding the kernel with lots of 
> changes the boot completed at least once. Now it still hangs in the same 
> stage while waiting the NVIDIA video driver instead of the TV tuner 
> driver. But pressing CTRL-C it continues without loading the faulty 
> driver and at least I'm able to continue debugging.
> 
> So the udev hang is in reality an NVIDIA driver problem, so that's what 
> I'm working on now.
> 
> Anyway I do have the impression that udev keeps a state somewhere, 
> because more than once it happened that on first boot with new kernel it 
> worked fine, starting from the second boot it had the 'waiting for 
> uevents' problem. I tried to delete /etc/udev/hwdb.bin but it didn't change.

Just a random idea:  gentoo "udev" is now installed by the virtual/udev package.

IIUC, the udev virtual package may install different "real" packages, depending
on whether you are using openrc or systemd.

My reply may give you no real help, but it may attract attention from the real
brains of this mailing list, who probably can give you the solid advice you need.




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

end of thread, other threads:[~2015-05-18 23:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-15  5:56 [gentoo-user] udev hanging Raffaele BELARDI
2015-05-15 21:56 ` [gentoo-user] " walt
2015-05-18  5:59   ` Raffaele BELARDI
2015-05-18 23:19     ` walt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox