Manipulate efivars when installing via `lzbt`

nikstur commented

2023-03-06 00:02:15 +00:00

(Migrated from github.com)

We should manipulate the efivars when we install Lanzaboote to point the standard boot entry to the systemd-boot path. This should be implemented via a command line flag ~~that is disabled by default~~. ~~Otherwise~~ Without being able to disable manipulating efivars, testing becomes annoying (i.e. our rust unit tests) and it also makes building disk images much harder.

We should manipulate the efivars when we install Lanzaboote to point the standard boot entry to the systemd-boot path. This should be implemented via a command line flag ~that is disabled by default~. ~Otherwise~ Without being able to disable manipulating efivars, testing becomes annoying (i.e. our rust unit tests) and it also makes building disk images much harder.

👍 1

RaitoBezarius commented

2023-04-14 13:57:49 +00:00

(Migrated from github.com)

Otherwise testing becomes annoying and it also makes building disk images much harder.

I didn't understand this part very well.

> Otherwise testing becomes annoying and it also makes building disk images much harder. I didn't understand this part very well.

nikstur commented

2023-04-14 14:12:15 +00:00

(Migrated from github.com)

If lzbt always manipulates efivars, we cannot run our rust test suite anymore. So we need to be able to disable manipulating efivars to have easy and quick tests for the rest of the system.

👍 1

RaitoBezarius commented

2023-04-14 14:25:25 +00:00

(Migrated from github.com)

If lzbt always manipulates efivars, we cannot run our rust test suite anymore. So we need to be able to disable manipulating efivars to have easy and quick tests for the rest of the system.

This makes sense. Note that we have EFIVARS manipulation in our NixOS tests. :)

> If lzbt always manipulates efivars, we cannot run our rust test suite anymore. So we need to be able to disable manipulating efivars to have easy and quick tests for the rest of the system. This makes sense. Note that we have EFIVARS manipulation in our NixOS tests. :)

👍 1

RaitoBezarius commented

2023-06-16 12:46:09 +00:00

(Migrated from github.com)

Should we fork to bootctl update and logic to handle A/B bootloaders and avoidance of broken systemd boot or should we go all the way and replace bootctl here?

Should we fork to `bootctl update` and logic to handle A/B bootloaders and avoidance of broken systemd boot or should we go all the way and replace `bootctl` here?

nikstur commented

2023-06-16 16:14:50 +00:00

(Migrated from github.com)

Although there is some charm to re-implementing systemd functionality (because we can upstream it) I think we can and should use bootctl for now. I'll implement something. However I don't know how `bootctl can help with an A/B system for bootloaders.

RaitoBezarius commented

2023-06-16 18:12:49 +00:00

(Migrated from github.com)

Although there is some charm to re-implementing systemd functionality (because we can upstream it) I think we can and should use bootctl for now. I'll implement something.

Awesome, I will let you do it then.

However I don't know how `bootctl can help with an A/B system for bootloaders.

Not really, but it's okay :)

> Although there is some charm to re-implementing systemd functionality (because we can upstream it) I think we can and should use bootctl for now. I'll implement something. Awesome, I will let you do it then. > However I don't know how `bootctl can help with an A/B system for bootloaders. Not really, but it's okay :)

Rows
Columns

Manipulate efivars when installing via lzbt #126

Manipulate efivars when installing via `lzbt` #126