o/{ifacestate,snapstate}: delay reboot when we have kernel-modules #14733

alfonsosanchezbeato · 2024-11-15T19:33:01Z

Delay reboot when we are installing/updating/removing kernel-modules
components jointly with a kernel refresh so it happens after the
refresh hooks have run. With this we ensure that the kernel modules
shipped in the component or built from the hooks is available at the
same time as the other modules after rebooting.

alfonsosanchezbeato · 2024-11-15T19:33:32Z

Opening as draft for the moment to see state of the test.

codecov · 2024-11-15T20:49:57Z

Codecov Report

Attention: Patch coverage is 69.91870% with 37 lines in your changes missing coverage. Please review.

Project coverage is 79.02%. Comparing base (96ea7b0) to head (353a40c).
Report is 75 commits behind head on master.

Files with missing lines	Patch %	Lines
overlord/snapstate/handlers_components.go	57.77%	12 Missing and 7 partials ⚠️
overlord/snapstate/handlers.go	66.66%	8 Missing and 4 partials ⚠️
overlord/ifacestate/handlers.go	25.00%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #14733      +/-   ##
==========================================
+ Coverage   78.95%   79.02%   +0.07%     
==========================================
  Files        1084     1087       +3     
  Lines      146638   147734    +1096     
==========================================
+ Hits       115773   116742     +969     
- Misses      23667    23751      +84     
- Partials     7198     7241      +43

