[Bug 1038055] Re: graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)

[Stefan Bader]

So asking around, grub (even in Precise) passes mode 0x70 (which happens
to be efifb) as a generic framebuffer setup and the usage of efifb is
more in a generic way than EFI. For real hw grub uses an internal VBE
driver. The reason we never had any issues was that without the cirrus
DRM driver efifb was the only framebuffer driver. Now there is one and
we run into this race.

With the (admittedly ugly) patch, the init of the cirrusdrmfb does wait
for the release of the efifb resources. But it fails on bringing up
lightdm. What I think happens is that efifb does not completely go away
until plymouth closes the old fb devices. Which it does at some point
(in my tests there would be a delay of about 3s), likely when getting IO
errors when accessing it. But it does not retry to open the (new)
device. Or it does but would need to give a bit more time between
retries.

If that would be working there currently would be the next issue that
efifb and cirrusdrmfb use different resolutions. Probably not fatal but
certainly visible on boot.

** Patch added: "Attempt to wait on resources (still includes debug code)"
   https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1038055/+attachment/3325106/+files/0001-UBUNTU-SAUCE-Wait-for-resources-when-switching-frame.patch

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1038055

Title:
  graphics fail to initialise correctly, in kvm with cirrus graphics
  (after LUKS install)

Status in “cryptsetup” package in Ubuntu:
  Invalid
Status in “grub2” package in Ubuntu:
  Invalid
Status in “linux” package in Ubuntu:
  Confirmed
Status in “plymouth” package in Ubuntu:
  Invalid
Status in “ubiquity” package in Ubuntu:
  Invalid

Bug description:
  reproducible with ubiquity or alternate installer in KVM virtual machine:
  1) select lvm + encrypted instalation

  
  it fails to boot, in a way that I get "no video mode activated" and I cannot type the password in to unlock the drive.

  As a workaround, I had to:
  1) force reboot machine
  2) then grub options come up
  3) select recovery mode
  4) then I can enter the password using text interface
  5) resume normal boot

  Disabling splash, brings up text interface to unlock the drive &
  allows to boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1038055/+subscriptions