[00:59] PR snapd#10561 closed: tests: revert revert manual lxd removal === E_Eickmeyer is now known as Eickmeyer [05:09] morning [06:04] mborzecki: hi! [06:05] mborzecki: do I understand it correctly, that goland does not have an equivalent for the C assert() macro? That is, something that panics when running tests, but is invisible in production [06:06] mardy: there's no such thing [06:09] I see, OK :-) [06:31] mardy: you could probably come up with something that uses build tags, but i'm not sure it's worth it [06:51] yay, remodel tests are working again now [07:02] morning [07:24] good morning pstolowski [07:36] pstolowski: mvo: hey [07:45] hmm can the managers suite fake store effectively sumilate a case where the revision of a snap in the channel we want to refresh from is the same as currently installed? [07:45] hey mborzecki [07:46] mborzecki: uh, IDK :( [07:47] mvo: it's probbaly an edge case, but for uc20 remodel there's downloads-and-checks-edge that we look for in the task sets, so in case the revision of a snap in the new channel is the same, there would be no update, so no downloads edge at all, but only time i've hit this is with actual store ;) [07:50] i think that the problem has been there since 2019 😉 but with uc18 remodels it was not possible to trogger it [07:50] as we always defaulted to the same risk as before, even when switching tracks [07:51] mborzecki: is it using fakeStore or something else? [07:52] pstolowski: no there's a mock store in baseMgrsSuite [07:52] uhh, damn i'm late, an errand back in 30 [07:58] pstolowski, mvo: hi! [07:59] mborzecki: do you have a minute to look at this spread failure? It's about arch and quota :-) https://github.com/snapcore/snapd/pull/10762/checks?check_run_id=3564511878 [07:59] PR #10762: o/servicestate: Update task summary for restart action [08:05] mborzecki: it's hard to tell by just glancing over the code but you may need to investigate newestThatCanRead() and the loop around for _, a := range input.Actions { .. in the mockServer [08:42] re [09:06] mvo: do you mind if I do some minor squashing of the commits in https://github.com/snapcore/snapd/pull/10653? [09:06] PR #10653: mount-control: step 1 [09:07] mardy: totally fine [09:07] mardy: if it's fully ready and all points are addressed I think it's fine to do this [09:08] mardy: hm systemd ran out of memory? [09:11] mborzecki: I'm not sure I know how to read that log: it says "systemd invoked oom-killer", so maybe the killed process is another one? [09:13] mardy: hmm `Memory cgroup stats for /snap.top.slice/snap.top-sub2.slice:` so probably the snap that was installed as part of the test, systemd forks it and sets up the limits before execing, but probably triggers oom after it configured the memory controller [09:13] mardy: otoh isn't the intention of the test to actually cause this? [09:31] mmm... let me look [09:39] mborzecki: I guess you know more about cgroups quotas and how systemd handles them, but here I do not see anything in the test that should trigger an OOM; do you? [09:39] (and if so, shouldn't we see the same error on other distros too?) [09:42] mardy: the test verifies memory quota control of snaps, iirc once quota is applied there's a systemctl restart [09:42] (if there was no quota before) [09:42] so that would check out, there's top.sub2 slice whic would get 5000B of quota 😛 sounds too little for anything to work [09:44] mborzecki: yes, the quota is very small, but I don't see that we are running any process inside it [09:45] clearly systemd (or a fork of it) was inside the slice at the time [09:46] mborzecki: OK. So, if you think that getting an OOM in this test should not make it fail, I'll try to add a flag so that the restore scripts will skip the OOM check for this test. Does it sounds OK to you? [09:48] mardy: could also be a bug in system or sth ;) [09:48] mardy: take a look at the oom information: https://paste.ubuntu.com/p/YB5xpM5FYR/ command is systemd, pid is 1, how com it's associated with this slice? [09:50] mborzecki: yes, it's strange: it also says "Out of memory and no killable processes...", and this seems correct, because indeed we didn't create any process [09:50] mardy: and it wouldn't kill pid 1 either i presume [09:53] mborzecki: indeed; so, as you say, it could be that systemd was inside the group, triggered the OOM, but the kernel refused to kill it [09:54] mardy: can you run it manually with spread, if it fails see what cgorup pid 1 is in? cat /proc/1/cgroup should only show the /init.scope and that's it [10:23] from inside a spread machine, is there a way to run a test case? [10:32] mardy: spread -debug google:ubuntu-18.04-64:tests/main/ ? [10:32] mardy: do you ahve a debug shell? or otherwise you can try spread -shell-before ... and then you can execute step by step the test [10:32] mardy: when it fails you'll be dropped into the shell on the machine and can investigate [10:51] pstolowski, mborzecki: yes, I added an "exit 1" at the end of the test, then I ran the spread with "-debug", but now I want to run the test again; is there a way to do it, without having to restart spread? [11:05] hmm evey time I run tests on master I got go.mod updated with + gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b [11:05] *every [11:05] should this change land or did i miss something? [11:06] it actually replaces same dependency but with // indirect [11:31] pstolowski: here too [11:31] mborzecki: from Russia with love: https://github.com/snapcore/snapd/pull/10764 :-) [11:31] PR #10764: tests: allow spread tests to skip the OOM test [11:31] PR snapd#10764 opened: tests: allow spread tests to skip the OOM test [11:32] oh wait, I left a debug message in it :-) [11:33] mardy: were you able to reproduce it? [11:33] pstolowski: yeah, looks like it's a dependency of configcore, i guess netplan? (cc mvo) [11:34] pstolowski: Y [11:34] pstolowski: heh, https://paste.ubuntu.com/p/5YGQcYJhVm/ [11:35] mborzecki: oh nice, i didn't know go mod why [11:41] mborzecki: no, I ran parts of the test in a loop, but it never happened [12:03] mvo: can you please use your superpowers? https://github.com/snapcore/snapd/pull/10653 [12:03] PR #10653: mount-control: step 1 [12:16] PR snapd#10765 opened: o/snapstate: enforce validation sets/enforce on InstallMany

