> @Ryan,
>
> Is it the /var/log/maas/rsyslog/{nodename}/{date}/messages file you want? If
> so, I've appended it. Note that it includes several deployments from today.
> The final one is definitely with the GRUB config lines in
> /etc/maas/preseeds/curtin. If it's another file, can you please tell me
> where to find it?

Thanks, that should be good enough.  Generally, fetching the logs via the
cli like so:

https://discourse.maas.io/t/getting-curtin-debug-logs/169

>
> I don't know offhand precisely how MAAS's GRUB handles the hand-off to the
> local GRUB, I'm afraid. I know it's been changed over the years, though.

OK.  Me neither; but I suspect we can work on that after sorting out how
to keep PXE boot enabled after a curtin install when BootCurrent is missing.

>
> From what state does the algorithm you posted begin? As I understand it (I

The algorithm runs after the following:

- Node is powered on and PXE boots
- Ubuntu boots over networking and starts the curtin install
- Curtin completes early, partitioning, network, extract phases; the
  requested OS has been installed to the target devices.
- Curtin starts the curthooks phase, which is used to configure the target
  OS
- The last step in curthooks calls setup_grub() method which finds the
  target block devices, chroots into the target and installs grub
- If grub install is successful, then curtin will then run the logic
  specified.

> may be wrong), installing the GRUB package adds the "ubuntu" boot
> item to the boot list, making it the first in the BootOrder. Thus, if the

Interesting. I know we create a new entry via the grub-install command, we
specify the bootloader-id value.  I was unaware as to the where in the order
it might place the new entry.

> algorithm you specified runs after that, then the effect of a missing
> BootCurrent variable would be that the GRUB-modified BootOrder that boots
> from disk would not be changed. Several possible fixes/workarounds occur to
> me, one of which would require changes to GRUB, or at least its packaging

Yes; It definitely runs after we've run grub-install and added a new entry.

>
> - Change the algorithm to ensure that the BootOrder item corresponding
>   to "ubuntu" is NOT first -- just blindly demote it by one if it's
>   first in the list, on the assumption that the system booted via
>   the first BootOrder item. This could be done conditional on
>   BootCurrent not existing.
> - Try to extract a PXE-boot option from the Boot#### list and push
>   it to the top. It's likely to be tricky to identify this item,
>   since it's not named in a fully standardized way, in my experience;
>   and some systems have multiple PXE-boot entries, so booting from
>   the wrong one would be inappropriate.
> - Combining the two above, the "ubuntu" entry could be pushed below
>   all identifiable PXE-boot entries.

I think understanding how MAAS pxe config works will matter here.
I can work up a curtin change which moves it past any PXE entries;
Thats worth a test at least.

The other thought I had was if we could find out which entry we've booted
from when BootCurrent is not set ... do you have any info on what we could
probe or look for?


> - Change GRUB packaging so that it can be told to add the GRUB entry
>   to the second position rather than the first one. (OTOH, I don't
>   think that efibootmgr permits this, so this may not be workable.)

Well, I suspect it would look almost exactly like what curtin would do
and could fail in the same way when BootCurrent is not present.

>
> Overall, the first of those seems to be the most sensible one, but I admit
> even it has problems, since the system might have failed over and booted
> from something other than the first of the BootOrder items.

Yeah, looking at some logs from a few tests runs you;'ve done, the new
entry is added at BootEntry 0000, and, the new order pushes 0000 in front
of the previous first boot entry, 0002.  Moving 0000, to second in line
*looks* like it would work.

At this point, for missing BootCurrent; it can't hurt and it might be good
enough in many cases where we wouldn't reboot into the right mode.