Issue #39: Explicitly mention the `-o` option to `grub2-mkconfig` - docs-fp-o

fedora-docs / docs-fp-o

#39 Explicitly mention the `-o` option to `grub2-mkconfig`

Opened 7 years ago by ncoghlan. Modified 2 years 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.

ncoghlan commented 7 years ago

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:

Using a Fedora BZ to get guidance on where to escalate the upstream bug
Collecting basic system info, akin to what ABRT would report (e.g. uname -a)
Collecting standard log output (e.g. dmesg)
Rebooting with modified kernel parameters and checking they've taken effect (e.g. drm.debug=0xe for graphics problems)
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.