first boot after installing Lucid results in tty request to login

Unsetting the package, this is almost certainly not a ureadahead bug.

When you're presented with this tty login, please log in and run 'sudo initctl list' and post the output here.

Thanks Steve, that was a wild guess on my part. Before I get started I want to clarify above all else that this should be considered very low priority, as it only occurs on the very first boot after installing, and it passes so quickly (3 to 4 seconds) that if you'd blink you'd miss it. Also, whether or not you take any action with the keyboard, the boot process completes successfully.

For the same reasons mentioned above (I'll have to do a fresh install to perform each test) I want to clarify exactly when to run "sudo initctl list". Remember that keyboard input either does not effect the boot process when that appears, or I simply can't input my five character username + Enter quickly enough to effect the boot process.

So should I Ctrl + Alt + F1 the moment that text login prompt appears to get a functional tty and then run the command? Or should I go ahead to the desktop and then run the command?

I'm thinking the prior but I'd like to be sure.

BTW many thanks to you all for making Lucid so awesome. It's looking really great!

Hi Steve,

I'm here from supposed duplicated 557930.

I'm booting with Live Version from a USB Stick. I fall back to console and not to tty's login like Erick. Btw attached you'll found initctl list and apport-cli file. Let me know if I can help you more.

Greetings

Eric said: "this should be considered very low priority, as it only occurs on the very first boot after installing, and it passes so quickly (3 to 4 seconds)"

@Steve: this is not the same bug like in #557930. I fallback in textual console permanently, not for just 3 seconds.

Oh, sorry, I guess I read this bug too fast and didn't understand that the tty login only appears briefly. Un-marking the other bug as a duplicate.

So if the command prompt only shows up briefly, that plymouth-stop has been triggered by the init scripts ('rc') finishing before gdm is ready to start.

This may indeed be affected by ureadahead, but it wouldn't be a ureadahead bug. We just are not defined to have gdm start before the init scripts have finished, so sometimes there may be a gap.

Reassigning to plymouth; I'm not sure what we can do about it in practice, but that's the package responsible for the boot splash.

I do think this should be marked low priority for now, possibly even "won't fix" at some point.

I reported this after 13 or 14 installs chasing the following bug to be sure it was taken care of:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/556373

I'll also be testing again in just a few days for progress on this one:

https://bugs.launchpad.net/ubuntu/+source/casper/+bug/539027

I'll report any change at that time. This was one of those tiny issues that I was almost tempted to overlook.

I'm not seeing this behavior with the pre-RC iso testing i386 Live CD so I'm marking it invalid.

setting back to confirmed, because I don't think the bug in plymouth has been fixed.

You're right Steve, I'm seeing this with the first iso-testing build for Lucid final. The thing is it's not at all consistent.

It's still low priority IMO because "no action" results in a proper boot. And it seems to only happen on the first boot after installation ............ I think!

After today's updates I'm having mixed results:

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/569317

So for now I'm going to focus on the worst to see if I can be helpful.

I notice this again iso-testing the pre-alpha 1 Maverick i386 Live CD. Very, very minor. Something so minor I'm reluctant to even report it, just to recap:

Initial boot after install appears to go to tty1 but if you wait for just a couple of seconds gdm appears as it should. Subsequent boots are normal.

I get it ever so often I run the startx command then bang I am back int the GUI

Well there issue here maybe loading the video drivers who knows

 $ lspci
00:00.0 RAM memory: nVidia Corporation MCP61 LPC Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 / nForce 630a] (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control

This is still seen, in some cases, with the actual active ubuntu releases. Looks like a process booting race, which have no real sad effect but only cosmetic one (like some others found with journalctl).

Yep, but it's gone in a flash. In fact I've tried to see what happens with keyboard input but it disappears so quickly I never have time to complete entering the input before it's gone.