Configure grub with Ubuntu Core 20

device
#1

Hey All,

I’m currently experimenting with Ubuntu Core and wanted to port my existing 18 image to 20. No I’m struggling with the grub configuration.

I need to add something to the kernel boot cmdline. With core18 I had the grub.cfg to do this. With core20 the grub.cfg is gone:

grub: boot configuration is shipped and managed by snapd
https://github.com/snapcore/pc-amd64-gadget/commit/12518c8bdadd12268fc535ffafe40c3d2116a6d3

Unfortunately I’m unable to find any documentation on that topic? Hope someone can give me a hint.

Thanks, and btw: is this the right place to ask about Ubuntu Core? If so, maybe add a category?

#2

I moved your post to the devices category which is for UbuntuCore related questions…

2 Likes
#3

Hi, unfortunately we are a bit behind implementing this feature for UC20, because the kernel command line is sealed against in the TPM for amd64, and so currently we store the kernel command line inside snapd and it is not changeable specifically for amd64 when using encryption. Snapd generates the grub.cfg that used to exist in the gadget snap to enforce that this is used.

We are aiming to soon enable the gadget snap to specify additional kernel cmdline arguments through a structured manner, but that feature is not yet implemented.

As a workaround, if you are not using encryption, you can manually edit the grub.cfg files on the ubuntu-seed and ubuntu-boot partitions after the system has finished installing (i.e. after you run console-conf). You could also do this with encryption enabled, but then the device would not be able to finish booting because it wouldn’t be able to unlock the encrypted data partition from the initramfs.

1 Like
#4

Hi,

Thank you for the explanation. In this case, I guess I will wait for the release of this feature.

#5

@ijohnson I also find myself in need of this feature because UC20’s default cmdline value for grub.cfg specifies “console=ttyS0”, which interferes with a connected serial device.

  1. Is the interface you mentioned available at this point?
  2. When describing the interface, you specifically mentioned it’d allow one to “specify additional kernel cmdline arguments” (emphasis mine). As noted above, I’m looking to remove console=ttyS0 from the default value of cmdline. Would that be possible through this interface?
#6

Once the feature is available, the gadget snap will be able to ship a file which provides arguments that shall be either appended to the command line or override it (with the exception some arguments set by snapd that are used during boot).

#7

instead of adding more and more to the gadget, which forces people into re-builds, should we not perhaps focus on extending model assertions with setting of default configurations and interface connections to prevent users from rolling custom gadgets for minor config/connection adjustments ?

#8

Not sure about connections, the original question was about kernel command lines. We did not mention this will be behind an interface.

Anyways, connections and model assertions sounds like material for a separate topic with more people involved.

#9

no, it will be a defaults: entry which forces you to have your own gadget.yaml.

i mentioned connections: simply because they are in the same boat … both are minor adjustments most/many users need for their images and both force a custom gadget making things harder than they should be (IMHO)

PS: but i agree it should be its own topic …

#10

My original issue was btw solved, when I realized that “console=ttyS0” is specified by default. Still, I would prefer to have the possibility to change the baud rate.
For such a simple change, I would expect it should not be necessary to build a custom gadget snap. But I think ether way will work fine.

#11

Well customizing the kernel command line is something that definitely should be forcing a custom gadget snap, since you can have radically different behavior for the same set of snaps with new kernel command lines, so we don’t want to say that the Canonical pi gadget and Canonical pi-kernel snaps are fully supported with any random kernel command line that folks put in their model assertion, they are specifically supported with the kernel command line that we have tested them with. This same line of reasoning also arguably applies to connections and defaults in that you can make radical changes to a system through those changes that may not be fully tested or supported.

I agree we should make it easier to do these things, but at the same time we need to be careful to ensure that we are not making a false assertion of support by enabling folks to use the upstream kernel/gadget snaps in a way that we can’t support.

2 Likes