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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
