tests/lib/nested.sh: add debug kernel command line parameters

[anonymouse64]

This should aid in debugging problems like in LP #1956586.

[codecov-commenter]

Codecov Report

Merging #11261 (bbf8dba) into master (228aa86) will decrease coverage by 0.00%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #11261      +/-   ##
==========================================
- Coverage   78.34%   78.33%   -0.01%     
==========================================
  Files         924      924              
  Lines      105436   105436              
==========================================
- Hits        82606    82597       -9     
- Misses      17689    17696       +7     
- Partials     5141     5143       +2     

Flag	Coverage Δ
unittests	78.33% <ø> (-0.01%)	:arrow_down:

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

Impacted Files	Coverage Δ
osutil/synctree.go	76.41% <0.00%> (-2.84%)	:arrow_down:
daemon/api_connections.go	93.04% <0.00%> (-0.54%)	:arrow_down:
overlord/ifacestate/helpers.go	76.96% <0.00%> (-0.49%)	:arrow_down:
cmd/snap/cmd_debug_state.go	70.18% <0.00%> (-0.46%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 228aa86...bbf8dba. Read the comment docs.

[anonymouse64]

mmh at least one of the nested tests are indeed unhappy with this PR:

for core20-tpm:

Jan 15 00:46:08 ubuntu snapd[793]: 2022/01/15 00:46:08.252798 stateengine.go:149: state ensure error: devicemgr: cannot mark boot successful: cannot mark successful boot command line: unexpected current command line: "snapd_recovery_mode=run console=ttyS0 console=tty1 panic=-1 dangerous systemd.journald.forward_to_console=1 rd.systemd.journald.forward_to_console=1"

full log: https://pastebin.ubuntu.com/p/YDySGVD4BY/

[bboozzoo]

I see. That test bit executes a compatibility scenario in which there was no current-kernel-command-lines stored in the modeenv (eg. a system deployed early before we released UC20), and thus the code comes up with what should be the right command line, but ignores the fragments that can come from the gadget. I think this assumption is still ok, keep in mind since there was no command line before, it also means there is no support for gadget provided command line fragments which came to be later. This would not normally happen on a UC20 system, but the test procures such conditions by directly manipulating modeenv.

FWIW if we ever have a remodel path from UC18 to UC20, the command line would be updated during the process, so we would not hit this scenario either.

The test actually does even more, and it removes the list of good recovery systems too, which would then be restored. Perhaps those 2 manipulation steps could be moved to some other test, or to a completely new test. The test would have to be under nested/manual as it would need a different gadget than the nested/core suite.

[Meulengracht]

I am closing this, I don't believe this is relevant anymore, and we already do get debug output in tests.