This is when using gfxpayload=keep. If I manually switch to gfxpayload=text, I don't see this problem - there is no "EFI VGA" mentioned in dmesg.
When the problem occurs, I get a plymouth full-screen text splash, which can't be cleared (because the console is apparently dead). ssh'ing in and using chvt doesn't work. /proc/fb is empty. plymouth has run and exited successfully, leaving no error logs in /var/log/upstart.
> Disabling splash, brings up text interface to unlock the drive & allows to boot.
How did you disable splash? For me, disabling the 'splash' commandline option is insufficient unless I also disable the grub fb handoff.
Anyway, the bug I'm seeing is definitely a kernel bug, but I don't know if it's the same as your bug.
Dmitrijs,
Which video driver are you using in your VM?
Installing from a quantal alpha 3 server image, I see the following in dmesg in KVM:
[ 2.900838] [drm] Initialized drm 1.1.0 20060810 vram_init] *ERROR* can't reserve VRAM 00-00000000febf 4fff> 00-00000000fc3f ffff>
[ 2.975879] checking generic (fc000000 160000) vs hw (fc000000 2000000)
[ 2.975885] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
[ 2.975914] Console: switching to colour dummy device 80x25
[ 3.010796] [drm:cirrus_
[ 3.010805] cirrus 0000:00:02.0: Fatal error during GPU init: -6
[ 3.010809] Trying to free nonexistent resource <00000000febf40
[ 3.010814] Trying to free nonexistent resource <00000000fc0000
This is when using gfxpayload=keep. If I manually switch to gfxpayload=text, I don't see this problem - there is no "EFI VGA" mentioned in dmesg.
When the problem occurs, I get a plymouth full-screen text splash, which can't be cleared (because the console is apparently dead). ssh'ing in and using chvt doesn't work. /proc/fb is empty. plymouth has run and exited successfully, leaving no error logs in /var/log/upstart.
> Disabling splash, brings up text interface to unlock the drive & allows to boot.
How did you disable splash? For me, disabling the 'splash' commandline option is insufficient unless I also disable the grub fb handoff.
Anyway, the bug I'm seeing is definitely a kernel bug, but I don't know if it's the same as your bug.