CoreOS assembler: How to make changes to grub.cfg?

Another question in the context of coreos-config and coreos-assembler (and bootloader)…

I need an advice on how I can customize the grub.cfg. What I want is to have the automatic boot_counter enabled. What I have done:

  1. I removed (some of) the removal of grub2 (in coreos-config)
  2. I added the “updated” grub.cfg to /boot/grub2/ via overlay

Result → cosa build ostree (or metal) does not work anymore pointing to the boot dir saying it is not empty!

Can someone help me, describing what would be the correct way to do such “low-level” changes. I don’t think that running ‘grub2-mkconfig’ is an option here?

Thanks a lot for any advice!

what feature are you interested in by making this change?

The background is a headless installation on bare metal with manual updates. The box is offline and is
only accessible via dedicated (private) network.

Because the box would then not consume the official Fedora updates, I want to have a reliable mechanism to rollback in case of failing updates. Therefore I want to add greenboot in conjunction with bootloader adaptions (actually the stuff which is on current Fedora IoT).

I am just experimenting with the stuff, and maybe Fedora IoT at the end could match better, but I like the idea of coreos to be container focused and one day, the box maybe also would move to the cloud.

If you’re just hacking around and building from scratch, you can just edit cosa’s grub.cfg directly: coreos-assembler/grub.cfg at 02653cad9870a3dd6f2500ce4f3b1962f1c260d4 · coreos/coreos-assembler · GitHub.

Re. automatic rollback, see the upstream issue where we’re discussing it: Determine how to handle automatic rollback · Issue #47 · coreos/fedora-coreos-tracker · GitHub.

I wrote this before my internet suddenly dropped this morning… I’m just going to post it anyway.

You can still consume official Fedora updates. You’d just have to mirror the content locally to your private network first. With ostree/rpm-ostree by itself it’s pretty easy to mirror content, but now we’re using zincati, which asks a server “what updates are available and safe”? We don’t have a good way to do that second part yet IIUC.

We want to use greenboot (or similar mechanism) in Fedora CoreOS too. Maybe you could help us investigate and get our story figured out there: Determine how to handle automatic rollback · Issue #47 · coreos/fedora-coreos-tracker · GitHub

Thanks for explaining. I would recommending not mucking around with grub settings for now if you want the system to be reliable.