Here's an updated late_command to deploy with.

_hexdump_bootcurrent:
 - &hexdump |
   grep efi /proc/mounts
   mountpoint /sys/firmware/efi/efivars
   echo "checking /sys/firmware/efi/vars/"
   ls -al /sys/firmware/efi/vars/
   bcurrent=$(ls /sys/firmware/efi/efivars/BootCurrent*/data)
   [ -e "${bcurrent}" ] && hexdump $bcurrent
   echo "efibootmgr output before mounting efivars (uses vars)"
   efibootmgr -v
   echo "mounting efivars"
   mount -o defaults -t efivarfs efivarfs /sys/firmware/efi/efivars
   ls -al /sys/firmware/efi/efivars/
   echo "efibootmgr output after mounting efivars"
   efibootmgr -v
   bcurrent=$(ls /sys/firmware/efi/efivars/BootCurrent*)
   [ -e "${bcurrent}" ] && hexdump $bcurrent
   umount /sys/firmware/efi/efivars


late_commands:
  01_efivars: ['grep', 'efi', '/proc/mounts']
  02_efimnt:  ['mountpoint', '/sys/firmware/efi/efivars']
  03_hexdump: ['curtin', 'in-target', '--', 'sh', '-c', *hexdump]

This runs fine on my VM now so it will be interesting to see what the
BootCurrent values show here.

One possible change to curtin here is we may need to start bind
mounting /sys/firmware/efi/efivars when we run commands in-target
The debug output from this should help us understand what's going on.

I did observe that without efivars mounted, the grub install which
adds a new ubuntu entry was only viable via /sys/firmware/efi/vars
and that if I mounted efivars up and then ran efibootmgr, it wouldn't
*show* the ubuntu entry; so it seems possible to have these
different paths out of sync which may explain the error.

On Fri, Sep 14, 2018 at 11:08 AM Ryan Harper <email address hidden> wrote:
>
> 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.