When I boot with kernel 4.17.0-rc2+ the screen stays dark for more than 2 minutes before the GUI appears. This is a regression towards 4.16.0-rc3+ where the GUI had appeared immediately when Xorg had started up.
Please attach the dmesg output from 4.17.0-rc2+, captured after the GUI has appeared.
Created attachment 275797 [details] dmesg with 4.17.0-rc3+ after bootup
persists with 4.17.0-rc4+
Sounds like the same bug I had https://bugzilla.kernel.org/show_bug.cgi?id=199567 that started with rc2 onwards as well. Have a look at my findings (including the kernel commit that caused it) and see if it's the same issue.
The issue persists with kernel 4.17.0+.
This applies to the nouveau driver.
Hi Elmar, I don’t know if it may be of help, anyway I have a similar problem: the point is that my problem does not seem related to graphic drivers. My OS is Slackware64 14.2, kernel 4.17.0. At boot, after the usual kernel messages, this is what I see, at the end, on the screen (please, note that I boot in non graphical mode, that is in init 3): Welcome to Linux 4.17.0 (tty1) darkstar login: [ 15.869206] wlan0: authenticate with 64:59:f8:cd:3a:88 [ 15.887504] wlan0: send auth to 64:59:f8:cd:3a:88 (try 1/3) [ 15.892825] wlan0: authenticated [ 15.895108] wlan0: associate with 64:59:f8:cd:3a:88 (try 1/3) [ 15.899592] wlan0: RX AssocResp from 64:59:f8:cd:3a:88 (capab=0x411 status=0 aid=3) [ 15.900872] wlan0: associated as you can see, after the welcome message I can’t insert my login username – because of the extra messages related to wlan authentication/association – and as a consequence the system gets stuck. However, (in my case) we are dealing here with a “trivial” bug, since it suffices to press Enter in order to restore the login prompt and then start X. I don’t know if this bug may be related to yours: in any case I would try to boot in runlevel 3 in order to see what happens. All the best, Giorgio
No, I don´t see what your bug should have in common with mine, Giorgio. Mine occurs after starting the X server. Very annoying; this bug persists up to kernel 4.18.0-rc1+.
Hi Elmar, sorry that I couldn't be of any help to you.....I hope that the the next (kernel) incremental patches will fix the bug...
persists with 4.19.0-rc2+
Elmar, did you have a look at my bug report from comment 4? Does installing something like rng-tools fix the problem? If it does, then you are suffering from the same, widespread, well-documented issue that began with 4.17-rc2 with commit43838a23a05fbd13e47d750d3dfd77001536dd33 (random: fix crng_ready() test). The kernel is waiting for enough entropy to have been generated and it causes a long hang until you mash on random keys or something else helps generate it. Until then, you get a nice black screen. Unfortunately, this has the side effect of slightly lengthening the shutdown and restart time by a few seconds, but the boot/login time is returned to normal. I used to have an ath9k based wireless card and there is an option in the kernel to use it to help add to the entropy pool. This solved the problem completely for me on my custom kernels, but then I went and got a new wireless card that isn't so fortunate as to have this option in the kernel config and I'm back to waiting for a more permanent fix too. At least give it a try, it sounds like the same problem.
Unfortunately when I install rng-tools I get the following error message with 4.19.0-rc2+: Hardware RNG device inode not found. If I install rng-tools5 I get no error message but booting does not speed up with rng-tools5 (same long waiting). Concerning my wireless network card I have an iwlwifi card (Intel Corporation Ultimate N WiFi Link 5300). However there seems to be no kernel option in order to gather entropy with this card.
It is the same with kernel 4.20.0-rc4+. Are there any plans to extend the number of devices that can contribute to the entropy pool? f.i. I have an accelerometer in my notebook which should contribute more and better entropy than my mouse and keyboard.