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