On Fri, Sep 14, 2018 at 9:51 AM Ryan Harper <email address hidden> wrote: > > On Thu, Sep 13, 2018 at 6:35 PM Rod Smith <email address hidden> wrote: > > > > I'm afraid the node is failing to deploy with those changes to > > /etc/maas/preseeds/curtin_userdata (I assume that's where you wanted > > them): > > > > Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpzfw22u7e/target', 'sh', '-c', 'ls -al /sys/firmware/efi\nbcurrent=$(ls /sys/firmware/efi/efivars/BootCurrent*)\n[ -e "${bcurrent}" ] && hexdump $bcurrent\n'] with allowed return codes [0] (capture=False) > > total 0 > > drwxr-xr-x 5 root root 0 Sep 13 23:10 . > > drwxr-xr-x 6 root root 0 Sep 13 23:08 .. > > -r--r--r-- 1 root root 4096 Sep 13 23:10 config_table > > dr-xr-xr-x 2 root root 0 Sep 13 23:08 efivars > > -r--r--r-- 1 root root 4096 Sep 13 23:10 fw_platform_size > > -r--r--r-- 1 root root 4096 Sep 13 23:10 fw_vendor > > -r--r--r-- 1 root root 4096 Sep 13 23:10 runtime > > drwxr-xr-x 9 root root 0 Sep 13 23:10 runtime-map > > -r-------- 1 root root 4096 Sep 13 23:09 systab > > drwxr-xr-x 70 root root 0 Sep 13 23:10 vars > > ls: cannot access '/sys/firmware/efi/efivars/BootCurrent*': No such file or directory > > Yuck, I was seeing the same thing in my VM, but I was sure it was an > issue with the VM. > > I cannot fathom why that sys path is not accessible. Let me look more > into my VM and see what's going on.
Well, it turns out that /sys/firmware/efi/efivars is a *mount* point which should be automatically mounted on UEFI systems. Something is fishy here.
If it's not mounted, one can run:
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Hrm, it looks like there are two vars paths:
/sys/firmware/efi/vars (part of the kernel, not a separate mount) and /sys/firmware/efi/efivars (special mount)
It seems that efibootmgr could show different values depending which path it is taking.
On Fri, Sep 14, 2018 at 9:51 AM Ryan Harper <email address hidden> wrote: preseeds/ curtin_ userdata (I assume that's where you wanted 7e/target' , 'sh', '-c', 'ls -al /sys/firmware/ efi\nbcurrent= $(ls /sys/firmware/ efi/efivars/ BootCurrent* )\n[ -e "${bcurrent}" ] && hexdump $bcurrent\n'] with allowed return codes [0] (capture=False) efi/efivars/ BootCurrent* ': No such file or directory
>
> On Thu, Sep 13, 2018 at 6:35 PM Rod Smith <email address hidden> wrote:
> >
> > I'm afraid the node is failing to deploy with those changes to
> > /etc/maas/
> > them):
> >
> > Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpzfw22u
> > total 0
> > drwxr-xr-x 5 root root 0 Sep 13 23:10 .
> > drwxr-xr-x 6 root root 0 Sep 13 23:08 ..
> > -r--r--r-- 1 root root 4096 Sep 13 23:10 config_table
> > dr-xr-xr-x 2 root root 0 Sep 13 23:08 efivars
> > -r--r--r-- 1 root root 4096 Sep 13 23:10 fw_platform_size
> > -r--r--r-- 1 root root 4096 Sep 13 23:10 fw_vendor
> > -r--r--r-- 1 root root 4096 Sep 13 23:10 runtime
> > drwxr-xr-x 9 root root 0 Sep 13 23:10 runtime-map
> > -r-------- 1 root root 4096 Sep 13 23:09 systab
> > drwxr-xr-x 70 root root 0 Sep 13 23:10 vars
> > ls: cannot access '/sys/firmware/
>
> Yuck, I was seeing the same thing in my VM, but I was sure it was an
> issue with the VM.
>
> I cannot fathom why that sys path is not accessible. Let me look more
> into my VM and see what's going on.
Well, it turns out that /sys/firmware/ efi/efivars is a *mount* point
which should be
automatically mounted on UEFI systems. Something is fishy here.
If it's not mounted, one can run:
mount -t efivarfs efivarfs /sys/firmware/ efi/efivars
Hrm, it looks like there are two vars paths:
/sys/firmware/ efi/vars (part of the kernel, not a separate mount) efi/efivars (special mount)
and
/sys/firmware/
It seems that efibootmgr could show different values depending which
path it is taking.