Re: accessing efivarfs in debian-installer
On Fri, May 27, 2016 at 10:59:35AM +0100, Steve McIntyre wrote:
> On Fri, May 27, 2016 at 10:41:39AM +0200, Francesco De Vita wrote:
> >Hi
> >
> >On 25/5/2016 16:31, Cyril Brulebois wrote:
> >> Francesco De Vita <fradev@inventati.org> (2016-05-24):
> >> > So, is it possible to access the efivarfs interface and retrieve
> >> > the required nvram-file inside the DI environment?
> >>
> >> I'm pretty sure we can do that from d-i since that's needed to get
> >> UEFI support working AFAICT. Looking at udebs, it seems you want to
> >> be loading this one, probably manually if you're at an early stage:
> >> efi-modules-4.5.0-2-amd64-di_4.5.4-1_amd64.udeb
> >>
> >> It contains:
> >> ./lib/modules/4.5.0-2-amd64/kernel/drivers/firmware/efi/efivars.ko
> >>
> >> which is likely to make it possible to access efivars, allowing you
> >> to mount them on the mount point (which you mentioned, exists
> >> already).
> >
> >This time I'm using the Stretch Alpha 6 DI. I successfully loaded the
> >efivars module as you suggested, however the efivarfs interface remains
> >inaccessible, it still cannot be mounted.
> >
> >I suppose that the efivarfs module has to be loaded too but there is no
> >trace of efivarfs.ko in the DI and I didn't find any udeb containing
> >it. Should I load it someway from an external source?
>
> Ah, that's your problem. It looks like we're not including that module
> yet. Most EFI variable users like efibootmgr will fall back to the
> older interfaces, so we've not noticed this yet.
>
> I'll go and fix that now.
Wasn't mounting the efivars as a file system implicated in the complete
bricking of someone's hardware a while ago? The problem being that it
was too easy to rm those files, which deleted those efi variables,
which included variable that were essential to making booting possible?
Not just that it wouldn't boot the installed system any more; it could
no longer boot anything, not even an operating-system installer?
I'd be wary of anything that mounts the efivars. Especially leaving
them mounted for more than the absolute minimum necessary to make
use of them.
Mind you, there was an argument that the hardware was bedly defined, in
that it had no mechanism to reset the efi vars to a safe staate, the
the guy who issued the rm -rf * was an idiot, and that systemd had left
the efivars mounted and vulnerable.
Juat be very careful with efivars.
-- hendrik
Reply to: