Page MenuHomeVyOS Platform

`set system option kernel disable-mitigations` not applied on upgrade
Open, NormalPublicBUG


I just upgraded from 1.4-epa2 to 1.4-epa3

I noticed on reboot that even though

set system option kernel disable-mitigations

was set, that it hadn't been applied on booting into epa3

My fix was to disable it, commit, enable it, commit and then reboot.

I expect maybe there needs to be a check when the config is copied over during the new image install, that looks for this statement and then applies the setting to grub.

This is a very very minor bug.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

tjh updated the task description. (Show Details)
syncer triaged this task as Normal priority.
syncer edited projects, added VyOS 1.4 Sagitta (1.4.0-GA); removed VyOS 1.4 Sagitta.

@tjh in fact, this was a design decision, discussed with @Viacheslav at the time, and agreed upon, although neither of us are fully satisfied with the decision (and I'll let him amend these claims, if needed):

Note that a second reboot after booting into the new image will pick up the configured cmdline options; no need to re-commit. The issue is a chicken-egg disjunction with configuration at boot and grub configuration preceding it: in an extreme case of migration needing to modify/deprecate configured options would only take place on the first boot into the new image, thus the concern about automatically modifying the initial boot line.

This remains a bug nonetheless, as the user (you in this case; thanks !) is not clearly informed that a second boot is necessary to apply the config boot options, and despite the logic being clear after the fact, that is not helpful. It would be useful to consider better alternatives, perhaps offering the user a prompt and choice during update, however, this requires some advanced knowledge of the target image and migration in the extreme case. I think with proper documentation and a simple notification message during update, the current logic remains the safe choice.

@jestabro Thanks for the detailed explanation. If I'd been a proper tester I should have just rebooted it a second time! I think the current solution is fine as long as it's mentioned in release/upgrade notes somewhere. It really is only a performance tweak, it doesn't impact functionality. Thanks again.