-
Notifications
You must be signed in to change notification settings - Fork 355
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
rpmostreepayload: Set bootloader=none #2752
rpmostreepayload: Set bootloader=none #2752
Conversation
Hello @cgwalters! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found: There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻 Comment last updated at 2020-07-23 13:27:47 UTC |
(Totally untested BTW, it's been a while since I've developed on Anaconda) |
957876a
to
f6aaa8d
Compare
Jenkins, it's ok to test. |
Hi, @martinezjavier I think this could be an interesting change for you. So just a heads-up. |
Please, use |
I wasn't able to test it with Fedora-Silverblue-ostree-x86_64-Rawhide-20200721.n.0.iso because of the bug https://bugzilla.redhat.com/show_bug.cgi?id=1857530. |
This matches coreos/coreos-assembler@311768c We don't need OSTree generating a new GRUB2 config everytime now since we embed a static GRUB2 config. Tell OSTree to just update the BLS entries using `sysroot.bootloader=none`. This gives a nice speedup as well at finalization time since we no longer call `grub2-mkconfig`. This only takes effect on new installs (here in Anaconda); since we're going to be installing an updated bootloader (e.g. GRUB2) which should parse the BLS fragments that OSTree generates.
f6aaa8d
to
2f37ac6
Compare
Sure, done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me too. Thanks for your contribution!
Thanks a lot for testing this! I think the problem might be we were relying on the side effect of running Something like
? |
FWIW, openQA actually relies surprisingly heavily on the 5 second grub timeout which anaconda writes to If this is merged in such a way that the installed system has a bootloader timeout of 1 second, it would be a problem for IoT testing, because several of the tests we run on IoT installs rely on this kernel command line editing. The other ostree installer image we test is Silverblue, but at a quick check, none of the tests we currently run on that image rely on this mechanism. |
Btw. I have tried the fix suggested in #2752 (comment), but the installed system still doesn't boot. Based on some warnings in the logs, I have tried the changes below, but it didn't help. Unfortunately, I don't understand this part well enough to be helpful.
|
I think it's better for the test harness to manipulate the image offline for that; see e.g. coreos/coreos-assembler#1265 (There's also more recently work on Ignition kargs coreos/ignition#1168 ) |
Hi @cgwalters any idea why the last test still won't boot? It would be great to push this a bit. |
This PR is stale because it has been open 60 days with no activity. |
This PR was closed because it has been stalled for 30 days with no activity. |
This matches
coreos/coreos-assembler@311768c
Since we're doing a new install, we're going to be installing an
updated bootloader (e.g. GRUB2) which should parse the BLS fragments
that OSTree generates. There's no reason for ostree to rerun
grub2-mkconfig
.