No way to update kernel cmdline via gadget snap update

Bug #1664388 reported by Tony Espy on 2017-02-13
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Undecided
Unassigned

Bug Description

There currently doesn't appear to be any way to update the kernel parameters on a grub based system running Ubuntu core via a gadget snap update.

In my particular instance, I'd like to change the value of panic=-1 to panic=0, as the device in question has a hardware watchdog timer enabled, and systemd is configured to use it.

Although it's possible to do override this for initial image builds by dropping a file in /etc/sysctl.d/ with:

kernel.panic = 0

...this file won't get picked up on gadget snap update either.

This bug is being reported on an Ubuntu Core 16 system running snapd 2.22.

Tags: ce Edit Tag help
Tony Espy (awe) on 2017-02-13
affects: snappy → snapd

For the certified kernels, I am not sure we want an open-ended "stick
this on the kernel cmdline" mechanism. We probably DO want a
parameterized "here are some well-behaved things you can enable or
disable in your gadget snap".

I can see the argument that for a brand-specific kernel, you get
whatever you want, and the result is uncertified.

Mark

Oliver Grawert (ogra) wrote :

note that you can easily manage the panic parameter via sysfs ...

while the gadget (sadly) does not update the bits in /boot whihc is indeed quite a bad thing) you can work around this by shipping a systemd unit in your gadget that simply does a:

echo 0 >/sys/module/kernel/parameters/panic

i am currently working on core configuration support for sysctl.d, once this is in place you should be able to set the parameter through that with something like:

snap set system.sysctl=['kernel.panic=0']

or in your gadget.yaml:

config:
  core:
    system:
      sysctl:
        - kernel.panic=0

(format fully made up and not finalized yet...)

Oliver Grawert (ogra) wrote :

oh, also note that in this specific case you definitely *do not* want to unset panic=-1 before systemd is up to not lose the panic behaviour of kernel and initrd

you only want to set it to 0 once systemd took over, setting this on the command line would make your kernel and initrd hang on panic instead of causing a reboot, so your only options are really the sysfs or the sysctl ways.

Tony Espy (awe) wrote :

@Ogra

If I add a systemd unit to my gadget snap to do what you suggest in comment #2, would it get picked up on an update today?

That said, in the case of the OEM I'm dealing with, all of their IoT systems are configured with a hardware WDT, and their approach to early boot is to configure the systems with a 10m boot BIOS timer which activates the hardware WDT on expiry. So if the system hangs in it's first 10m of life, it'll be rebooted at the 10m mark, otherwise the WDT is activated, and is configured to reboot after 10s of no pings from systemd.

Re: the sysctl.d approach, +1, it's a much better solution than a dedicated systemd unit for the purpose of modifying a kernel parameter. Let me know if you'd like me to review if/when you have something ready.

Tony Espy (awe) on 2017-03-28
Changed in snapd:
status: New → Confirmed
tags: added: hwe
Tony Espy (awe) on 2017-05-16
tags: added: ce
removed: hwe
Ian Johnson (anonymouse67) wrote :

Snapd has for a while now supported gadget asset updates, so the grub.cfg for a gadget can be updated with a gadget snap refresh which would allow one to change the kernel command line used, so I'm marking this bug as Fix Released.

Changed in snapd:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers