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

kernel command line parameters are not being updated #706

Closed
jlarsen45 opened this issue Apr 1, 2020 · 4 comments
Closed

kernel command line parameters are not being updated #706

jlarsen45 opened this issue Apr 1, 2020 · 4 comments

Comments

@jlarsen45
Copy link

I am using intel-corei7-64 with grub as bootloader. If I change my kernel command line parameters the changes do not get updated when an update is performed.

Steps:

  1. make image within Yocto project.
  2. run image on board
  3. view kernel parameters cat /proc/cmdline
  4. change kernel command line parameters (OSTREE_KERNEL_ARGS)
  5. make new image within Yocto project.
  6. update board
  7. view kernel parameters cat /proc/cmdline

Expected result: command line parameters are the new parameters from new OSTREE_KERNEL_ARGS

Actual result: command line parameters are stuck at initial values

@pattivacek
Copy link
Collaborator

Hello @jlarsen45! Unfortunately we don't have a good way of doing what you want to do right now. Currently, OSTREE_KERNEL_ARGS is only used in classes/image_types_ota.bbclass, which is the class used for building the local image, but not the image pushed to Treehub. The reason is that those kernel arguments are passed directly to ostree admin deploy, which for the local image we can call directly. But when updating an image via SOTA, the deploy is done via libostree and since the kernel arguments aren't stored in the image, we can't change them at that time.

If you have ideas on how to change that, I'd be interested to hear your thoughts.

Also, it's worth making sure we're on the same page, so a couple questions:

  • What branch/version of meta-updater are you using?
  • When you say "update board", do you mean over-the-air using Here OTA Connect?

And if you want to see exactly what is happening with that variable, I recommend looking at https://wiki.yoctoproject.org/wiki/Technical_FAQ#I_set_a_variable_but_it_doesn.27t_seem_to_be_having_an_effect.2C_how_do_I_fix_this.3F. But in this case, I think it just isn't getting used the way you want it to be.

@jlarsen45
Copy link
Author

Thanks @patrickvacek for your reply.

I am using meta-updater master branch (36c0d42)
I update my board through OTA connect "community edition"

I think I was too specific in my details. In general, I want to be able to update kernel args with an over-the-air update.
Does ostree have the ability to update kernel args with an update?

It seems like it should. It already modifies the bootloader conf file (grub.cfg in my case). Could it do an update to that file before it does the modifications that switch to boot the new rootfs? Another idea is to keep a kernel arg file along with vmlinuz and initramfs. There is karg handling code in libostree already correct?

@pattivacek
Copy link
Collaborator

I think I was too specific in my details. In general, I want to be able to update kernel args with an over-the-air update.
Does ostree have the ability to update kernel args with an update?

AFAIK ostree does support that, see for example ostreedev/ostree#479 (comment). The problem you're going to face if trying to update with meta-updater is that our update client aktualizr does not currently support changing the kernel args when it deploys a new OSTree commit.

If you want to do it yourself, you might be able to try using the commandline run-mode options of aktualizr and then deploy the OSTree commit yourself, i.e.:

systemctl stop aktualizr
aktualizr check
aktualizr download
ostree admin deploy --karg=<...>
reboot

That might work.

@pattivacek
Copy link
Collaborator

Closing due to lack of feedback.

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