I have a number of systems on which I need to modify the kernel cmdline, adding a few options.

At the moment I do it using the following procedure:

  1. Open /etc/default/grub
  2. Modify GRUB_CMDLINE_LINUX_DEFAULT, adding the options
  3. Run update-grub
  4. Reboot

However, I would prefer to automate this process as a part of a packet installation, and avoid modifying the default file (as this is generally brittle).

What I would want to do is something like:

  1. Drop a file (in /etc/grub.d/?), overriding GRUB_CMDLINE_LINUX_DEFAULT or similar
  2. Run update-grub and reboot

There are a pile of scripts in /etc/grub.d/* which are used to build the actual menu config, however, there is no obvious way to interact with them. The script which generates the config only seems to read /etc/default/grub :(

Can somebody enlighten me if there is a way to drop a file to modify the default kernel commandline?

  • 1
    How about using diff and patch to change /etc/default/grub in one step? This would also be future proof, because if the package-provided file ever changed in structure, your patch would no longer apply cleanly, rather than overwriting stuff without any safeguards (as dropping in files would do). – sysconfig Dec 9 '14 at 11:01
  • @sysconfig: I kind of like that approach, but I am not sure how well uninstall/reinstall would work. Just doing a reverse patch and then barfing on uninstall if the file doesn't match seems like it could easily break. I also think that patching config files of other packages is considered bad form in Debian/Ubuntu packaging, but I may be wrong. – pehrs Dec 9 '14 at 13:33
  • Patching configs per say shouldn't really be bad practice. They are there for a reason, and most services don't use a whatever.d directory approach to add in things, but require to change their main config. Not entirely sure right now how apt handles it, but rpm for example won't touch modified files in /etc during updates. Patch is safe, because if it doesn't apply, it doesn't change anything, and it's repeatable and simple. I'm sure there's a way to leverage grub.d to the same effect, but I hate grub2 and can't advise, hence a comment and not an answer from me. :) – sysconfig Dec 9 '14 at 13:47
  1. Create the directory /etc/default/grub.d if it doesn't exist already.
  2. Create a file /etc/default/grub.d/myextraoption.cfg adding to the variable you want (Append to it only, with an extra space. You want to be careful to not clobber or mangle any existing data there.):

  3. Run update-grub.

You should be able to safely include a yourpackage.cfg file in your package without risk of it being overwritten or clobbering something else. Any of those .cfg files are included after the main default file, so just be aware of that and plan accordingly.

You will almost certainly also want a postinst script to run update-grub when your package is installed, and just to be safe since it is in /etc you should probably also include it in conffiles in your package. I think though that this will leave it behind unless a purge of the package is done, so dealer's choice on that part.

For reference, /usr/sbin/grub-mkconfig on or around line 157 is what reads the default files, including anything matching /etc/default/grub.d/*.cfg. It seems likely to me that this situation is exactly why it does so.

I wrote this based on Trusty. I don't know how far back in releases this is still applicable. I just checked Lucid and it is not there. It is there in Precise.

  • This was my first thought, but I tried exactly this on 14.01.1 (Trusty), and it has no effect. I think that the default menu options are generated from 10_linux, but regardless of if I name the file as 05_xxx or 15_xxx it is not reflected in the config generated. I know the file is sourced, as if I make a typo in it the update-grub fails. – pehrs Dec 15 '14 at 9:46
  • 1
    I think you're mixed up by the two different but similar locations and config files. /etc/grub.d and /etc/default/grub.d do very different things. /etc/grub.d has the XX_ files in it. That is not the right location for what I described. /etc/default/grub.d is what you want. Re-read my instructions carefully and give it another go. – Jeff Snider Dec 15 '14 at 15:06
  • Gaaaa! Thanks for the hand holding! That was indeed the solution. Remind me to stab the guy who designed this mess with a rusty spoon when I get the chance. – pehrs Dec 15 '14 at 15:20

grub 2.02 appears to source files matching /etc/default/grub.d/*.cfg in addition to /etc/default/grub.

Maybe this works on whatever version your Ubuntu has, too.

  • It does at least since grub-common_1.99-21ubuntu3.17, i.e. Precise Pangolin with added in precise-updates repository. Maybe you can elaborate on your answer and give @pehrs some steps to follow and an example config file, because your solution integrates well. – blubberdiblub Dec 14 '14 at 14:39
  • I have found the config files, but I would prefer not to modify them. Is there a way to change the default cmdline without modifying the files? – pehrs Dec 15 '14 at 9:39

As per the grub documentation, you may find it useful to edit the /etc/grub.d/40_custom file with grub-mkconfig;

/etc/grub.d/40_custom is particularly useful for adding entire custom menu entries; simply type the menu entries you want to add at the end of that file, making sure to leave at least the first two lines intact.

Perhaps you could grab one of the first entries and copy it to the end of that config, and append your desired options? This should be future-proof as it's basically preserving the existing config and appending your custom config as a supplementary menu-option.

Edit: I realise that you requested that it be the default line, but the above is a compromise of the edit with a less potentially-destructive methodology (and in any case, you could choose to use grub-mkconfig to perform a more bold task such as changing the default)

  • I think it's better to patch the default/grub file in this case, but editing 40_custom can certainly be an option as well. – pehrs Dec 15 '14 at 9:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.