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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1038055 Title: graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1038055/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
