Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ways to update grub.cfg with an OSTree update #2052

Closed
clime opened this issue Apr 2, 2020 · 4 comments
Closed

ways to update grub.cfg with an OSTree update #2052

clime opened this issue Apr 2, 2020 · 4 comments

Comments

@clime
Copy link
Contributor

clime commented Apr 2, 2020

Hello,

it seems currently, OSTree is designed to have /boot placed in the root directory of either root partition (there are some quirks with this, however ad. #2047) or a dedicated boot partition. Grub loads grub.cfg and the BLS entries from there to get a kernel and initramfs. And in initramfs then, the root is switched to a particular version of a filesystem.

The problem is how to be able to update also kernel parameters with this. In grub.cfg, there is default_kernelopts variable, which is generated like this:

set default_kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"

I then use this variable to set options in BLS loader entries:

options $default_kernelopts ostree=/ostree/boot.1/transcoder/7cda57c344c1621b70fed57acc7345550780540e60f32457c1b2af1223be7dac/2

(the options from the initial ostree boot loader entry is being carried over into the new entries - only the ostree= param is being modified, that's why this works)

The problem is how to update kernel parameters with this scheme. Some new version of kernel might require a setup of some parameters to function properly for a given use-case (i.e. ACPI needs be switched off for AMD Threadripper, or switched back on when a fix is provided: pcie_aspm= option specifically). The question is how to achieve this because grub.cfg and default_kernelopts hence are not updatable while kernel is.

I know about #479 but it doesn't seem to be yet finished and I am possibly thinking about something slightly else.

I would like to provide static grub.cfg in e.g. /usr/lib/modules/<kernel version> and I would like to have this grub.cfg copied into /boot/grub2/ during deployment, i.e. when the loader entries are regenerated also this grub.cfg file is copied into the place if it exists.

Can something like this be done with OSTree?

Can it be done atomically?

Could you show me some pointers into code where this could be implemented if this functionality doesn't exist yet?

Thank you

@clime
Copy link
Contributor Author

clime commented Apr 2, 2020

I was just informed by a colleague that this approach has a flaw (basically it doesn't work). In grub menu, you don't need to always choose the latest deployment but you can opt for an older one, in which case a wrong grub.cfg would be used.

So I don't know how to do this properly. #479 seems like a good option but it's not finished.

@clime
Copy link
Contributor Author

clime commented Apr 6, 2020

I am going to close this because it was basically non-sense.

To solve the problem with kernel arguments, we currently stopped using ostree admin upgrade and ostree admin deploy and instead created a custom helper script ostree-admin-deploy-with-kargs which checkouts the file at a specific location from the target ref, executes it, reads stdout and interprets the stdout as white-space separated kernel args. I am not sure if the script is needed (i.e. if a static file is not enough). We have it in case we would need to add kernel arguments based on target hardware.

It is unpleasant that ostree admin upgrade and bare ostree admin deploy are off but well at least we've got the problem solved somehow.

@clime clime closed this as completed Apr 6, 2020
@jlarsen45
Copy link

@clime I am needing to be able to update kernel arguments also. Could you share the script/process you came up with to accomplish this?

@clime
Copy link
Contributor Author

clime commented Apr 10, 2020

Well, there is a script with specific name at /usr/lib/modules/<kernelversion>/ in each commit. And for deploying we are using a custom script, which first cheks out that script from that location from the target commit (which should be deployed) and executes it. Standard output of it are whitespace separated kernel arguments. The helper deployment script then calls ostree admin deploy --karg-none --karg=<arg1> --karg=<arg2> --karg=<arg3> ... <target commit> where arg1, arg2, arg3,... are the kernel arguments separated by whitespace read from stdout of the script which was checkouted from the <target commit> in the beginning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants