Merge lp:~blake-rouse/curtin/uefi-clear-reorder into lp:~curtin-dev/curtin/trunk
| Status: | Merged |
|---|---|
| Merged at revision: | 503 |
| Proposed branch: | lp:~blake-rouse/curtin/uefi-clear-reorder |
| Merge into: | lp:~curtin-dev/curtin/trunk |
| Diff against target: |
544 lines (+450/-4) 4 files modified
curtin/commands/curthooks.py (+66/-1) curtin/util.py (+53/-0) tests/unittests/test_curthooks.py (+261/-3) tests/unittests/test_util.py (+70/-0) |
| To merge this branch: | bzr merge lp:~blake-rouse/curtin/uefi-clear-reorder |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Ryan Harper | 2017-05-10 | Approve on 2017-05-23 | |
| Server Team CI bot | continuous-integration | Approve on 2017-05-12 | |
|
Review via email:
|
|||
Commit Message
Clear and re-order UEFI boot methods during UEFI grub installation.
Previously when installing Ubuntu using curtin it was default to pass '--no-nvram' to the grub-install. This branch reverts that has passing '--no-nvram' will prevent the system from booting if MAAS is down because Ubuntu not be a loader in the EFI system for the system to fallback on. When updating the nvram grub places Ubuntu before the currently booted method, which prevents the ability for the machine to boot from the network anymore. This branch reorders to boot order of the EFI system to place the currently booted method before all others, but Ubuntu is still second in the list so if MAAS is down the machine will still boot from its local disk correctly.
Another issue is that older EFI loaders would be present in the EFI firmware even through curtin deletes and re-creates the entire EFI partition. This removes only those loaders before grub-install is performed to make sure that only the relevant loads for the current state of the system are present.
- 497. By Blake Rouse on 2017-05-10
-
Link bug.
- 498. By Blake Rouse on 2017-05-11
-
Link bug.
PASSED: Continuous integration, rev:498
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
Click here to trigger a rebuild:
https:/
| Ryan Harper (raharper) wrote : | # |
Thanks for working on this.
Let's have a
uefi_get_
which returns a dictionary(ordered, I suppose) with the key, value pairs of the current menu.
That's nicer than reparsing
uefi_remove_
which handles the removal of previously installed File loaders
uefi_set_
which sets the order.
If I understand the flow, we're looking to achieve:
1. removal of any FILE boot menu entries
2. installation of a new entry for what we just installed
3. placing the currently booted method first.
Instead of doing(1) which would end up removing entries that we may not have written
could we instead collect the current entries and order, perform a grub install, collect
the new menu; then set the new boot order with current first,
and pick out of the menu the *new* entry we created? I believe this is more robust
since (3) assumes that the first entry the boot order list is the newly created
boot entry; but does not verify that. There may be non-FILE based entries in the menu
that this code does not consider.
The FILE entry includes the part UUID, which curtin can find since it knowns
the partition that was used for grub install. I think we should ensure that the
second entry should be the newly installed partition.
Also noted in IRC from this morning, we should have unittests for the efibootmgr output manipulation.
Some questions in-line below
| Blake Rouse (blake-rouse) wrote : | # |
> Thanks for working on this.
>
> Let's have a
>
> uefi_get_
>
> which returns a dictionary(ordered, I suppose) with the key, value pairs of
> the current menu.
> That's nicer than reparsing
What is being reparsed? It has to reparse after grub-install because it adds its entry.
>
>
> uefi_remove_
>
> which handles the removal of previously installed File loaders
>
> uefi_set_
>
> which sets the order.
>
>
> If I understand the flow, we're looking to achieve:
>
> 1. removal of any FILE boot menu entries
> 2. installation of a new entry for what we just installed
> 3. placing the currently booted method first.
>
> Instead of doing(1) which would end up removing entries that we may not have
> written
> could we instead collect the current entries and order, perform a grub
> install, collect
> the new menu; then set the new boot order with current first,
> and pick out of the menu the *new* entry we created? I believe this is more
> robust
> since (3) assumes that the first entry the boot order list is the newly
> created
> boot entry; but does not verify that. There may be non-FILE based entries in
> the menu
> that this code does not consider.
No the code only places the current boot loader first. Grub can place the boot entry in whatever order it prefers and I don't want to override that behavior. So I specifically did it this way to prevent the need for curtin to explicitly set the boot order, it just places the current boot loader first.
So I don't see the need to pickout the new entry.
>
>
> The FILE entry includes the part UUID, which curtin can find since it knowns
> the partition that was used for grub install. I think we should ensure that
> the
> second entry should be the newly installed partition.
This should not be needed. The reordering explicitly places the current boot method first that is it. Allowing grub to make the decision on the order and I do not want to override that.
>
> Also noted in IRC from this morning, we should have unittests for the
> efibootmgr output manipulation.
I have pushed a new branch that unit tests all of setup_grub, because sadly it had no unit tests at all. Seems like a critical code path with no unit tests, that is worrying.
>
> Some questions in-line below
| Blake Rouse (blake-rouse) wrote : | # |
I have not split out the methods as I did the unit tests before I saw your review. I will split them out in my next push.
- 499. By Blake Rouse on 2017-05-11
-
Add unit tests for all of setup_grub.
FAILED: Continuous integration, rev:499
https:/
Executed test runs:
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
- 500. By Blake Rouse on 2017-05-12
-
Refactor from code review, add more tests.
- 501. By Blake Rouse on 2017-05-12
-
Capture output of subp.
| Blake Rouse (blake-rouse) wrote : | # |
I have split apart the code and add a new get_efibootmgr util that calls efibootmgr and parses it into a dictionary.
FAILED: Continuous integration, rev:501
https:/
Executed test runs:
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
- 502. By Blake Rouse on 2017-05-12
-
Fix unit tests on trusty-py27 and trusty-py35.
PASSED: Continuous integration, rev:502
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
Click here to trigger a rebuild:
https:/
| Ryan Harper (raharper) wrote : | # |
This looks really good. We can switch the with Chrootable target to use of util.subp(... target=target) which will chroot as needed.
| Ryan Harper (raharper) wrote : | # |
See comment below re: ChrootableTarget; I can add the comment during merge.

PASSED: Continuous integration, rev:497 /jenkins. ubuntu. com/server/ job/curtin- ci/490/ /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-amd64/ 490 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-arm64/ 490 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-ppc64el/ 490 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= vm-i386/ 490
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
Click here to trigger a rebuild: /jenkins. ubuntu. com/server/ job/curtin- ci/490/ rebuild
https:/