© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
@Ryan,
Is it the /var/log/
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.
From what state does the algorithm you posted begin? As I understand it (I 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 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
- 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.
- 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.)
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.