Flag	Coverage Δ
unittests	`79.02% <69.91%> (+0.07%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

andrewphelpsj

Thanks, just some small things!

andrewphelpsj · 2024-11-18T14:15:57Z

overlord/snapstate/snapstate_update_test.go

@@ -15556,7 +15580,7 @@ func (s *snapmgrTestSuite) TestUpdateWithComponentsRunThroughAdditionalComponent

 func (s *snapmgrTestSuite) TestUpdateWithComponentsRunThroughAdditionalComponentsAlreadyInstalled(c *C) {
 	s.testUpdateWithComponentsRunThrough(c, updateWithComponentsOpts{
-		instanceKey:           "key",
+		instanceKey:           "",


If I understand correctly, is this changed because kernel snaps cannot have instance keys? This does remove some of the cases that we're testing.

Same with TestInstallInstanceManyComponentsRunThrough now installing only one component, the intent of that test was to install multiple components.

There was an issue with these test as now I had to improve the emulation of kernel updates in the tests. I have done changes now so both kernel and applications snaps using instances are tested.

andrewphelpsj · 2024-11-18T14:18:32Z

overlord/snapstate/handlers.go

+	csups := make([]ComponentSetup, 0, len(compsups))
+	for _, c := range compsups {
+		csups = append(csups, *c)
+	}


Unused slice here.

andrewphelpsj · 2024-11-18T14:26:46Z

overlord/snapstate/handlers_components.go

+	csups := make([]ComponentSetup, 0, len(compsups))
+	for _, c := range compsups {
+		csups = append(csups, *c)
+	}


Same here, unused.

andrewphelpsj · 2024-11-18T14:30:07Z

overlord/snapstate/handlers_components.go

+	if rebootInfo.RebootRequired {
+		return m.finishTaskWithMaybeRestart(t, state.DoneStatus,
+			restartPossibility{info: newInfo, RebootInfo: rebootInfo})


Could this half of this if statement go in the above if statement's block? Since this shouldn't ever be true if we don't have a valid rebootInfo? Then, rebootInfo could be scoped to that block.

Changed... I was a bit hesitant about this as I don't like non-error returns to be in the middle of a method, but this looks close enough to the end.

alfonsosanchezbeato

@andrewphelpsj thanks for the review, I've addressed your comment now. I am also removing the draft status.

alfonsosanchezbeato · 2024-11-18T18:36:10Z

overlord/snapstate/handlers.go

+	csups := make([]ComponentSetup, 0, len(compsups))
+	for _, c := range compsups {
+		csups = append(csups, *c)
+	}


alfonsosanchezbeato · 2024-11-18T18:37:04Z

overlord/snapstate/handlers_components.go

+	csups := make([]ComponentSetup, 0, len(compsups))
+	for _, c := range compsups {
+		csups = append(csups, *c)
+	}


alfonsosanchezbeato · 2024-11-18T18:45:08Z

overlord/snapstate/handlers_components.go

+	if rebootInfo.RebootRequired {
+		return m.finishTaskWithMaybeRestart(t, state.DoneStatus,
+			restartPossibility{info: newInfo, RebootInfo: rebootInfo})


Changed... I was a bit hesitant about this as I don't like non-error returns to be in the middle of a method, but this looks close enough to the end.

alfonsosanchezbeato · 2024-11-18T22:00:50Z

overlord/snapstate/snapstate_update_test.go

@@ -15556,7 +15580,7 @@ func (s *snapmgrTestSuite) TestUpdateWithComponentsRunThroughAdditionalComponent

 func (s *snapmgrTestSuite) TestUpdateWithComponentsRunThroughAdditionalComponentsAlreadyInstalled(c *C) {
 	s.testUpdateWithComponentsRunThrough(c, updateWithComponentsOpts{
-		instanceKey:           "key",
+		instanceKey:           "",


There was an issue with these test as now I had to improve the emulation of kernel updates in the tests. I have done changes now so both kernel and applications snaps using instances are tested.

Meulengracht · 2024-11-20T07:46:52Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


So in regards to the introduction of the following new task variables finish-restart and prepare-restart - what happens when an update, which needs to reboot, is scheduled before snapd is updated to this version?

Snapd updates first, then the other essential snaps update, but at this point the change does not have any task that sets either prepare-restart or finish-restart. What happens in this case? This is not entirely clear for me

When the variables are not set (old snapd running when creating the change), the behavior is the same as in the past, even with newer snapd running the tasks. What is an actual difference is that discard-old-kernel-snap-setup has moved but looking at the code there we are safe regardless of the order and the snapd version.

Said this, there is no kernel yet deployed using kernel-modules, so we are also safe if this gets into 2.67.

sorry, I'm confused as if the finish-restart is not set needsFinishRestart is false, no? so we will not have the old behavior

also wouldn't it make more sense to deal with the new field inside snapstate.FinishRestart itself? it receives the task anyway?

Good catch, the default value needs to capture the old behavior, I've changed this now. To make this work, I also make sure now that all the related tasks receive a value with either true or false so we can differentiate from the case where there is no value set. I have not moved the checks to FinishRestart as in that case I would need to look at the kind of task to decide what to do if there is no value set.

you could also pass the default behavior boolean in though instead?

do we need a test in the package that tests the "finish-restart" false behavior?

I've changed FinishRestart now. Test for it added too.

overlord/snapstate/snapstate.go

Meulengracht

Looks really nice overall, but couple of questions

andrewphelpsj

Thanks for the changes!

pedronis

some initial questions

pedronis · 2024-11-20T16:14:15Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


sorry, I'm confused as if the finish-restart is not set needsFinishRestart is false, no? so we will not have the old behavior

pedronis · 2024-11-20T16:14:54Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


also wouldn't it make more sense to deal with the new field inside snapstate.FinishRestart itself? it receives the task anyway?

overlord/snapstate/snapstate.go

alfonsosanchezbeato

@pedronis @Meulengracht thanks for the reviews, I've addressed your comments now

alfonsosanchezbeato · 2024-11-20T18:36:17Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


Good catch, the default value needs to capture the old behavior, I've changed this now. To make this work, I also make sure now that all the related tasks receive a value with either true or false so we can differentiate from the case where there is no value set. I have not moved the checks to FinishRestart as in that case I would need to look at the kind of task to decide what to do if there is no value set.

overlord/snapstate/snapstate.go

Meulengracht · 2024-11-21T07:45:06Z

overlord/snapstate/handlers.go

+		return err
+	}
+	if needsFinishRestart {
+		logger.Debugf("finish restart from doAutoConnect")


Suggested change

logger.Debugf("finish restart from doAutoConnect")

logger.Debugf("finish restart from doDiscardOldKernelSnapSetup")

Meulengracht · 2024-11-21T07:49:29Z

overlord/snapstate/snapstate.go

+	if setupKmodComponents != nil {
+		setupKmodComponents.Set("prepare-restart", restartInSetupKmods)
+	}
+	if afterSetupKmodComps != nil {
+		afterSetupKmodComps.Set("finish-restart", restartInSetupKmods)
+	}


Should we not just set those up in the else above? Then we can save the restartInSetupKmods bool?

Moved now, hopefully it looks simpler now

pedronis

did another pass, some more comments/questions

pedronis · 2024-11-21T10:45:57Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


you could also pass the default behavior boolean in though instead?

pedronis · 2024-11-21T10:46:39Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


do we need a test in the package that tests the "finish-restart" false behavior?

overlord/snapstate/snapstate.go

pedronis · 2024-11-21T10:53:48Z

overlord/snapstate/snapstate.go

+	linkSnap.Set("prepare-restart", restartInLink)
+	autoConnect.Set("finish-restart", restartInLink)
+	if setupKmodComponents != nil {
+		setupKmodComponents.Set("prepare-restart", restartInSetupKmods)
+	}
+	if afterSetupKmodComps != nil {
+		afterSetupKmodComps.Set("finish-restart", restartInSetupKmods)
+	}


this seems overly complicated, can't we fold these into the previous ifs and don't have the flags? or just have the flag restartInSetupKmods, both flags cannot be true at the same time?

overlord/snapstate/snapstate.go

pedronis · 2024-11-21T11:16:22Z

overlord/snapstate/handlers_components.go

+		// TODO we have to revert changes in bootloader config/modeenv if an
+		// error happens later in this method. This is not likely as possible
+		// errors after this would happen only due to internal errors or not
+		// being able to write to the filesystem, but still. There is also the
+		// question of what would happen if a restart happens when the boot
+		// configuration has been already written but DoneStatus in the state
+		// has not.


are we happy with the reboot placement on the undo paths?

In principle we are, "unlink-snap" and "unlink-current-snap" still look as the right places to reboot when undoing even when there are kernel-modules. cc @Meulengracht in case he difers.

I think the reboot placement along undo still is correct

pedronis · 2024-11-21T11:16:35Z

overlord/snapstate/handlers_components.go

+			return m.finishTaskWithMaybeRestart(t, state.DoneStatus,
+				restartPossibility{info: newInfo, RebootInfo: rebootInfo})


tests don't exercise this afaict

I've improved the tests that call testUpdateWithComponentsRunThrough so this is now exercized.

pedronis · 2024-11-21T11:17:35Z

overlord/snapstate/handlers_components.go

+	// Set the default to false for compatibility with older snapd (case of
+	// joint refresh of snapd and kernel).
+	prepareRestart := false
+	if err := t.Get("prepare-restart", &prepareRestart); err != nil &&


isn't prepare-restart doubling what the restart-boundary should also indicates? I understand that is trickier for the finish-restart bit as the task is not the boundary one

Not exactly, restart-boundary is set only for one of the snaps that want a reboot in a change. But, we need to call MaybeSetNextBoot for all snaps that want a reboot, as they need to do different things in preparation for the reboot. We also need to call finishTaskWithMaybeRestart in all these cases I believe. On the other hand, the kernel snap is the one getting the restart-bounday flag if part of a refresh change (see essentialSnapsRestartOrder), so maybe what you suggest is doable, but sounds too implicit and asymmetric as we need still finish-restart.

alfonsosanchezbeato

Thanks for the reviews, I've pushed changes now

alfonsosanchezbeato · 2024-11-21T14:00:16Z

overlord/snapstate/snapstate.go

+	if setupKmodComponents != nil {
+		setupKmodComponents.Set("prepare-restart", restartInSetupKmods)
+	}
+	if afterSetupKmodComps != nil {
+		afterSetupKmodComps.Set("finish-restart", restartInSetupKmods)
+	}


Moved now, hopefully it looks simpler now

alfonsosanchezbeato · 2024-11-21T14:01:30Z

overlord/snapstate/snapstate.go

+	linkSnap.Set("prepare-restart", restartInLink)
+	autoConnect.Set("finish-restart", restartInLink)
+	if setupKmodComponents != nil {
+		setupKmodComponents.Set("prepare-restart", restartInSetupKmods)
+	}
+	if afterSetupKmodComps != nil {
+		afterSetupKmodComps.Set("finish-restart", restartInSetupKmods)
+	}


alfonsosanchezbeato · 2024-11-21T16:24:30Z

overlord/snapstate/handlers_components.go

+	// Set the default to false for compatibility with older snapd (case of
+	// joint refresh of snapd and kernel).
+	prepareRestart := false
+	if err := t.Get("prepare-restart", &prepareRestart); err != nil &&


Not exactly, restart-boundary is set only for one of the snaps that want a reboot in a change. But, we need to call MaybeSetNextBoot for all snaps that want a reboot, as they need to do different things in preparation for the reboot. We also need to call finishTaskWithMaybeRestart in all these cases I believe. On the other hand, the kernel snap is the one getting the restart-bounday flag if part of a refresh change (see essentialSnapsRestartOrder), so maybe what you suggest is doable, but sounds too implicit and asymmetric as we need still finish-restart.

alfonsosanchezbeato · 2024-11-21T18:09:27Z

overlord/ifacestate/handlers.go

@@ -1386,9 +1386,17 @@ func (m *InterfaceManager) doAutoConnect(task *state.Task, _ *tomb.Tomb) error {
 	// if this is the case we can only proceed once the restart
 	// has happened or we may not have all the interfaces of the
 	// new core/base snap.
-	if err := snapstateFinishRestart(task, snapsup); err != nil {
+	needsFinishRestart := false
+	if err := task.Get("finish-restart", &needsFinishRestart); err != nil &&


I've changed FinishRestart now. Test for it added too.

alfonsosanchezbeato · 2024-11-21T18:15:00Z

overlord/snapstate/handlers_components.go

+		// TODO we have to revert changes in bootloader config/modeenv if an
+		// error happens later in this method. This is not likely as possible
+		// errors after this would happen only due to internal errors or not
+		// being able to write to the filesystem, but still. There is also the
+		// question of what would happen if a restart happens when the boot
+		// configuration has been already written but DoneStatus in the state
+		// has not.


In principle we are, "unlink-snap" and "unlink-current-snap" still look as the right places to reboot when undoing even when there are kernel-modules. cc @Meulengracht in case he difers.

alfonsosanchezbeato · 2024-11-21T19:06:40Z

overlord/snapstate/handlers_components.go

+			return m.finishTaskWithMaybeRestart(t, state.DoneStatus,
+				restartPossibility{info: newInfo, RebootInfo: rebootInfo})


I've improved the tests that call testUpdateWithComponentsRunThrough so this is now exercized.

overlord/snapstate/snapstate.go

pedronis

thank you, couple small remarks

pedronis · 2024-11-22T12:13:19Z

overlord/snapstate/snapstate_update_test.go

@@ -15803,6 +15830,36 @@ func (s *snapmgrTestSuite) testUpdateWithComponentsRunThrough(c *C, opts updateW
 	})
 	c.Assert(err, IsNil)

+	// Check boundaries are in the expected tasks


should we Get("restart-boundary"...) and check it directly as well?

pedronis · 2024-11-22T12:14:11Z

overlord/snapstate/handlers.go

@@ -2283,14 +2283,14 @@ func (m *SnapManager) doLinkSnap(t *state.Task, _ *tomb.Tomb) (err error) {
 		return err
 	}

-	// Prepare for rebooting for snaps that need it. Note that if we have
+	// Set next boot for snaps that need it. Note that if we have
 	// kernel-modules components this gets delayed as it happens in the
 	// "prepare-kernel-modules-components" task. The default is set to
 	// true for compatibility with older snapd (case of joint refresh of
 	// snapd and kernel).
 	var rebootInfo boot.RebootInfo
 	prepareRestart := true


shouldn't we change the var name as well? same in other places?

pedronis

thank you

Meulengracht

Couple of final remarks surrounding the new structure

Meulengracht · 2024-11-22T13:54:09Z

overlord/snapstate/snapstate.go

@@ -985,16 +1014,32 @@ func isInvokedWithRevert() bool {
 	return os.Getenv("SNAPD_REVERT_TO_REV") != ""
 }

+// FinishRestartOpts are options for FinishRestart.
+type FinishRestartOpts struct {


In relations to naming structure types as 'Opts' vs 'Options', we seem to be mostly biased towards spelling it out to FinishRestartOptions by doing a search in our code. (35 results vs 130 results). Let's try to stick to the Options pattern.

Suggested change

type FinishRestartOpts struct {

type FinishRestartOptions struct {

Meulengracht · 2024-11-22T13:56:58Z

overlord/snapstate/snapstate.go

+// FinishRestartOpts are options for FinishRestart.
+type FinishRestartOpts struct {
+	// Set to the default behavior if finish-restart is not set in the task.
+	RunIfOldChange bool


Suggested change

RunIfOldChange bool

FinishRestartDefault bool

Meulengracht · 2024-11-22T13:57:56Z

overlord/snapstate/snapstate.go

@@ -985,16 +1014,32 @@ func isInvokedWithRevert() bool {
 	return os.Getenv("SNAPD_REVERT_TO_REV") != ""
 }

+// FinishRestartOpts are options for FinishRestart.
+type FinishRestartOpts struct {
+	// Set to the default behavior if finish-restart is not set in the task.


I would like to see a more detailed explanation for this, my suggestion

Suggested change

// Set to the default behavior if finish-restart is not set in the task.

// FinishRestartDefault sets the default behavior for whether FinishRestart should finalize the restart. For tasks that exists before this introduction, this should be true, otherwise false.

Rephrased a bit

Meulengracht · 2024-11-22T14:45:12Z

overlord/snapstate/handlers_components.go

+		// TODO we have to revert changes in bootloader config/modeenv if an
+		// error happens later in this method. This is not likely as possible
+		// errors after this would happen only due to internal errors or not
+		// being able to write to the filesystem, but still. There is also the
+		// question of what would happen if a restart happens when the boot
+		// configuration has been already written but DoneStatus in the state
+		// has not.


I think the reboot placement along undo still is correct

Delay reboot when we are installing/updating/removing kernel-modules components jointly with a kernel refresh so it happens after the refresh hooks have run. With this we ensure that the kernel modules shipped in the component or built from the hooks is available at the same time as the other modules after rebooting.

Test that modules from kernel-modules components are available early after rebooting.

alfonsosanchezbeato · 2024-11-22T16:22:03Z

@Meulengracht thanks, I've addressed your comments now. I've also squashed commits.

alfonsosanchezbeato requested review from pedronis, Meulengracht and andrewphelpsj November 15, 2024 19:33

alfonsosanchezbeato added the Run nested The PR also runs tests inluded in nested suite label Nov 15, 2024

alfonsosanchezbeato closed this Nov 15, 2024

alfonsosanchezbeato reopened this Nov 15, 2024

alfonsosanchezbeato force-pushed the delay-kernel-reboot branch from f05becd to 353a40c Compare November 15, 2024 20:27

andrewphelpsj reviewed Nov 18, 2024

View reviewed changes

alfonsosanchezbeato commented Nov 18, 2024

View reviewed changes

alfonsosanchezbeato marked this pull request as ready for review November 18, 2024 22:01

alfonsosanchezbeato requested a review from andrewphelpsj November 18, 2024 22:02

alfonsosanchezbeato force-pushed the delay-kernel-reboot branch 2 times, most recently from 4d2d2a6 to b209258 Compare November 19, 2024 12:57

Meulengracht reviewed Nov 20, 2024

View reviewed changes

overlord/snapstate/snapstate.go Show resolved Hide resolved

Meulengracht reviewed Nov 20, 2024

View reviewed changes

overlord/snapstate/snapstate.go Show resolved Hide resolved

Meulengracht reviewed Nov 20, 2024

View reviewed changes

overlord/snapstate/snapstate.go Show resolved Hide resolved

Meulengracht reviewed Nov 20, 2024

View reviewed changes

pedronis added this to the 2.67 milestone Nov 20, 2024

andrewphelpsj approved these changes Nov 20, 2024

View reviewed changes

pedronis reviewed Nov 20, 2024

View reviewed changes

alfonsosanchezbeato commented Nov 20, 2024

View reviewed changes

alfonsosanchezbeato requested review from Meulengracht and pedronis November 20, 2024 18:51

Meulengracht reviewed Nov 21, 2024

View reviewed changes

pedronis reviewed Nov 21, 2024

View reviewed changes

alfonsosanchezbeato commented Nov 21, 2024

View reviewed changes

alfonsosanchezbeato requested a review from Meulengracht November 21, 2024 20:01

alfonsosanchezbeato requested a review from pedronis November 21, 2024 20:01

pedronis reviewed Nov 22, 2024

View reviewed changes

pedronis approved these changes Nov 22, 2024

View reviewed changes

Meulengracht reviewed Nov 22, 2024

View reviewed changes

alfonsosanchezbeato added 2 commits November 22, 2024 11:19

tests/kernel-modules-components: test early modules

9c6ee64

Test that modules from kernel-modules components are available early after rebooting.

alfonsosanchezbeato force-pushed the delay-kernel-reboot branch from d902299 to 9c6ee64 Compare November 22, 2024 16:19

alfonsosanchezbeato requested a review from Meulengracht November 22, 2024 16:21

	logger.Debugf("finish restart from doAutoConnect")
	logger.Debugf("finish restart from doDiscardOldKernelSnapSetup")

		return m.finishTaskWithMaybeRestart(t, state.DoneStatus,
		restartPossibility{info: newInfo, RebootInfo: rebootInfo})

	type FinishRestartOpts struct {
	type FinishRestartOptions struct {

	// Set to the default behavior if finish-restart is not set in the task.
	// FinishRestartDefault sets the default behavior for whether FinishRestart should finalize the restart. For tasks that exists before this introduction, this should be true, otherwise false.

o/{ifacestate,snapstate}: delay reboot when we have kernel-modules #14733

Are you sure you want to change the base?

o/{ifacestate,snapstate}: delay reboot when we have kernel-modules #14733

Conversation

alfonsosanchezbeato commented Nov 15, 2024

alfonsosanchezbeato commented Nov 15, 2024

codecov bot commented Nov 15, 2024

Codecov Report

andrewphelpsj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alfonsosanchezbeato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Meulengracht left a comment

Choose a reason for hiding this comment

andrewphelpsj left a comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alfonsosanchezbeato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alfonsosanchezbeato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Meulengracht left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment