2

If you cat /boot/grub2/grub.cfg, you get the big block of text telling you DO NOT MANUALLY EDIT THIS FILE, indicating that you should instead edit files in /etc/default/ instead and then run grub2-mkconfig to update the /boot/grub2/grub.cfg file.

My question is this: why is it emphasized so strongly that one should not edit the grub.cfg file by hand?

My understanding is that changes made will not be persistent across updates and such. This seems annoying, but it doesn't seem to be that big a deal. Am I missing something?

Liam
  • 278
  • 2
  • 8
  • this is my opinion and an opinion only: people who think they are hot-shot sysadmins and know what they are doing, manually edit every possible file, leave behind a single, hard to notice typographical error and mess up everything. Consider grub.cfg comes before even your OS starts to load. Making an error in this one, render your system useless. The warning signs are there to deter people who really don't know what they are doing from shooting themselves in the foot. – MelBurslan Feb 05 '16 at 20:36
  • @MelBurslan So it's an additional safety feature added in grub2? – Liam Feb 05 '16 at 20:37
  • the answer is inside it head /boot/grub/grub.cfg , if you wich to edit grub stuff : edit files inside /etc/grub.d/ – Yunus Feb 05 '16 at 21:30
  • Historically, the scripts that updated the /boot/grub/menu.lst of GRUB Legacy tried to maintain any manually edited kernel options and other customizations. I think the GRUB authors and distro maintainers realized that this was a fragile hack that would soon break if GRUB configuration syntax grew any more complex... and with GRUB 2, it did. So the new scheme was developed to allow heavier customization without impairing auto-updates. The problem is in teaching the new way to all the people used to the old way. – telcoM May 04 '18 at 12:54

2 Answers2

3

First directly editing is not a reliable method because this file is the result of various scripts which build the menu in sections.

But mainly every time you upgrade to a new kernel (installations/removals, updates) your /boot/grub/grub.cfg will be overwritten and you will lose your changes.

Thats why you should not directly edit it.

  • There are valid reasons for doing so. For instance: http://unix.stackexchange.com/questions/323749/background-image-manual-grub-cfg – Elder Geek Nov 17 '16 at 09:06
  • Elder Geek, your example is about creating a bootable flash drive with a heavily customized boot loader. Of course there can be other situations... However, there is one more tier between editing /etc/default/grub and directly modifying /boot/grub/grub.cfg: you can add your own files (or modify the existing ones) in /etc/grub.d. That will probably cover at least 90% of the situations that cannot be handled by just editing /etc/default/grub, and still allows the distribution's standard bootloader update procedures to keep working, so kernel updates won't undo the customizations. – telcoM May 04 '18 at 12:41
0

I personall think its silly. I would prefer that the grub software creates an easy tool for automatic grub.cfg generation (which they basically already have) and allow users the option to use it. I personally needed to remove a few lines from my grub.cfg because it wants to boot into an operating system which no longer exists. Everytime I grub-update it adds those menu entries again. It's really annoying and unnecessary. (I Know I could learn how to do this properly with the grub.d documents, but I'm lazy.) Obviously you need to practice due caution editing the grub.cfg, but as long as you always maintain a working fallback you can boot into os, and you don't need to be able to boot into os to edit the grub.cfg (live disk and the grub editing tools both allow you to do this). Also I should probably learn why grub still thinks my old arch install is on disk.

  • You could try os-prober, that cleared an old OS from my system many moons ago. Also, grub2 wiki: https://fedoraproject.org/wiki/GRUB_2 – thecarpy May 04 '18 at 11:08