A release upgrade asked me whether I would like to use the new or old version of /etc/grub.d/10_linux file. I chose the new one, but noticed now that the old (slightly manually patched) file is still there, named 10_linux.dpkg-old.
My understanding is that update-grub will run all the scripts in /etc/grub.d. Since there have been a few bugs fixed in the new version of the 10_linux script, I do not want update-grub to run 10_linux.dpkg-old.
I assume making the old script non-executable using chmod would allow me to keep it in that folder. But I would like to know whether there is some other mechanism preventing update-grub from using it.
Reference of my current understanding: help.ubuntu
The scripts in this directory are read during execution of the update-grub command and their instructions are incorporated into /boot/grub/grub.cfg.
The placement of the menu items in the grub.cfg menu is determined by the order in which the files in this directory are run. Files with a leading numeral are executed first, beginning with the lowest number. 10_linux is run before 20_memtest, which would run before 40_custom. If files with alphabetic names exist, they are run after the numerically-named files.
Custom menu entries can be added to the 40_custom file or in a newly created file. Based on its name, 40_custom entries by default appear at the bottom of the menu. A custom file beginning with 06_ would appear at the top of the menu since its alphanumeric sorting would place it ahead of 10_ through 40_ files.
Only executable files generate output to grub.cfg during execution of update-grub. By default the files in the /etc/grub.d folder are executable.
Yes.
The
grub-mkconfigscript will ignore filenames that match*~or*/\#*\#, and filenames that match*.dpkg-*, or*.rpmsave|*.rpmnew, orREADME*|*/README*, or*.sig.You can trace the script if you want to confirm this with the command
bash -x $(which grub-mkconfig) -o /boot/grub/grub.cfg.