[05:09] morning [06:30] ha, i'm not the one seeing osx failures [06:44] mvo: hey [06:45] good morning mborzecki [06:50] PR snapd#9211 closed: o/snapstate: disk space check with InstallMany [07:04] pstolowski: heya [07:05] hi! [07:05] hey pstolowski ! good morning [07:06] hey mvo! [07:22] good morning [07:30] PR snapd#9239 closed: many: misc doc-comment changes and typo fixes [07:41] ehhh @systemd [07:45] pstolowski: mvo: hi, do we need to have a chat about disk space checks? [07:46] pstolowski: problems? [07:48] pedronis, pstolowski maybe, I'm not super worried. was mostly thinking about something simple (like a system option) to disable the checks [07:48] mvo: well, some checks have landed already [08:10] PR snapd#9242 opened: github: run macOS job with Go 1.14 [08:16] heh, it's green (the macos job at least) [08:16] zyga: can you take a look ^^^ ? [08:17] zyga: can you look at https://bugs.launchpad.net/snapd/+bug/1892895 when you have a moment [08:17] Bug #1892895: unable to allow an app to access all devices with a certain major number via a :* device cgroup rule [08:30] mborzecki: mvo: are we working on this https://bugs.launchpad.net/snapd/+bug/1776622 ? [08:30] Bug #1776622: snapd updates on focal never finish installing. Can't install any other updates.

