Bug 2036520
| Summary: | BLS entries don't contain "options $kernelopts" but "options <list of kernel options used by current boot>" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Renaud Métrich <rmetrich> |
| Component: | grub2 | Assignee: | Javier Martinez Canillas <fmartine> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | fmartine, lkundrak, pgnet.dev, pjones, rharwood, vpolasek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-08 08:59:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hello Renaud, That's expected after https://src.fedoraproject.org/rpms/grub2/c/4a742183a39f344a7685bccdc76d5e64dea3766a. The rationale is explained in the commit message: commit 4a742183a39f344a7685bccdc76d5e64dea3766a Author: Javier Martinez Canillas <javierm> Date: Wed May 6 19:13:01 2020 +0200 Store cmdline in BLS snippets instead of using a grubenv variable The kernel cmdline was stored as a kernelopts variable in the grubenv file and the BLS snippets used that. But this turned out to be fragile since the grubenv file could be removed or get corrupted easily. To prevent the entries to not have a cmdline if the grubenv can't be read, a fallback variable was set in the GRUB config file. But this still caused issues since the config needs to be re-generated to change the parameters. Instead, let's store the cmdline in the BLS snippets. This will make the configuration more robust, since it will work even without the grubenv file and the BLS entries will contain all the information needed to boot. Signed-off-by: Javier Martinez Canillas <javierm> The kernelopts variable has not been removed yet because users could have old BLS snippets still referring to it. But probably is time to also drop it from the grub2.cfg generation. |
Description of problem: Unlike on RHEL8, the 20-grub.install file loaded by Fedora's grub2.spec file doesn't use "options \$kernelopts" but "option $kernelopts", which ends up creating a BLS entry with currently used kernel boot args: RHEL8 file: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- title ${NAME} (${kernelver}) ${VERSION}${debugname} version ${kernelver}${debugid} linux /vmlinuz-${kernelver} initrd /initramfs-${kernelver}.img options \$kernelopts ... -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Fedora file: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- title ${NAME} (${kernelver}) ${VERSION}${debugname} version ${kernelver}${debugid} linux /vmlinuz-${kernelver} initrd /initramfs-${kernelver}.img options ${kernelopts} ... -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Is there a good reason for not having \$kernelopts on Fedora? I think it's a bug. It breaks my entries upon kernel update, say for example I boot with "ip=dhcp" once and update the kernel, I get this "ip=dhcp" in the entry, hence a runtime argument become sticky. Additionally this makes all the $kernelopts grubenv variable completely useless and not usable anymore. Version-Release number of selected component (if applicable): grub2-common-2.06-11.fc36.noarch How reproducible: Always Steps to Reproduce: 1. Boot with some one-shot kernel argument (e.g. "ip=dhcp") 2. Update the kernel Actual results: BLS entry for new kernel now has "ip=dhcp" and no "$kernelopts" variable reference Additional info: Now say you want to update $kernelopts in grubenv or through editing /etc/default/grub, this won't have any effect even with running grub2-mkconfig unless you edit all BLS entries for current kernels with "options $kernelopts".