Note (2014-01-03):
The problem described in this thread was fixed during the kernel 3.10 development cycle and has been backported to older supported Ubuntu kernels.
On one of my spare laptops I've been fiddling with some UEFI stuff on other distributions. I began to notice a major problem: attempts to write to the NVRAM would silently fail. In the worst case scenario, this renders a machine unbootable. It's easy enough to recover -- boot with some kind of live USB and run efibootmgr. But what was really going on?
A pattern began to emerge: after any updates to a 3.8 series kernel, writes to NVRAM would fail. Booting a USB with an older kernel allowed me create the NVRAM variable that otherwise wouldn't get created.
I filed a bug against efibootmgr, thinking the problem was with that utility. Then I started Googling a bit, and noticed posts on the forums for Arch, openSUSE, and others. Eventually I found some Launchpad bugs. Turns out the problem actually is with the kernel. See comment #7 in Launchpad Bug 1167622. A commit to the kernel increases paranoia:
This change is to workaround the buggy Samsung UEFIs that would brick themselves if the NVRAM storage space became more than 50% full.
So we have a kernel commit to protect a crappy UEFI implementation that ends up borking proper UEFI behavior for everybody. Great. I hope this commit gets reverted sometime.
Lesson: if you have a UEFI machine, and you like to run the latest kernels, remember to keep a 3.7 kernel around. You'll need this whenever you want to modify your UEFI NVRAM variables.
The problem described in this thread was fixed during the kernel 3.10 development cycle and has been backported to older supported Ubuntu kernels.
On one of my spare laptops I've been fiddling with some UEFI stuff on other distributions. I began to notice a major problem: attempts to write to the NVRAM would silently fail. In the worst case scenario, this renders a machine unbootable. It's easy enough to recover -- boot with some kind of live USB and run efibootmgr. But what was really going on?
A pattern began to emerge: after any updates to a 3.8 series kernel, writes to NVRAM would fail. Booting a USB with an older kernel allowed me create the NVRAM variable that otherwise wouldn't get created.
I filed a bug against efibootmgr, thinking the problem was with that utility. Then I started Googling a bit, and noticed posts on the forums for Arch, openSUSE, and others. Eventually I found some Launchpad bugs. Turns out the problem actually is with the kernel. See comment #7 in Launchpad Bug 1167622. A commit to the kernel increases paranoia:
efi: be more paranoid about available space when creating variables
UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.
Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.
Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
So we have a kernel commit to protect a crappy UEFI implementation that ends up borking proper UEFI behavior for everybody. Great. I hope this commit gets reverted sometime.
Lesson: if you have a UEFI machine, and you like to run the latest kernels, remember to keep a 3.7 kernel around. You'll need this whenever you want to modify your UEFI NVRAM variables.
Comment