#39 Explicitly mention the `-o` option to `grub2-mkconfig`
Opened 4 years ago by ncoghlan. Modified 5 months ago

While trying to add a kernel debug option to investigate https://bugs.freedesktop.org/show_bug.cgi?id=102765, I made a mistake where I was just running sudo grub2-mkconfig rather than sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg - I mistakenly thought the display on stdout was purely for informational purposes, rather than being a dry-run version of the command.

While https://docs.fedoraproject.org/beta/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader.html did give me the info I needed to eventually figure that out, it could be helpful to include an explicit command sequence that also shows backing up the previous file like:

$ sudo /boot/efi/EFI/fedora/grub.cfg /root/grub.cfg.bak
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

That way if you end up messing up and needing to reboot from a live USB, the old file is readily available for copying back into place.


Also worth mentioning would be cat /proc/cmdline to see whether or not you're getting the kernel config settings you expect.

However, I'm starting to wonder whether this might be better placed somewhere as a "Reporting potential kernel bugs" guide that walks a Fedora user through progressively more difficult steps in helping out with kernel QA by escalating bug reports from Fedora to upstream:

  1. Using a Fedora BZ to get guidance on where to escalate the upstream bug
  2. Collecting basic system info, akin to what ABRT would report (e.g. uname -a)
  3. Collecting standard log output (e.g. dmesg)
  4. Rebooting with modified kernel parameters and checking they've taken effect (e.g. drm.debug=0xe for graphics problems)
  5. Building and booting your own patched kernel with a potential fix applied (OK, most folks won't go this far, but it would be the natural destination for a learning ramp like this)

I haven't needed step 5 myself since 2011 when KDE was triggering a driver memory leak that @whot was able to tell me about, but I'm hoping it might be relevant to me again at some point in relation to the HP Spectre x360's internal monitor issues.

Metadata Update from @darknao:
- Issue priority set to: Low
- Issue tagged with: content

5 months ago

The admin guide is going to be rewritten at some point. We'll come back to it at that time.

Login to comment on this ticket.

Metadata
Boards 1
Documentation Content Status: Backlog