Bug#708430: EFI bug still present

[Svante Signell]

On Sat, 2013-11-23 at 16:33 +0100, Philipp Kern wrote:
> 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.)

As I said before, without copying the grubx64.efi file to the fallback
path, I'm left with a grub prompt (the most primitive). And I have not
done any strange settings in the "BIOS", except disabling secure boot.