[08:30] pedronis: systemctl status check (what we discussed last friday wrt --root semantics difference when unit is missing) is going to be messy or maybe we need to do something else, the bahvior of systemctl status is different in 14.04. i wonder if we shouldn't land https://github.com/snapcore/snapd/pull/9241/ to unblock services PR (and in the meantime i'll work on a solution) [08:30] PR #9241: tests: do not set rsyslog.disable in core18 config defaults test <⛔ Blocked> [08:33] pstolowski: it's a real issue, no? is not just the tests [08:46] re [08:46] mborzecki, pedronis: ack [08:46] (my laptop suspended during my 1:1) [08:46] that udev permission issue is very interesting [08:46] it kind of forces us to re-think the entire cgroup access logic [08:46] but, there is some hope that cgroupv2 mode may allow us to do this race free [08:46] mborzecki: reviewed [08:46] pedronis: we should talk about that during the standup a little [08:46] pedronis: I'll think about this and write down some ideas [08:46] pedronis: it's an issue if the config flag is set (e.g. via defaults) but the service file doesn't exist [08:46] i suppose it would be an issue if flag was set and then the service was uninstalled [08:46] PR snapd#9242 closed: github: run macOS job with Go 1.14 [09:00] PR snapd#9202 closed: tests/nested/core20/tpm: verify trusted boot assets tracking [09:02] the nested suite seems to be doing strage stuff and the state from one test seems to leak to the next one [09:02] see https://github.com/snapcore/snapd/runs/1050105329 [09:03] https://github.com/snapcore/snapd/runs/1050105322 this one [09:07] hmm, let's tell sergio about it [09:07] hopefully the nested fixes he was doing will help [09:10] hm, I see some failures in macos-sanity in or 9238 [09:10] did we acciently break that? [09:10] I also noticed it was not a required check :( I fixed that now [09:11] mvo: it's fixed already, merge master please [09:11] mborzecki: ta [09:15] PR snapd#9238 closed: many: check that users of BaseTest don't forget to consume cleanups [09:25] pedronis: I replied in 1776622 [09:25] pedronis: (just fyi) [09:41] pedronis: small question on now-merged https://github.com/snapcore/snapd/pull/9238/files#r480014070 [09:41] PR #9238: many: check that users of BaseTest don't forget to consume cleanups [09:49] zyga: the new set of denials in https://github.com/snapcore/snapd/pull/9204 looks sane [09:49] PR #9204: sandbox: track applications unconditionally [09:51] PR snapd#9240 closed: o/devicestate/devicestate_cloudinit_test.go: test cleanup for uc20 cloud-init tests [09:55] zyga: left a note with a snippet that you can try adding to the policy https://github.com/snapcore/snapd/pull/9204#issuecomment-683683132 [09:55] PR #9204: sandbox: track applications unconditionally [09:56] PR snapd#9224 closed: interfaces/utf: Add MIRKey to u2f devices [09:56] mborzecki: thank you, I'll do that [10:06] PR snapd#9243 opened: testutil: add checkers for symbolic link target [10:06] mborzecki: updated, I also left a TODO to implement the equivalent session bus permission [10:06] mborzecki: but our tests are not measuring that yet [10:10] zyga: cool, let's see what will fail this time ;) [10:55] * pstolowski lunch [11:15] hexchat got stuck on ssl somehow [12:10] * zyga lunch [12:56] cmatsuoka: I answered your doubt, hopefully correctly, in mborzecki PR [12:56] pedronis: thanks, I'll check there [12:56] PR snapd#9201 closed: boot: observe update & rollback of trusted assets [12:56] pedronis: thanks, there was an implicit call to reseal the key after the first backup pass in BeforeWrite() [12:59] pedronis: ah, that was what I thought too [13:04] zyga: https://github.com/snapcore/snapd/pull/9204#discussion_r480115407 [13:04] PR #9204: sandbox: track applications unconditionally [13:05] mborzecki: in one or in both places? [13:05] zyga: just the closing ') [13:06] zyga: the opening one is (` [13:06] ah, ok [13:06] thanks [13:43] kenvandine: fyi, I've seen that firefox font thing several times since we last talked. unfortunately, I've had no time to debug :\ [13:45] restarting the browser does seem to correct it. that is pretty much the extent of debugging I can do atm [13:52] PR snapd#9244 opened: boot: add unit test helpers [13:54] pstolowski, hey, I see the preseed-lxd test failing today [13:54] cmatsuoka: ijohnson: ^^ trivial PR [13:55] pstolowski, did you see that as well? [13:55] mborzecki: sure [13:55] cachio: no, do you have a link? [13:56] mborzecki: checking... [13:56] mborzecki: could you also look at https://github.com/snapcore/snapd/pull/9207 ? just needs another +1 [13:56] PR #9207: boot/bootstate20: reboot to rollback to previous kernel [13:56] pstolowski, https://github.com/snapcore/snapd/pull/9098/checks?check_run_id=1051196015#step:5:1115 [13:56] PR #9098: tests: new organization for nested tests [13:56] ijohnson: sure [13:56] thanks! [13:59] cachio: is this on your PR? [13:59] yes [13:59] pstolowski, I updated nested [13:59] but also the images were updated [14:00] so I dont know what could hte the root cause [14:00] mborzecki: added a question there about bootloader.Force(nil) [14:00] cachio: /home/gopath/src/github.com/snapcore/snapd/tests/lib/preseed.sh: line 66: /mnt/cloudimg/var/lib/snapd/seed/seed.yaml: No such file or directory [14:01] pstolowski, 6 hours ago the images in the bucked were updated [14:01] cachio: it seems this path in inject_snap_into_seed is no longer valid [14:01] cmatsuoka: the helper already adds a cleanup via .AddCleanup() [14:01] mborzecki: ah ok [14:01] pstolowski, I'll try with master to discard the problem is in my pr [14:01] cachio: pstolowski: how are the tests failing ? [14:02] cmatsuoka: see https://github.com/snapcore/snapd/pull/9244/files/accda18257efd4aedf6d32b3d5704709b02d50ca#diff-a69542b9519987a9ee6b8ef3f670f3cbR64 [14:02] PR #9244: boot: add unit test helpers [14:02] * ijohnson may have written inject_snap_into_seed IIRC [14:02] ijohnson, https://github.com/snapcore/snapd/pull/9098/checks?check_run_id=1051196015#step:5:1115 [14:02] PR #9098: tests: new organization for nested tests [14:02] this is the log [14:02] cachio: that link is 500 for me [14:02] oh well I can just look at the PR [14:03] 1 sec [14:04] ijohnson, https://paste.ubuntu.com/p/gyQnPVgCNV/ [14:05] cachio: thanks looking now [14:07] ijohnson, I am running on master just to see if the error is not caused by my PR [14:09] cachio: that cloud image has no snaps seeded in it at all [14:09] pstolowski: ^ [14:10] I just mounted it and this is what is in /var/lib/snapd/: [14:10] https://pastebin.ubuntu.com/p/FPXJfThJ3X/ [14:10] 🤔 [14:10] seems to be a busted image to me if they dropped all snaps from the image [14:12] PR snapd#9244 closed: boot: add unit test helpers [14:13] ijohnson: can you ask/check on preseed channel? [14:13] pstolowski: sure [14:14] thanks [14:14] pstolowski: cachio: actually before I ask, where does this image come from? [14:14] cachio: I downloaded the same img as the spread test: [14:14] https://storage.googleapis.com/spread-snapd-tests/images/cloudimg/bionic-server-cloudimg-amd64.img [14:15] cachio: that looks like an image you maintain, is there maybe something wrong with your image there ? [14:16] in the meantime, I am trying the generic image link from https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img [14:16] ijohnson, 1 sec [14:17] ijohnson, https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img [14:17] this is the same Image [14:17] cachio: that image from cloud-images.ubuntu.com also doesn't have snaps on it, so yeah I'll take it upstream [14:17] thanks [14:17] I copy that to gce weekly [14:18] yaw [14:22] PR snapd#9245 opened: o/snapstate, features: add feature flags for disk space awareness [14:25] cmatsuoka: have you see install fail with this before: [14:25] ``` [14:25] taskrunner.go:271: [change 2 "Setup system for run mode" task] failed: cannot create partitions: cannot create the partitions: partition not available: device /dev/vda4 not available [14:25] ``` [14:26] ijohnson: humm, no, never seen that [14:26] ijohnson: is it a special scenario/device? [14:27] cmatsuoka: no it's from nested tests on GCE, one sec I can provide full logs (well as full as we have) [14:27] cachio: huh I think something may have gone wrong with your test / organization [14:27] cachio: the command being run is [14:27] ` IMGURL=$(get_google_image_url_for_nested_vm ubuntu-20.04-64)` [14:27] but the image it downloaded is a bionic image ? [14:28] ijohnson, ran with master and passed [14:28] to the issue is in my PR [14:29] ijohnson, thanks for the hint, I'll take a look [14:29] cachio: yeah I think your PR has a problem resolveing `nested_get_image_url_for_vm ubuntu-20.04-64` to a bionic image [14:29] it should be getting a focal image [14:30] cmatsuoka: https://pastebin.ubuntu.com/p/VdqWrf5qGS/ is the full log we have from spread [14:30] ijohnson: ok, checking... [14:32] ijohnson: restarted the spread job in 9207 [14:32] mborzecki: ohhhh [14:32] I was looking at the spread logs [14:33] ok seems I have the logs saved [14:33] ijohnson: thanks for figuring that out [14:33] np [14:38] cachio: the issue with getting the wrong URL is that the function nested_get_image_url_for_vm takes an argument, but it isn't passing that argument through to the function nested_get_google_image_url_for_vm [14:40] ijohnson, yes, I already fixed that [14:40] now testing [14:40] cachio: ah ok, I just left a review on your PR for that [14:40] ijohnson, thanks [14:43] errands, bbl [14:47] PR snapd#9246 opened: boot: handle canceled update [14:47] ijohnson: that's a very strange error, it seems that for some reason the device node is not there, even retriggering udev [14:48] ijohnson: is it random or reproducible? [14:49] cmatsuoka: I dunno I didn't try reproducing it yet [14:49] I haven't ever seen it before though [14:58] ijohnson, fix pushed [14:58] * cachio lunch [15:03] * zyga EODs and prepares for PT [15:12] PR snapd#9207 closed: boot/bootstate20: reboot to rollback to previous kernel [15:13] ijohnson: could you have a look at https://github.com/snapcore/snapd/pull/9138? [15:13] PR #9138: many: refactor tpm seal parameter setting [15:14] ijohnson: it should make the seal transition to boot a lot easier [15:16] cmatsuoka: yes I will look today [15:16] thanks [16:27] PR snapcraft#3269 opened: spread tests: remove references of core16 [16:39] ijohnson, about the comment related to SC2120 [16:39] yes? [16:40] I just copied the same we had for the google function [16:40] because the unit test checks that and fails [16:40] cachio: ok, if it fails leave it in [16:40] ijohnson, ok, thanks [16:40] I'm slightly surprised that we don't run shellcheck in such a way that shellcheck could see how the script is used, but oh well [16:41] s/script/function/ [16:43] cachio: I reviewed #9235, I'm not sure whether we should go this route or not yet [16:43] PR #9235: tests: new tests for nested and external [16:43] cachio: I would like to see some others comment on the approach, perhaps zyga could take a look when available [16:43] ijohnson, thanks for the review [16:43] this should go after 9098 [16:43] yes [16:43] I'll tag it [16:46] ijohnson, I'll try to implement something like you suggested in 9235 [16:46] cachio: don't spend too much time on it, maybe others think this approach is ok, in which case I wouldn't want you to waste a bunch of time on implementing my suggestion [16:47] ijohnson, we also could have tests duplicated :) [16:47] cachio: true that's another option :-) [16:47] because there are just few we need to run in both worlds [16:47] I'll ask in the standup tomorrow [16:48] yeah maybe [17:02] PR snapd#9247 opened: secboot: use EFIImage type in load sequences [18:07] PR snapcraft#3270 opened: Add PYTHONPATH to environment (fixes #1893262) [18:44] pedronis: it's easy to compose the boot chains using slice of BootImage defined in bootloader, however how do you envision the actual chain parameters being passed to the sealer? [18:45] cmatsuoka: ? [18:45] pedronis: do you have time for a quick chat? [18:47] cmatsuoka: yes, in a couple minutes [18:47] pedronis: thanks, I'll be in the su room [19:03] PR snapd#9248 opened: exportstate: add scaffolding for the export manager [19:10] pedronis: ^ some early code for the export manager, I would appreciate ack/nack on the data structures / names [19:10] pedronis: but you should really get some rest, let's look at it tomorrow [19:19] zyga, hey, about zfs [19:20] which should be the idea of that image? [19:20] everyhing zfs? [19:28] cachio: the 20.04 image offers a new installer option to use zfs [19:28] cachio: it should be representative of that image [19:28] cachio: it's a complex setup, please try a desktop install to examine it [19:28] zyga, I see [19:29] I'll do that [19:29] cachio: zfs uses lots of mount points for everything, [19:29] and see if it is possible to replicated that for gce [19:29] cachio: it's not like ext4 but zfs [19:29] cachio: try a desktop image locally in qemu or otherwise first [19:29] cachio: to see how that looks like [19:30] zyga, ok, I'll start with that [19:30] tx [19:33] cachio: no, thank you :) [19:48] PR snapd#9247 closed: secboot: use EFIImage type in load sequences [20:01] ijohnson: cmatsuoka: I went ahead in the end and proposed this: https://github.com/snapcore/snapd/pull/9249 [20:01] PR #9249: boot,bootloader,gadget: apply new bootloader.Options.Role [20:01] pedronis: ack [20:01] cmatsuoka: the Role type there might be useful for you as well [20:02] pedronis: will check, thanks [20:02] mmm I like this, Role seems much more intuitive [20:03] PR snapd#9249 opened: boot,bootloader,gadget: apply new bootloader.Options.Role [20:41] ijohnson, hi [20:41] hey cachio [20:42] running in nested I see that if I stop the vm and the service sometimes the users that I created cant login anymore [20:42] so, first I create the instace, then I start it [20:43] then I create the test and external users [20:43] then I shutdown the vm and stop the service [20:43] I do that because I need to backup the vm for future tests [20:43] cachio: how are you shutting down the VM ? [20:44] > shutdown now [20:44] run shoutdown now [20:44] when I cannot connect through ssh [20:44] I stop the service [20:44] cachio: before running that, on the host (not in the VM), you should run `sync`, I have seen before where if you do not sync state then file changes in the nested VM disappears [20:45] ijohnson, ahhh, nice [20:45] so sync in the host [20:45] it's probably a bug somewhere [20:45] but yeah on the host is what fixed it for me [20:45] ijohnson, thanks, I'll try that [20:45] this happened reliably to me when I was working on the cloud-init nested tests [20:46] ijohnson, I remember that you told it in the stand up [20:46] yeah hopefully this works for you [21:29] * cachio afk [22:43] PR snapd#9250 opened: Uc20 bootloader boot image