$tuned_initrd and $tuned_params are not initialised in grub.cfg after updating to Fedora 41

[mikebeaton]

When upgrading to Fedora 41, $tuned_initrd and $tuned_params are inserted into /boot/loader/entries files for all kernels, e.g.:

initrd /initramfs-6.11.5-300.fc41.x86_64.img $tuned_initrd
options root=UUID=2ab82b06-905c-4f00-a3c6-7782accb6547 ro rootflags=subvol=root rhgb quiet $tuned_params

but corresponding blank values are not inserted into /boot/grub2/grub.cfg.

Empty values only appear in grub.cfg after we re-run grub2-mkconfig or if we install a TuneD profile which actually uses these values (e.g. with [bootloader] cmdline_...=... &/or initrd_add_img=...).

The absence of these values does not cause any actual issue in booting, but it goes against a fairly stable convention that grub variables are always defined if referred to. (And makes it harder for any third party software which wants to parse loader/entries, and relies on this convention, to do its work.)

TuneD also inserts the values for tuned_initrd and tuned_params into grubenv. Setting aside the issue of whether this is really wise (grubenv has very limited space and these variables can be long; it is not clear why they are needed in both places?), it looks as if a quick fix could involve adding initial blank values in either place.

[yarda]

Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2323514

There is also fedora-devel discussion.

[mikebeaton]

Thank you. I guess the Fedora-level discussion has no public link?

I think you would have meant https://discussion.fedoraproject.org/t/kernel-install-92-tuned-install-is-conflicted-with-systemd-boot/134899

@yarda - Please can I just mention these are both discussing something slightly different? Namely how this breaks sd-boot. To be completely specific, the problem I have is that (the Linux loader I work on is only broken here because...) there is no value for these variables available to parse from grubenv or grub.cfg (as mentioned above), even though code to reference the (unset) values is added in loader/entries, so this is a slightly separate, albeit closely related, issue.

It seems to me that the issue is something like: if you add TuneD to an existing system, then it does not automatically set initial values for its variables in grub.cfg, even though it sets up code which will consume these (unset) variables in /loader/entries. Which is not fatal, but probably not ideal. Maybe this is just a matter of whether grub2-mkconfig gets called or not, though I am not entirely sure.

[yarda]

It's set on two places because IMHO grub can run in BLS and non-BLS mode.

Exact reproducer is just to upgrade Fedora from F40 to F41?

And then the problem doesn't reappear?

[mikebeaton]

It's set on two places because IMHO grub can run in BLS and non-BLS mode.

You wouldn't need the values in grubenv for either mode. The variables just need to appear in grub.cfg before the grub blscfg command is called, if in BLS mode; or in grub.cfg before they are used, if in non-BLS mode.

Exact reproducer is just to upgrade Fedora from F40 to F41?

Yes.

And then the problem doesn't reappear?

I believe the issue is that grub.cfg is never updated (&/or is updated at the wrong time?). Once it has been updated and the values are present, they do not disappear again.

[mikebeaton]

We're adding support for multiple initrd files in one GRUB2 blscfg /loader/entries initrd line to our loader; while still assuming that non-blscfg distros (i.e. 'pure' blspec) have only one file listed per initrd line. We already had grub variable expansion in options^†, we have now added it for initrd lines too. Both of these are fine, we want to boot what's out there, not join a war about blspec purity!

For now, at least, we are continuing to assume that grub variables should be initialised, and that if they are not, this should be a DEBUG ASSERT, and cause the entry not to be used even in RELEASE - we want to avoid incorrect boots - but we have added a work-around specifically for the two TuneD variables which we know may (currently) be referenced but not initialised on some distros.

acidanthera/OpenCorePkg#565

---

^†CentOS is one distro which uses grub vars in options lines - hence the reason for their support there already - and I now understand you've been in CentOS for a while. However git blame on the TuneD repo shows that there was never a time when you had $tuned_params but not yet $tuned_initrd in loader/entries .conf files, so I'm still not entirely clear whether it was specifically a TuneD variable which prompted us to add this support in the first place! EDIT: Possibly/probably our support for this comes from examining a CentOS 6 distro, which I believe would have had $kernelopts in options but not the TuneD vars in options and initrd.