/etc/default/grub.d/50-curtin-settings.cfg overwrites GRUB_CMDLINE_LINUX_DEFAULT

Bug #1527664 reported by Junien Fridrick
This bug affects 12 people
Affects Status Importance Assigned to Milestone

Bug Description


The /etc/default/grub.d/50-curtin-settings.cfg contains the following on a server :
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS1,38400 nosplash"
# disable grub os prober that might find other OS installs.

Hence, making changes to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub is completely useless. I think this behavior is very confusing, and shouldn't be the default.

This comes from : https://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/helpers/common#L643

Is /etc/default/grub.d/50-curtin-settings.cfg supposed to stay after the first successful boot ?

Note that the server has been installed via MAAS.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty


Related branches

Revision history for this message
Scott Moser (smoser) wrote :

this is expected behavior.
if you want to override entirely the best i can tell you is just to write your changes into 99-local.cfg.

Changed in curtin:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Junien Fridrick (axino) wrote :

It may be "expected" behaviour (for who ? because I really didn't expect that), it's still very confusing.

You should at least warn the user that editing /etc/default/grub (which is the expected and documented way to alter grub configuration) is useless.

JuanJo Ciarlante (jjo)
tags: added: canonical-bootstack
Revision history for this message
Alan Meadows (alan-meadows) wrote :

I do not think this should have been dismissed so easily. I agree with Junien. Expected for who?

I think a missing element not mentioned is that if you have customized the kernel parameters in maas for the provisioned node, you will see them in /etc/default/grub, leading you to believe you have discovered the right place to make changes. Only after several hours of frustration and further poking will you realize that although this file reflects the current state, there is another file with the same kernel boot contents in /etc/default/grub.d/50-curtin.cfg that is the actual source of truth.

This is misleading and is not expected behavior in my opinion. At the very least, /etc/default/grub contain null values which would make it clear the true parameters that are authoritative are housed elsewhere.

Revision history for this message
Anthony Wood (z-launchpad-wood-id-au) wrote :

After a clean server install of 18.04, /etc/default/grub.d/50-curtin.cfg is


curtin is not installed on the server; this file should be removed when curtin is finished/removed.

Alternate fixes:
- change the file so it is not so destructive
- get the grub people to change their script so overwriting like this is detected + reported

sudo update-grub
/etc/default/grub.d/50-curtin.cfg is over-riding /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT

Revision history for this message
Scott Moser (smoser) wrote :

I dug a bit on this.
curtin sets 3 things:
 - GRUB_CMDLINE_LINUX_DEFAULT : this is what people are most likely to be bothered by.
 - GRUB_TERMINAL=console

grub somewhat manages GRUB_CMDLINE_LINUX_DEFAULT via 'ucf' and 'debconf' [1].
So what I'm thinking right now is that the right thing for us to do is
edit the setting in /etc/default/grub directly for GRUB_CMDLINE_LINUX_DEFAULT.

To my reading and understanding, it does not handle modifications we
are making.

[1] https://git.launchpad.net/ubuntu/+source/grub2/tree/debian/postinst.in#n375

Revision history for this message
Nobuto Murata (nobuto) wrote :

Or alternatively, curtin could write /etc/default/grub.d/50-curtin.cfg as:
So the variable in /etc/default/grub will be also respected by update-grub.

Revision history for this message
Nobuto Murata (nobuto) wrote :
Revision history for this message
Server Team CI bot (server-team-bot) wrote :

This bug is fixed with commit 22ad20db to curtin on branch master.
To view that commit see the following URL:

Changed in curtin:
status: Triaged → Fix Committed
Revision history for this message
Ryan Harper (raharper) wrote : Fixed in curtin version 18.2.

This bug is believed to be fixed in curtin in version 18.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in curtin:
status: Fix Committed → Fix Released
Revision history for this message
Evren Yurtesen (eyurtese-g) wrote :

I have Ubuntu 19.10 which was upgraded from Ubuntu 19.04. I seem to have the file `/etc/default/grub.d/50-curtin-settings.cfg` and causes this problem. It has the contents

# Curtin disable grub os prober that might find other OS installs.

Not sure what I am suppose to do with this file? The fix only effects installations which were never effected with this problem. I had to remove the `GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"` line manually from there.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers