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

dbus api to change kernel arguments #594

Closed
cgwalters opened this issue Jan 27, 2017 · 11 comments
Closed

dbus api to change kernel arguments #594

cgwalters opened this issue Jan 27, 2017 · 11 comments

Comments

@cgwalters
Copy link
Member

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
@vtolstov
Copy link

vtolstov commented Jan 27, 2017 via email

@cgwalters
Copy link
Member Author

If anyone wants to edit kernel arguments on an rpm-ostree managed system today, you need to:

  • vi /boot/loader/entries/ostree-*-0.conf

Then if using GRUB2 (most Fedora/CentOS architectures):

If EFI:

grub2-mkconfig > /boot/efi/EFI/fedora/grub.cfg.new && mv /boot/efi/EFI/fedora/grub.cfg{.new,}

If BIOS:

grub2-mkconfig > /boot/loader/grub.cfg.new && mv /boot/loader/grub.cfg{.new,}

@canit00
Copy link

canit00 commented Feb 23, 2017

thank you @cgwalters for providing these steps.

However, I get the following error:

grub2-mkconfig /boot/loader/grub.cfg.new
Generating grub configuration file ...
/etc/grub.d/10_devmode+: line 28: _OSTREE_GRUB2_BOOTVERSION: unbound variable

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.

12: veth6493a05c@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master ovs-system state UP
link/ether 46:0e:05:48:4f:2e brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::3a9b:9270:66da:69de/64 scope link
valid_lft forever preferred_lft forever

grub2_issue.pdf

Is this the right place to post this?

Sincerely,
SA

@jlebon
Copy link
Member

jlebon commented Feb 24, 2017

This used to be an issue in older ostrees. Try:

	bootver=$(readlink /boot/loader)
	_OSTREE_GRUB2_BOOTVERSION=${bootver#*.} \
          grub2-mkconfig -o /boot/loader/grub.cfg

ostreedev/ostree#165
https://github.com/projectatomic/atomic-devmode/blob/master/libexec/bootentry#L45

jlebon added a commit to jlebon/atomic-devmode that referenced this issue Feb 27, 2017
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.
@jlebon
Copy link
Member

jlebon commented Feb 27, 2017

Actually, I misremembered and got confused up above.

However, I get the following error:

grub2-mkconfig /boot/loader/grub.cfg.new
Generating grub configuration file ...
/etc/grub.d/10_devmode+: line 28: _OSTREE_GRUB2_BOOTVERSION: unbound variable

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 /usr/libexec/atomic-devmode/bootentry remove).

jlebon added a commit to projectatomic/atomic-devmode that referenced this issue Feb 27, 2017
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.
@cgwalters
Copy link
Member Author

@peterbaouoft
Copy link
Contributor

Hi, For implementation of the kernel-args command, I have a few doubts. It will be great if you have time to answer them :).
1: What functionality do we want to implement with kernel-args command, do we want to share a similar functionality as ostree admin instutil set-kargs ? ( with the addition of --delete functionality)

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?

@cgwalters
Copy link
Member Author

Based on discussion, I think it'd say:

Let's do this in rpm-ostree kargs first; we can fix ostree later.

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

@cgwalters
Copy link
Member Author

I just made this up but I think it'd be cool if rpm-ostree kargs --edit popped up $EDITOR and allowed you to make arbitrary changes. We have some code for that in ostree commit.

@peterbaouoft
Copy link
Contributor

peterbaouoft added a commit to peterbaouoft/rpm-ostree that referenced this issue Sep 25, 2017
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.
peterbaouoft added a commit to peterbaouoft/rpm-ostree that referenced this issue Sep 25, 2017
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.
peterbaouoft added a commit to peterbaouoft/rpm-ostree that referenced this issue Oct 6, 2017
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.
peterbaouoft added a commit to peterbaouoft/rpm-ostree that referenced this issue Oct 11, 2017
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.
peterbaouoft added a commit to peterbaouoft/rpm-ostree that referenced this issue Nov 2, 2017
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.
rh-atomic-bot pushed a commit that referenced this issue Nov 6, 2017
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
@jlebon
Copy link
Member

jlebon commented Apr 30, 2018

Done in #1013.

@jlebon jlebon closed this as completed Apr 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants