Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd sysroot.bootloader repo config key (fix running bootloader when no deployments exist) #1814
Conversation
This comment has been minimized.
This comment has been minimized.
|
Related: #1719 I need to dive into this more; not entirely sure it's right (but it doesn't seem necessarily wrong either). There's risk here in changing the grub backend. I know it's more work but if we can get FCOS systems into having a static grub config (i.e. ostree only writes BLS snippets, use the grub BLS plugin) the whole architecture is much clearer. |
a4c4d69
to
234b07b
This comment has been minimized.
This comment has been minimized.
|
Thanks @cgwalters - just pushed a change.
Agreed on the risk - I think now this is a question of "could this change break existing systems that might have been relying on the existing deployment being used rather than the pending". I'm interested in taking a look at using the BLS plugin in OSTree - I need to read into it more, but now that I've had a look at the bootloader code a bit better, I think I can see what would need to be changed. |
234b07b
to
307b5cc
This comment has been minimized.
This comment has been minimized.
|
As part of this, going to start on an implementation for writing the BLS config, and a way to configure the bootloader (something like #1801 (comment)). One way after brief discussion is to have OSTree always write BLS configs, and ship with a config |
This comment has been minimized.
This comment has been minimized.
That's what ostree has done since the very start. The BLS configs are canonical. But at the time RHEL7's grub didn't speak BLS (actually no bootloaders did really) so I added the concept of a "bootloader backend" to ostree as a temporary hack. libostree never reads the grub config - it reads the BLS configs it writes as the source of truth. |
This comment has been minimized.
This comment has been minimized.
Ahh that's clear to me now, thanks!
So what's needed is really having a switch in the bootloader backend to use or not use it (at least for the grub2-mkconfig part), and a way to configure that switch (through |
e5bb2c0
to
dd38a31
This comment has been minimized.
This comment has been minimized.
|
Dropped the edits to the grub2 bootloader code, and started on adding a WIP, with the following left to do:
Right now I'm testing with the following commands:
On
Repeating the previous commands with
|
a71ade1
to
e068e86
|
Just various things I noticed from a quick review! |
98b2788
to
ee14d6d
Prep commit as part of ostreedev#1814, where a new `sysroot` group is added to the repo config. This allows falling back to a default key value if the specified group does not exist in the config file.
This comment has been minimized.
This comment has been minimized.
|
I'm thinking bd082ad is a clean way to make the So far, the A problem I see with this is not giving the user an error if for some reason |
This comment has been minimized.
This comment has been minimized.
|
Hmm - seeing the tests for keyfile utils https://github.com/ostreedev/ostree/blob/master/tests/test-keyfile-utils.c#L126, probably best to keep the API as it is and instead only make the |
288fb49
to
d6ab97c
Rename ot_keyfile_get_string_as_list() to ot_keyfile_get_string_list_with_separator_choice() which expresses more clearly why the function is needed. Also shorten the function comment.
The sysroot.bootloader key configures the bootloader that OSTree uses when deploying a sysroot. Having this key allows specifying behavior not to use the default bootloader backend code, which is preferable when creating a first deployment from the sysroot (#1774). As of now, the key can take the values "auto" or "none". If the key is not given, the value defaults to "auto". "auto" causes _ostree_sysroot_query_bootloader() to be used when writing a new deployment, which is the original behavior that dynamically detects which bootloader to use. "none" avoids querying the bootloader dynamically. The BLS config fragments are still written to sysroot/boot/loader/entries for use by higher-level software. More values can be supported in future to specify a single bootloader, different behavior for the bootloader code, or a list of bootloaders to try. Resolves: #1774
Add ot_keyfile_get_value_with_default_group_optional() which allows getting values from keys where the group is optional in the config file. This is preparatory to add the sysroot.bootloader repo config key, where the sysroot group is optional.
c76fb65
to
2c3cd83
This comment has been minimized.
This comment has been minimized.
|
Updated, and fixed the commit messages! |
This comment has been minimized.
This comment has been minimized.
|
Also split 5b5093f into its own commit (previously added tests for |
This comment has been minimized.
This comment has been minimized.
|
Awesome, LGTM! |
This comment has been minimized.
This comment has been minimized.
The sysroot.bootloader key configures the bootloader that OSTree uses when deploying a sysroot. Having this key allows specifying behavior not to use the default bootloader backend code, which is preferable when creating a first deployment from the sysroot (#1774). As of now, the key can take the values "auto" or "none". If the key is not given, the value defaults to "auto". "auto" causes _ostree_sysroot_query_bootloader() to be used when writing a new deployment, which is the original behavior that dynamically detects which bootloader to use. "none" avoids querying the bootloader dynamically. The BLS config fragments are still written to sysroot/boot/loader/entries for use by higher-level software. More values can be supported in future to specify a single bootloader, different behavior for the bootloader code, or a list of bootloaders to try. Resolves: #1774 Closes: #1814 Approved by: jlebon
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
@rh-atomic-bot retry |
This comment has been minimized.
This comment has been minimized.
The sysroot.bootloader key configures the bootloader that OSTree uses when deploying a sysroot. Having this key allows specifying behavior not to use the default bootloader backend code, which is preferable when creating a first deployment from the sysroot (#1774). As of now, the key can take the values "auto" or "none". If the key is not given, the value defaults to "auto". "auto" causes _ostree_sysroot_query_bootloader() to be used when writing a new deployment, which is the original behavior that dynamically detects which bootloader to use. "none" avoids querying the bootloader dynamically. The BLS config fragments are still written to sysroot/boot/loader/entries for use by higher-level software. More values can be supported in future to specify a single bootloader, different behavior for the bootloader code, or a list of bootloaders to try. Resolves: #1774 Closes: #1814 Approved by: jlebon
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
AdrianVovk
commented
Mar 2, 2019
|
|
This comment has been minimized.
This comment has been minimized.
|
Thanks :) |
rfairley commentedFeb 8, 2019
•
edited
The sysroot.bootloader key is used to configure the bootloader
that OSTree uses when deploying a sysroot. Having this key
allows specifying behavior not to use the default bootloader
backend code, which is preferable when creating a first
deployment from the sysroot (#1774).
As of now, the key can take the values "auto" or "none". If
the key is not given, the value defaults to "auto".
"auto" causes _ostree_sysroot_query_bootloader() to be used
when writing a new deployment, which is the original behavior
that dynamically detects which bootloader to use.
"none" avoids querying the bootloader dynamically. The BLS
config fragments are still written to
sysroot/boot/loader/entries for use by higher-level software.
More values can be supported in future to specify a single
bootloader, different behavior for the bootloader code, or
a list of bootloaders to try.
Resolves: #1774