wrong stride for efifb on some systems

Bug #1065263 reported by Steve Langasek
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
In Progress
Andy Whitcroft

Bug Description

On some systems, the efifb driver comes up with the wrong idea of the framebuffer dimensions, resulting in diagonal-stripey corruption on the display at boot time. This is only a minor problem if there's another framebuffer taking over immediately, but it makes d-i-based install CDs unusable when this happens.

Matthew Garrett has pushed a kernel patch to address this:


This may be too late to do any good for 12.10 server images, but we should make sure this gets into 13.04 and that it's included in any 12.04.2 UEFI-related backports.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1065263

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

mjg59 points out that the early-boot half of this also needs to be pulled in:


Those two patches will give us correct efifb handling in the case where we use the signed kernel. Users who aren't using vmlinuz.efi will still see the video corruption, but that's not an issue for the installer per se.

Changed in linux (Ubuntu):
status: Incomplete → Opinion
status: Opinion → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: kernel-da-key quantal
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Andy Whitcroft (apw) wrote :

@vorlon -- I have pulled back three changes (the two mentioned here and Seths size one) and built a test kernel. Could you test the kernels here and let me know if they resolve your issue:



Changed in linux (Ubuntu):
assignee: nobody → Andy Whitcroft (apw)
status: Triaged → In Progress
Revision history for this message
Steve Langasek (vorlon) wrote :

So I've regression-tested this, and the system still boots with the patches applied. However, to test the fix I need an image that includes the kernel efi stub, since that's where one half of the fix lands. I don't suppose you could spit me out one of these? (I don't need it to be signed, I just need a stub to be there.)

Revision history for this message
Steve Langasek (vorlon) wrote :

Andy has clarified that the unsigned vmlinuz in the .deb does include the stub. However, it seems I'm now unable to reproduce the original issue: if I block the i915 driver from loading on an installed system, leaving me with EFI VGA in /proc/fb, I get a perfectly usable console on boot. Need to investigate further to understand why this is reproducible with the server image but not with an installed desktop.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.