-
Notifications
You must be signed in to change notification settings - Fork 192
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
dbus api to change kernel arguments #594
Comments
2017-01-27 18:30 GMT+03:00 Colin Walters <notifications@github.com>:
This would abstract things a bit, be more reliable since we'd do atomic swaps rather than having admins do vi or something on /boot/loader/entries/ostree-fedora-0.conf etc.
$ rpm-ostree kernel-args
rd.lvm.lv=fw/root rhgb quiet root=/dev/mapper/fw-root
$ rpm-ostree kernel-args --append foo=bar baz=whee
$ rpm-ostree kernel-args --delete foo
Nice feature, in which cases and how ostree/rpm-ostree use this
entries? If i modify it via vi, does rpm-ostree upgrade use this
options when generate grub conf?
…--
Vasiliy Tolstov,
e-mail: v.tolstov@selfip.ru
|
If anyone wants to edit kernel arguments on an rpm-ostree managed system today, you need to:
Then if using GRUB2 (most Fedora/CentOS architectures): If EFI:
If BIOS:
|
thank you @cgwalters for providing these steps. However, I get the following error:
Our goal is to disable IPv6 on all of our Atomic hosts running containerized OpenShift. Unfortunately, disabling this through NetworkManager or in /etc/sysctl.d/ does not appear to be working. The root of this want leads back to our IPF routers consistently going down and want to get rid of the vast log entries for IPv6. This is what I see when issuing ip -a that leads me to believe that IPv6 isn't disabled.
Is this the right place to post this? Sincerely, |
This used to be an issue in older ostrees. Try:
ostreedev/ostree#165 |
Our hook was breaking the workflow for people who manually wanted to call grub2-mkconfig because we expected _OSTREE_GRUB2_BOOTVERSION to always be available. See e.g.: coreos/rpm-ostree#594 Instead, we should use the same logic as `ostree admin instutil grub2-generate`: target _OSTREE_GRUB2_BOOTVERSION if available, otherwise, just target the current bootversion.
Actually, I misremembered and got confused up above.
This isn't the same ostree bug, but a different atomic-devmode one. Should be fixed by projectatomic/atomic-devmode#9. You'll have to use the workaround above in the meantime though (or alternatively, if you have no use for the Developer Mode feature, you can disable it with |
Our hook was breaking the workflow for people who manually wanted to call grub2-mkconfig because we expected _OSTREE_GRUB2_BOOTVERSION to always be available. See e.g.: coreos/rpm-ostree#594 Instead, we should use the same logic as `ostree admin instutil grub2-generate`: target _OSTREE_GRUB2_BOOTVERSION if available, otherwise, just target the current bootversion.
Hi, For implementation of the kernel-args command, I have a few doubts. It will be great if you have time to answer them :). 2: due to the similarity of these two commands, do we want to possibly use some of the functions that are already developed in ostree? 3: Do we need to worry about the grub related issues after users modify the conf file? |
Based on discussion, I think it'd say: Let's do this in Most of the API that lives in libostree today should be enough - if not, let's extend the ostree API? As far as point 3) - let's not worry about it for now, this will fix itself if we eventually do ostreedev/ostree#717 |
I just made this up but I think it'd be cool if |
This is initial groundwork for coreos#594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands.
This is initial groundwork for coreos#594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands.
This is initial groundwork for coreos#594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands.
This is initial groundwork for coreos#594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands.
This is initial groundwork for coreos#594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands.
This is initial groundwork for #594. This commit sets up most of the required front end logic( arg parsing, transaction handling), and will be used in the following commits. There is nothing really fancy in this commit, as most of the code shares the similar style between other dbus related commands. Closes: #1013 Approved by: cgwalters
Done in #1013. |
This would abstract things a bit, be more reliable since we'd do atomic swaps rather than having admins do
vi
or something on/boot/loader/entries/ostree-fedora-0.conf
etc.The text was updated successfully, but these errors were encountered: