Bug#708430: EFI bug still present

[Philipp Kern]

On 2013-11-23 15:26, Svante Signell wrote:
> On Sat, 2013-11-23 at 15:19 +0100, Philipp Kern wrote:
>> Control: severity -1 important
>> 
>> On Fri, Nov 15, 2013 at 01:01:15PM +0100, Svante Signell wrote:
>> > found 708430 2.00-20
>> > thanks
>> >
>> > Ping! Any ideas why nothing happens to this grave bug?
>> 
>> I disagree that it's grave. It's not broken for everybody. You copied
>> the binary to the fallback path to cope with non-compliant firmware,
>> your proposed solution is certainly not the right way, and even if it
>> sounds harsh you cannot expect this solution to last during upgrades,
>> unless you add a hook to, say, /etc/grub.d.
>> 
>> What does efibootmgr -v say?
> BootCurrent: 0004
> Timeout: 2 seconds
> BootOrder: 0001,0004,0000
> Boot0000  Windows Boot Manager
> Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...1................
> Boot0001* debian
> HD(2,c8800,32000,8d145938-70ee-4ef9-958f-8c0ac6d990b6)File(\EFI\debian
> \grubx64.efi)
> Boot0004* UEFI: LITEONIT LCT-128M3S
> ACPI(a0341d0,0)PCI(1f,2)03120a000000ffff0000HD(2,c8800,32000,8d145938-70ee-4ef9-958f-8c0ac6d990b6)AMBO

I wonder if the HD needs more qualification through the ACPI/PCI path 
information. But I'm unsure if efibootmgr can actually set that... 
(Assuming that you didn't do a manual pick at boot and it just skipped 
0001, which is likely what happened here.)

Kind regards
Philipp Kern