When using only governor, the charm adds a grub config

[dashmage]

When deploying a simple bundle like: series: bionic applications: ubuntu: charm: cs:ubuntu num_units: 1 sysconfig: charm: cs:~canonical-bootstack/sysconfig-8 options: governor: 'performance' relations:

• • ubuntu:juju-info
  • sysconfig:juju-info

We see the following in juju status Model Controller Cloud/Region Version SLA Timestamp sysconfig maas maas 2.6.9 unsupported 07:42:13Z

App Version Status Scale Charm Store Rev OS Notes sysconfig active 1 sysconfig jujucharms 8 ubuntu
ubuntu 18.04 active 1 ubuntu jujucharms 12 ubuntu

Unit Workload Agent Machine Public address Ports Message ubuntu/0 active idle 0 172.27.12.141 ready sysconfig/0 active idle 172.27.12.141 reboot required. Changes in: /etc/systemd/system.conf, /etc/default/grub.d/90-sysconfig.cfg

Machine State DNS Inst id Series AZ Message 0 started 172.27.12.141 node02 bionic default Deployed

In the machine, we can see that there's a new /etc/default/grub.d/90-sysconfig.cfg file.

This is due to the fact that during the first config-changed hook, all flags are set to their default value: https://git.launchpad.net/charm-sysconfig/tree/src/reactive/sysconfig.py#n82 Therefore, it will run the update_grub_file function: https://git.launchpad.net/charm-sysconfig/tree/src/lib/lib_sysconfig.py#n226 In this function, when getting the enable_pti property (as the config option enable-pti is not set), it will set pti_off in the context to True. A grub file will then be rendered.

---

Imported from Launchpad using lp2gh.

• date created: 2019-11-27T07:50:02Z

• owner: npochet

• assignee: afreiberger

• the launchpad url

[dashmage]

(by npochet) After a bit more of investigation, it seems that the install_sysconfig() function call update_grub_file without any condition: https://git.launchpad.net/charm-sysconfig/tree/src/reactive/sysconfig.py#n55

[dashmage]

(by aluria)

• Reviewed MP
• suggested a different approach (initialize checksums of managed configuration files on the reactive entry function so any_file_changed can solely be called to verify if an update is needed)
• triaged this bug as "Low" because the Juju description can be reset to "ready" by running the "clear-notification" action

[dashmage]

(by vern) Running the clear-notification action clears the block and changes the status message to "ready" but within a few minutes, the charm returns to blocked requesting a reboot. There doesn't appear to be a way to resolve this without rebooting, which is a very heavy-handed solution.

[dashmage]

(by msmarcal) The charm is not just adding the GRUB configuration but also erasing the kernel options MAAS configured.

/etc/default/grub.d/90-sysconfig.cfg rendered file contains:

# Juju generated file - do not edit manually

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

# Evaluate grub-config-flags first, in case it uses $GRUB_CMDLINE_LINUX_DEFAULT.
# However, if grub-config-flags is not specified, ignore that (current behavior.)
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT console=ttyS0,115200 console=tty0"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
GRUB_TERMINAL=serial

Also, it adds "console=ttyS0,115200 console=tty0" to the options (which has already been added by MAAS)

IMHO, the template shouldn't set GRUB_CMDLINE_LINUX_DEFAULT="" even if the grub-config-flags option is not set. (https://git.launchpad.net/charm-sysconfig/tree/src/templates/grub.j2#n12)

[dashmage]

(by nobuto) This is going to be handled in: https://bugs.launchpad.net/charm-sysconfig/+bug/2012581