Make use of grub2 environment block

[davidcassany]

This commit sets the grub2 configuration to load /grubenv file, if any,
and checks the next_entry variable to set the default grub2 option.

This is helpful to set default boot in grub only for the next boot. From
cOS it is enough to run grub2-editenv /oem/grubenv set next_entry=recovery to set the next reboot to default to recovery system.

Signed-off-by: David Cassany [email protected]

[davidcassany]

@Itxaka @mudler I could not resist and did a PoC that worked out of the box, so here is the PR :)

With this grub config change we can run grub2-editenv /oem/grubenv set next_entry=recovery and the follow up boot it will default to recovery, but it will default to recovery only once, then it will be unset again. If you'd like to change the empty default to something else you could do grub2-editenv /oem/grubenv set default=fallback and then the default would be set to fallback permanently (obviously only as long as the /oem/grubenv file exists and it is configured as such).

I did not add a tests neither refactored any test since it collides with #382 and I did not want to conflict with it. But it should be pretty straight forward to use that on tests. Also probably a new test for that is not needed since it might be already tested on upgrade or recovery tests.

This PR might also be helpful to define a default reboot behavior in case we detect some obvious error at boot (we are dropped into an emergency shell, no login user is defined, etc.)

[mudler]

Nice! Looks good here and seems shouldn't even have side effects on old installs

[davidcassany]

Nice! Looks good here and seems shouldn't even have side effects on old installs

Correct, that's my understanding too.

[mudler]

Maybe also worth it to add to the docs as well? Easy to forget in PRs, but I see this quite handy in the long run also when debugging things going bad from recovery

[Itxaka]

This is awesome!

[Itxaka]

All tests green, nice change!

[davidcassany]

All tests green, nice change!

Yes, test-recovery had some issues. In fact, I do have concerns about these tests, since we can't get back to the initial state in any way after running cos-upgrade --recovery ..., if we had a way to cos-upgrade --docker-image <img-build-in-opensuse-build> then we could make these tests less error prone.

[Itxaka]

mmmhhh, we maybe be able to get away with mounting a temporal dir from the runner into the vm, but that would imply doing a create-repo with --type docker first and dumping the images into the runner so they are available. Possible but cumbersome.

Or we could rework the serial port stuff so it saves in different files using timestamp and then restore the snapshot functionality, so we get a pristine vm after each test... this seems simpler

[mudler]

mmmhhh, we maybe be able to get away with mounting a temporal dir from the runner into the vm, but that would imply doing a create-repo with --type docker first and dumping the images into the runner so they are available. Possible but cumbersome.

Or we could rework the serial port stuff so it saves in different files using timestamp and then restore the snapshot functionality, so we get a pristine vm after each test... this seems simpler

We could also avoid the docker repo type for tests, and just start an http server on the host (there is a small one embedded in luet for that purpose, luet serve-repo) we are already passing the whole repo between the artifacts. But I'd keep that for few tests, as testing with docker images has its own value as well

[davidcassany]

We could also avoid the docker repo type for tests, and just start an http server on the host (there is a small one embedded in luet for that purpose, luet serve-repo) we are already passing the whole repo between the artifacts. But I'd keep that for few tests, as testing with docker images has its own value as well

That's a nice option indeed.