After dist-upgrade today, I'm getting a black screen on boot, around populating devices. It times out after a minute or two and the boot process continues, apparently normally, to the kdm login screen.

There will be a new kernel coming up in a few hours, which might fix the issue - please test (there is one potential issue, which might explain this behaviour, but I can not reproduce the bug locally).

vinur

Post subject: RE: Black screen on boot Posted: 21.08.2013, 18:53

Joined: 2010-09-11
Posts: 83
Location: Lake Oswego
Status: Offline

Just a quick note that I am experiencing the same wait. its about 2 minutes and then the system seems to load normally at first glance... I have not as yet investigated it much... so actual data is not available but it has been going on for a couple of days.
I will pay attention to the effect next boot time.
here is what I am running this minute:

Please, as mentioned yesterday, test "3.10-9.slh.1-aptosid-amd64" (or its 686 variant), I'm very interested if the issue persists. There is a very high probability that it's fixed with the current kernel, so I'm considering 3.10-7.slh.2-aptosid-amd64 (3.10-7.slh.2-aptosid-686 respectively) as "known-broken" and am only interested in issues with other (newer) kernels.

alexk

Post subject:Posted: 21.08.2013, 21:05

Joined: 2010-10-01
Posts: 288

Status: Offline

I still have the same issue with kernel 3.10-9.slh.1-aptosid-amd64 and after another dist-upgrade. When I hit Scroll Lock after the 1-2 minutes of black screen, I see messages like this on the screen (this is as recorded for yesterday in /var/log/daemon.log, I saw the same kind of messages today):

Then comes up with some code I did not have enough time to see well, at which point it runs the rest of the start up as more or less normally.

Otherwise all is the same as far as I can see running the machine.

Is there some command I can use to get information you can use that may help?

slh

Post subject:Posted: 21.08.2013, 23:55

Joined: 2010-08-25
Posts: 954

Status: Offline

O.k., now it would be interesting to confirm if this is actually a kernel regression or a new bug in hplip (which was updated on saturday).

So if you still have an older kernel installed, please check if that one is affected as well. In order to rule out stale initramfs (without the new hplip udev rules), you'll have to refresh the initramfs for your old kernel as well, so boot into an older (perviously unaffected) kernel and run "update-initramfs -u -k $(uname -r)" as root, which will recreate the initramfs for the running kernel and update the embedded udev rules. I'd also need to know which was the last unaffected kernel version - and if it remains unaffected after refreshing the initramfs.

In case you don't own a HP printer, it might be easier to purge hplip alltogether (apt-get purge hplip hplip-data libhpmud0 printer-driver-hpcups) - and reboot.

vinur

Post subject:Posted: 22.08.2013, 00:50

Joined: 2010-09-11
Posts: 83
Location: Lake Oswego
Status: Offline

Hello slh,
Did some reboots with different older kernels going back to 3.9 and the issue seemed to follow with a change of the microcode failed. (does not seem to track the kernel id so I think the numbers are unrelated 3.904644, 3.831470, ... etc)
however the one consistency is fam15h.bin which is always present in the failed to load information... its been there for a long time so I don't think it is related to the hanging issue, but I don't know enough to judge.
What I am going to do now is start to boot with the oldest extant kernel I have on this drive and see what happens.

vinur

Post subject:Posted: 22.08.2013, 01:15

Joined: 2010-09-11
Posts: 83
Location: Lake Oswego
Status: Offline

Hello slh,
booted to 3.9-0.slh.4 microcode failed 3.456039 and the hang continues for about 1 minute
the fam15h.bin I think is related to an AMD issue and never seemed to amount to much of an problem as it has always been there in passing fast and the machine just boots fast.

I see that the hang is related to something about hp printers as *it is* correcting for some issue relative to that.
By the way the printer is a low end hp laser I got as a trade in and is very junky... but it does continue to work through these issues... just printed your last instructions so I will have them available in what ever mode and drive I am in.

I don't mind purging the printer drivers on this system for a while

I have an older Linux aptosid drive on this computer that runs OK and it contains printer drivers that will run the hp p1006 printer ok. it is a crash backup system and is old but I do use it from time to time.

let you know what I find out soon.
If I need to print I can use that old drive

vinur

Post subject:Posted: 22.08.2013, 02:23

Joined: 2010-09-11
Posts: 83
Location: Lake Oswego
Status: Offline

Hello slh,
As the hang seemed to be independent of which kernel I was using... always a time hang independent of kernel version I did the purge option you gave (apt-get purge hplip hplip-data libhpmud0 printer-driver-hpcups)
when I rebooted the time hang was gone.
Hope this bit of info is useful to you.
For the time being I will use the older (older = un-upgraded system 1.5 years) as connected dual boot aptosid to print from.

alexk

Post subject:Posted: 23.08.2013, 12:32

Joined: 2010-10-01
Posts: 288

Status: Offline

The last kernel that I didn't have the issue with was 3.10-2.slh.2-aptosid-amd64 and I still have the issue with that kernel now, even after running an "update-initramfs -u -k 3.10-2.slh.2-aptosid-amd64" from the 3.10-9.slh.1-aptosid-amd64 kernel and then booting into 3.10-2.slh.2-aptosid-amd64.

The udev rule that's generating the timeout on boot is in /lib/udev/rules.d/56-hpmud.rules from hplip:

Then I'd suggest to report a bug against the hplip package, unfortunately I don't have access to any printers using it.

alexk

Post subject:Posted: 25.10.2013, 03:13

Joined: 2010-10-01
Posts: 288

Status: Offline

I still have this issue with hplip version 3.13.9-2, except that I get the black screen for only 30 seconds after "Populating devices ...", then the boot continues.

slh

Post subject:Posted: 25.10.2013, 03:48

Joined: 2010-08-25
Posts: 954

Status: Offline

Please check dmesg for gaps between the timestamps. A short black screen is normal for that stage, caused by the graphics mode switch - this typically takes 2-3 seconds (and is only cosmetic, the system actually continues booting in parallel). If your screen is slow with adjusting to resolution changes, that modeswitch might easily take up to around 10-12s, so dmesg is best at telling the truth.