[12:21] PR snapd#10766 opened: update go.mod dependencies [12:23] mvo, mborzecki ^ [12:31] pstolowski: ah, the PR title :-) [12:32] mardy: doh.. yeah I was kinda expecting it ;) [13:05] degville: hey, I really like the new trend with interface docs of including a snippet of relevant policy, code examples and links to code :) [13:07] jdstrand: lovely to hear from you! And thanks for the comment! I'd like to go through them all to use the same template. [13:08] degville: that's a fair amount of work, but I think the transparency would be welcome. +1 :) [13:51] mvo: ok to land https://github.com/snapcore/snapd/pull/10766 ? [13:51] PR #10766: go: update go.mod dependencies [13:57] PR snapd#10697 closed: o/snapstate: enforce validation sets on snap install

[14:11] pstolowski: sure [14:12] thx [14:12] PR snapd#10766 closed: go: update go.mod dependencies [14:57] I've a bunch of snaps installed. In my snaplist I've got multiple versions of common/framework snaps that were installed as, I assume, dependencies of one/more of 'my' snaps. [14:57] E.g., I've got core/core18/core20 & gnome-3-28-1804/gnome-3-34-1804 installed. [14:57] How do I get the dependency tree out of my snap list? Specifically, what's requiring each of those, and ... can I remove any of them without destructively uninstalling another snap, config, etc? [15:07] PR snapd#10767 opened: o/snapstate: only conflict with runnable and relevant tasks [15:33] * cachio lunch [15:37] PR snapd#10768 opened: daemon: amend ssh keys coming from the store [15:42] PR snapd#10653 closed: mount-control: step 1 [15:42] PR snapd#10718 closed: tests/lib/prepare.sh: download core20 for UC20 runs via BASE_CHANNEL [15:42] PR snapd#10761 closed: o/snapstate: optimize conflicts around snaps stored on conditional-auto-refresh task [17:50] I'm having trouble booting UC20 on a Fitlet2 (x86/AMD64), It encrypts the drives upon installation, but when it boots the first time it fails to unlock the disks, saying: cannot activate with TPN sealed key. Can you provide some pointers on how to troubleshoot this? What log files should I be looking at (and how do I get to them, since it doesn't completely boot)? Thanks. [18:01] Led-Hed, check the forum, i think there are hints how to flush the TPM and such (see channel topic for the link) [18:02] @orga, thanks [18:02] sorry, ogra [18:03] 🙂 [18:17] I found these 2 forum posts, but they seem to be building a custom image. Perhaps the 'breakage' referenced in the 2nd post is what I'm suffering from. [18:17] https://forum.snapcraft.io/t/debugging-installation-issue-with-secured-image/25970 [18:17] https://forum.snapcraft.io/t/debugging-installation-issue-with-secured-image/25970 [18:17] https://forum.snapcraft.io/t/changes-in-shim-signed-packaging-and-breakages-in-uc20-secured-grade-model-images-on-amd64/25983 [20:53] PR snapd#10769 opened: tests: update test nested tool part 2 [21:09] PR snapcraft#3579 closed: snap: move base to core20 (CRAFT-509)