Created attachment 40800 [details]
patch to systemd-vconsole-setup.service

Sorry, I spoke too soon.

A few more reboots showed that the attached patch does not make a difference.

It seems that the problem is triggered (not yet sure if it is 100%) by booting with "verbose" as opposed to "quiet". I also noticed that it seems to make syslog-ng.service fail (but I'll need to look into that more carefully, it might be a coincidence).

Created attachment 42242 [details] [review]
patch to systemd-vconsole-setup.service

I had a look at this bug again to see if I could figure it out.

I am not able now to reproduce the bug with the patch applied, so either the patch decreases the likelihood of hitting the bug a lot, or it fixes it and I made a mistake before.

If a non-standard tty is used, the After and Requires dependencies must obviously also be changed (in the attached I made the tty explicit, so this should hopefully be obvious).

Hmm, is it possible that you have udev rules on your system that do things with the tty? Maybe some package of your distros hooks in some udev rules?

If this patch of yours really has an effect than this means that for some reason the tty0 device is not available right from the beginning but only have a udev event got send to systemd. There might be two explanations for that I can think of: a) there's something fiddling with the console run from udev rules, i.e. before we get the the event from udev or b) your video drivers or so are loaded as modules and not compiled in?

Can you verify whether b) is the case?

s/have/after

Thanks for the suggestions.

I can confirm that my video drivers are compiled in (however, I had reports from others who _might_ be seeing the same problem where the drivers are as modules, so it would be nice if we could support both scenarios).

I will look into your first suggestion on Monday and report back. I have been meaning to try to clean up our udev package so this is a good excuse (I'm not the maintainer though, so might take some time).

(In reply to comment #6)
> Thanks for the suggestions.
> 
> I can confirm that my video drivers are compiled in (however, I had reports
> from others who _might_ be seeing the same problem where the drivers are as
> modules, so it would be nice if we could support both scenarios).

Hmm, maybe the video drivers themselves are compiled in but some other parts of the graphics stack aren't? Can you paste your lsmod post-boot here?

I had a look at our udev rules, I could find nothing related there. As we don't have a development version of rsyslog available yet, we have been using syslog-ng for the time being. This obviously doesn't work quite as it should, in particular it prints log messages to the console. Could this be somehow block the device (wild guess...)?

I don't think anything else graphics-related is compiled as a module:

binfmt_misc            17456  1 
rfcomm                 47077  6 
sco                    18056  2 
bnep                   18139  2 
l2cap                  53032  16 rfcomm,bnep
btusb                  18600  2 
bluetooth              70106  9 rfcomm,sco,bnep,l2cap,btusb
usbhid                 32683  0 
microcode              14024  0 
snd_hda_codec_hdmi     27884  1 
snd_hda_codec_idt      70361  1 
snd_hda_intel          32748  2 
b43                   337009  0 
uhci_hcd               30969  0 
snd_hda_codec          92394  3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel
snd_hwdep              13556  1 snd_hda_codec
snd_pcm                79457  3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
ehci_hcd               48885  0 
dell_wmi               12681  0 
firewire_ohci          39903  0 
sdhci_pci              13943  0 
usbcore               157210  4 btusb,usbhid,uhci_hcd,ehci_hcd
psmouse                54740  0 
firewire_core          60624  1 firewire_ohci
snd_timer              28605  1 snd_pcm
sparse_keymap          13534  1 dell_wmi
dell_laptop            13827  0 
sdhci                  26721  1 sdhci_pci
ssb                    50296  1 b43
snd                    63974  11 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc         18101  2 snd_hda_intel,snd_pcm
processor              30518  2 
thermal                18353  0 
wmi                    18697  1 dell_wmi
battery                13695  0 
evdev                  17712  8 
ac                     12862  0

(In reply to comment #8)
> I had a look at our udev rules, I could find nothing related there. As we don't
> have a development version of rsyslog available yet, we have been using
> syslog-ng for the time being. This obviously doesn't work quite as it should,
> in particular it prints log messages to the console. Could this be somehow
> block the device (wild guess...)?

Nope, very unlikely.
 
> I don't think anything else graphics-related is compiled as a module:

Yupp, looks fine.

I have really no ide what might be going on here, sorry...

That makes two of us.

I'll report back if I find out more information (or if the bug disappears).

My guess is that this is the following bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554172/comments/245

Can you reproduce this with a .38 kernel? The BKL is gone there so the bug should be gone, too.

Thanks for getting back to this. I can confirm that I can no longer reproduce the bug (after 10 tries) on kernel 2.6.38-rc5 and systemd 18.