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.
Here's an updated late_command to deploy with.
_hexdump_ bootcurrent: efi/efivars efi/vars/ " efi/vars/ efi/efivars/ BootCurrent* /data) efi/efivars efi/efivars/ efi/efivars/ BootCurrent* ) efi/efivars
- &hexdump |
grep efi /proc/mounts
mountpoint /sys/firmware/
echo "checking /sys/firmware/
ls -al /sys/firmware/
bcurrent=$(ls /sys/firmware/
[ -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/
ls -al /sys/firmware/
echo "efibootmgr output after mounting efivars"
efibootmgr -v
bcurrent=$(ls /sys/firmware/
[ -e "${bcurrent}" ] && hexdump $bcurrent
umount /sys/firmware/
late_commands: efi/efivars' ]
01_efivars: ['grep', 'efi', '/proc/mounts']
02_efimnt: ['mountpoint', '/sys/firmware/
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 efi/efivars when we run commands in-target
mounting /sys/firmware/
The debug output from this should help us understand what's going on.
I did observe that without efivars mounted, the grub install which efi/vars
adds a new ubuntu entry was only viable via /sys/firmware/
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: 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 efi/efivars is a *mount* point efi/efivars efi/vars (part of the kernel, not a separate mount) efi/efivars (special mount)
>
> 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/
> > > 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/
> 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/
>
> Hrm, it looks like there are two vars paths:
>
> /sys/firmware/
> and
> /sys/firmware/
>
> It seems that efibootmgr could show different values depending which
> path it is taking.