Description of problem: First of all kernel updates seem to be depended on the present of /dev/root which is afaik obsolete on the 21 century and breaks update on initramfs img less setups Secondly kernel updates seem to be ignoring user made changes and adding additional parameters when generating new grub.cfg on updates. Version-Release number of selected component (if applicable): Any kernel update How reproducible: Always Steps to Reproduce: 1. Make custom changes to grub2 configuration files 2. Run grub2-mkconfig -o /boot/grub2/grub.cfg 3. Copy /boot/grub2/grub.cfg to /tmp 4. Update to new kernel 5. Diff the kernel generated /boot/grub2/grub.cfg with the one manually generated in /tmp Actual results: Difference Expected results: No difference Additional info: Any particular reason why kernel updates are not simply calling grub2-mkconfig -o /boot/grub2/grub.cfg on updates ?
Created attachment 547810 [details] Grub cfg generated on kernel update
Created attachment 547811 [details] Grub cfg generated manually from the cli
Created attachment 547812 [details] Diff of both the files
The grubby package deals with this, not the kernel itself.
(In reply to comment #0) > Description of problem: > > First of all kernel updates seem to be depended on the present of /dev/root > which is afaik obsolete on the 21 century and breaks update on initramfs img > less setups Please file this as a separate bug against grubby. > 1. Make custom changes to grub2 configuration files > 2. Run grub2-mkconfig -o /boot/grub2/grub.cfg > 3. Copy /boot/grub2/grub.cfg to /tmp > 4. Update to new kernel > 5. Diff the kernel generated /boot/grub2/grub.cfg with the one manually > generated in /tmp This is the wrong workflow. grub2-mkconfig is only really useful to create the initial configuration file, not to update in general. You shouldn't use it unless you're expecting to clobber old configuration entries and any changes you've made there, which may be necessary in cases where one kernel needs different command line flags than another one. > > Actual results: > > Difference > > Expected results: > > No difference > > Additional info: > > Any particular reason why kernel updates are not simply calling grub2-mkconfig > -o /boot/grub2/grub.cfg on updates ?
(In reply to comment #5) > (In reply to comment #0) > > Description of problem: > > > > First of all kernel updates seem to be depended on the present of /dev/root > > which is afaik obsolete on the 21 century and breaks update on initramfs img > > less setups > > Please file this as a separate bug against grubby. Roger > > > 1. Make custom changes to grub2 configuration files > > 2. Run grub2-mkconfig -o /boot/grub2/grub.cfg > > 3. Copy /boot/grub2/grub.cfg to /tmp > > 4. Update to new kernel > > 5. Diff the kernel generated /boot/grub2/grub.cfg with the one manually > > generated in /tmp > > This is the wrong workflow. grub2-mkconfig is only really useful to create the > initial configuration file, not to update in general. You shouldn't use it > unless you're expecting to clobber old configuration entries and any changes > you've made there, which may be necessary in cases where one kernel needs > different command line flags than another one. In which cases has that been the case and I cant ever recall if updates behaving like this with old grub.cfg changes you made there where honoured during updates. Even if it has ever been the case I could always reboot into older kernel that supported those entries making necessary updates to /etc/default/grub and regenerate grub.cfg After initial installation I made changes to /etc/default/grub and other necessary changes to configuration grub2 configuration files. Upon update grubby completely ignores those changes and just generates well apparently whatever it feel is right like adding UUID entry to the kernel command line after it has been disabled adding initramfs.img to an imitramfs img less setup after it has been disabled etc. Anyway I'm not going to debate this with you here. Grubby is ignoring/overwriting user defined grub2 configuration upon update and given that grub2 is officially is supported by the distribution this becomes an QA issue.