[00:03] PR snapd#9326 closed: tests: fix for basic20 test running on external backend and rpi === jamesh_ is now known as jamesh [01:59] PR snapd#9362 closed: tests: skip nested images pre-configuration by default [06:20] PR snapd#9360 closed: tests: make gadget-reseal more robust [06:35] morning [06:37] good morning mborzecki [06:37] mvo: hey [06:38] mvo: so are we out of the woods yet? [06:39] mborzecki: yeah, I think it's time for a (small) bottle of champagne [06:39] mborzecki: resealing+pcr4 just landed [06:40] mborzecki: so we should be good [06:40] PR snapd#9277 closed: secboot: add boot manager profile to pcr protection profile [06:40] PR snapd#9356 closed: sysconfig,o/devicestate: mv DisableNoCloud to DisableAfterLocalDatasourcesRun [06:40] mborzecki: I guess the next step is to test gadget udpate with the pc branch 20/beta/edition3 for real [06:40] mborzecki: and if that works it's really time to celebrate [06:41] mborzecki: I will branch 2.47 now [06:41] yay [06:41] mborzecki: afaict all is merged and the only missing pr needs a samuele review first [06:41] mvo: i'll work on the fix for updating structures without partitions on an encrypted device [06:42] mborzecki: sounds great, thanks for this [07:01] morning [07:02] good morning pstolowski [07:02] pstolowski: do we happen to have a forum topic for disk-space awareness that I could link to? [07:02] mvo: i don't think so [07:03] mvo: i could publish the notes i sent to degville [07:04] pstolowski: not urgent if degville publishes them I can link to that [07:04] pstolowski: mostly wondering because I'm working on 2.47 release notes [07:05] mvo / pstolowski: the disk awareness doc is here: https://forum.snapcraft.io/t/disk-space-awareness/20007 [07:07] degville: nice, thank you! [07:07] np! [07:07] degville: there is a mistake there re snapd version (it says 2.37+ ) [07:08] pstolowski: ah, thanks. I'll fix it now. [07:08] degville: \o/ thank you! I updated the snapd roadmap page now [07:10] good morning :) [07:10] I patched all the profiles last night and ran a test before EODing [07:10] I see that lxd and gdbserver failed, let me look at those [07:12] let's debug those [07:12] mvo: is 2.47 ready now? [07:13] I saw ian and samuele fight some issues last night [07:13] good morning zyga [07:13] zyga: yeah, I'm on 2.47~pre1 right now [07:13] I slept for 5 hours but I'm okay surprisingly [07:13] cool, fingers crossed no more surprises [07:15] PR snapd#9361 closed: tests/lib/cl_check.py: use python3 compatible code [07:27] ah missing snap-gdbserver-shim [07:27] fixed [07:27] let's look at lxd now [07:35] zyga: can you take a loot at https://github.com/snapcore/snapd/pull/9364 ? you like them python bits ;) [07:35] PR #9364: tests/lib/cla_check: default to Python 3, tweaks, formatting [07:35] sure [07:35] looking [07:35] zyga: fwiw, do you remember what distro is used for the workers/ [07:35] PR snapd#9364 opened: tests/lib/cla_check: default to Python 3, tweaks, formatting [07:36] re-formatted with black I presume [07:36] zyga: yeah, the trademark () style it uses [07:36] +1 [07:37] zyga: are you in power to install python3-launchpadlib in the containers used to run the cla workflow? [07:37] on mine, yes [07:37] one moment [07:39] zyga: who manages the other workers? that workflow runs on self-hosted (whatver that means) [07:39] mborzecki: claudio [07:39] installing now [07:39] zyga: cool, i'll ping him [07:40] mborzecki: self hosted are workers which are managed buy us, not github [07:40] zyga: right, i though that maybe is runs/manages some of those for us [07:40] that's two nodes from me and one from claudio [07:40] it's self-managed [07:40] it will be ready in a few minutes [07:41] zyga: cool, thank you [07:55] mborzecki: done, all workers under my control are ready [07:56] zyga: thanks [07:56] mborzecki: as for self-hosted workers [07:56] mborzecki: we could tweak actions to run cla checks on a pi easily [07:56] mborzecki: no need for spread or root access [07:56] mborzecki: just a small container with python and git [07:57] mborzecki: so that's entirely viable [07:58] nothing is running now [07:58] rebooting for kernel update [07:59] workers will be back in a minute or two [08:00] ok, fixed the profile bit affecting lxd [08:00] it's quite curious [08:00] MS_BIND really matters for MS_REMOUNT [08:00] testing again [08:00] all of main should pass now [08:00] I'll do core next and then add the feature flag I need for safety [08:01] and that should be it :) [08:01] mvo: I'll start working on enabling raa today as we talked [08:09] hm built a uc20 image and it gets stuck in the efi shell [08:09] pretty sure i'm using the same ovmf that worked the last time [08:14] Removing snapd (2.45.1ubuntu0.2) ... [08:14] Failed to execute operation: Connection timed out [08:14] inside containers [08:15] PR snapd#9365 opened: release: 2.47~pre1 [08:18] \o/ [08:24] lxd passed [08:24] regression and core are in progress [08:47] afk, lucy needs me [08:47] both core and regression passed [08:47] just the feature to restore old behavior in case we need it [08:48] but that's after wife is back in a moment [08:48] o/ [08:48] mvo: I made a comment in https://github.com/snapcore/snapd/pull/9293 [08:48] PR #9293: snap: auto-import will not try to auto-create users on managed devices [08:48] pedronis: \o/ [08:48] pedronis: sounds sensible [08:49] mvo: sorry, it's a bit more work, but maybe put us in a better spot [08:49] pedronis: yeah, totally agreed, I like this [09:07] duh, console-conf drops a backtrace when i try to configure the device [09:08] mborzecki physical or vm? [09:08] or snapd isn't quite up yet https://paste.ubuntu.com/p/3RZY7vmC4m/ [09:08] vm [09:09] well, console conf should handle that error [09:09] and probably just retry [09:09] maybe we just got restarted [09:34] mborzecki: please file a bug and we need to put it onto the foundations radar [09:35] mvo: investigating still a bit, maybe it's snapd that's tarting slow [09:36] mvo: and seriously takes a bit of work to get a debug shell on the system :/ [09:36] mvo: but i guess you already know the pain :) [09:36] mborzecki: yes, but it's okay to just file a bug [09:37] uhh, mark boot successful fails, `cannot identify kernel snap with bootloader grub: cannot read dangling symlink kernel.efi` [09:37] mborzecki: and not dive too deep, if it's really a matter of retrying. but sorry, in a meeting so only 20% of my brain is available [09:38] mborzecki: this is not the issue that ian identified the other day that snap-bootstrap older versions eat modeenv keys? [09:38] yeah, omg, need to repack the kernel [09:38] ehh [09:39] i suppose i have what i wanted now anyway [09:40] mvo: a random thought, it'd be great to have at least a debug version of the snapd snap which has `systemd.debug-shell=1 dangerous` baked in [09:43] mborzecki: yeah, I was wondering something similar - and snapd.debug=1 too :) [09:44] mborzecki: maybe we should have this as part of the +testkeys or a similar new build-tag? [09:48] re :) [10:36] I've updated mount-ns test to cope with the new tmpfs [11:22] now added the feature flag [11:22] now for some tests [11:28] brb [11:55] re [12:08] mborzecki: imho the proper way to set systemd.debug-shell=1 dangerous for tests is to make gadget specified kernel cmdlines work, then when we already repack the gadget we can set the extra cmdlines from there [12:09] ijohnson: well, i'm using https://github.com/snapcore/snapd/commit/a1ec67e26bc5fde9ef645bcc8d6e127345cee344 for now ;) [12:09] ijohnson: but yeah, i'd prefer the gadget way [12:19] login.ubuntu.com is down? [12:19] cannot create users in a UC20 vm [12:20] WFM [12:22] ehh, dropped too many modules when repacking the kernel [12:26] PR snapd#9366 opened: gadget: resolve device mapper devices for fallback device lookup [12:27] zyga: any news on google:ubuntu-16.04-64:tests/main/lxd:snapd_cgroup_neither ? [12:27] pedronis: oh? is that broken? [12:27] I ran it today several times [12:28] it failed here: https://github.com/snapcore/snapd/pull/9270/checks?check_run_id=1123940072 [12:28] PR #9270: wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl <⛔ Blocked> [12:28] let me look [12:29] ah, wait, is that the issue we discussed recently [12:29] I remember now, [12:29] zyga: I had multiple errors in that test yesterday [12:29] it's weird, I did see the failure messages but in my case the test ultimately passed (it was slow though) [12:30] I'll check with stgraber about it and re-check with -shell-after, to see if it really passed for me [12:39] pedronis: there is no api to append to zip in Go... but gess what, there is an old juju package from rogpeppe to do this.. https://godoc.org/github.com/juju/zip#Reader.Append [12:39] pstolowski: mmh [12:39] pedronis: it's a fork of stdlib though ... [12:39] and old [12:40] pstolowski: we need to chat again [12:40] for context: https://groups.google.com/g/golang-dev/c/ZSubqlF2G4k?pli=1 [12:40] and https://github.com/golang/go/issues/15626 [12:40] it got nowwhere in stdlib of go [12:46] pstolowski: I also I was confused about something [12:46] pstolowski: anyway let's chat again [12:46] pedronis: ok, now/later? [12:47] pstolowski: as you prefer, but not a lot of time before standup [12:47] pedronis: ok, after then [13:01] PR snapd#9364 closed: tests/lib/cla_check: default to Python 3, tweaks, formatting [14:01] hmm, maybe we still need to improve error handling in nested prepare: https://paste.ubuntu.com/p/FBBRKSKBGH/ [14:01] huh [14:01] if the snap command is available why would it be connection refused talking to the socket [14:02] I guess sudo snap wait system seed.loaded in the nested_retry_until_success with a much shorter timeout on that [14:06] ijohnson: could it be that this ran after the socket was created by system, but before snapd.service started listening (or the service started)? [14:07] mborzecki: but I thought that was the whole point of socket activation [14:08] is that the stuff sent on the socket gets queued and "saved" so that when snapd is ready and starts listening using systemd's fd we just get what was sent before snapd finished starting [14:10] Bug #1887153 changed: Installing network-manager drops the network [14:13] Bug #1887153 opened: Installing network-manager drops the network [14:19] Bug #1887153 changed: Installing network-manager drops the network [14:51] * cachio lunch [15:27] PR snapd#9365 closed: release: 2.47~pre1 [15:47] PR snapd#9367 opened: tests: misc nested changes [15:47] hmm does anybody remember the version of snapd we supported parallel installs of classic snaps? [15:51] degville: when you have time could you review my update to https://forum.snapcraft.io/t/parallel-installs/7679 mentioning classic parallel snap support in 2.43+ ? [15:52] hopefully I didn't botch it too badly :-) [15:53] ijohnson: yes, of course! Looks great - thanks for updating it. [15:53] thanks [16:00] woot, new test passes [16:21] a few more variants to cover everything [16:21] I'll go make tea [16:21] I like days like this [16:21] quiet focus [16:43] mvo, 2.47 is comming today, right? [16:54] -debug time === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [17:22] cachio: could you look at my 9364 again, it seems my change to the debug: section for each suite didn't take when the nested tests failed, so I force pushed a different change which should work now I think === ijohnson is now known as ijohnson|lunch [17:23] ijohnson|lunch, sure [17:23] thanks [17:24] ijohnson|lunch, it is already merged [17:24] cachio: sorry I meant 9367 [17:24] ijohnson|lunch, hehe, ok === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [17:49] cachio: it's already in beta - at least the snapd snap [17:50] cachio: systemd is yet again hold in the review queue === ijohnson|lunch is now known as ijohnson [17:50] mvo, ok, I'll start with snapd, thnanks [17:51] cachio: great, thank you [17:51] * zyga starts to prepare commits === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [18:57] ok, one more case fixed [18:57] this test acts as extra documentation [19:11] still some failures on some systems [19:17] centos/fedora/amazon [19:18] and core [19:18] let's dig at the classic set first [19:18] PR snapcraft#3289 opened: build providers: fix issues running on Windows [19:19] but hey 29 / 40 passed :) [19:27] ijohnson: did you try to build and install an edge system recently? [19:27] cmatsuoka: yes, many [19:27] cmatsuoka: let me read your mind [19:27] cmatsuoka: it's broken isn't it? [19:27] :-) [19:27] ijohnson: hum, I just tried it and it failed to install [19:27] ah ok [19:28] the issue is that we need a kernel snap respin [19:28] ubuntu-core-initramfs was updated with new snap-bootstrap [19:28] but the kernel snap has not been rebuilt yet [19:28] ah I see [19:28] so edge is currently broken [19:28] ah I thought it was published already [19:28] ok [19:29] not yet [19:30] * zyga takes the dog out [19:31] my idea was to build a edge image with maciek's gadget update snapd branch and try it with the edition3 gadget [19:31] and see if it reseals correctly [19:32] yeah you'll need to repack the initramfs with the new version of ubuntu-core-initramfs [19:33] do we have any estimate on when the kernel snap will be ready? [19:33] no idea [19:43] okay [19:44] back and looking at the debug prompt [19:48] huh [19:48] looks like real byg [19:50] printf debug time [20:06] mmm [20:22] ijohnson, cmatsuoka I found something really insteresting about the issue on kvm [20:22] if I use the host system = debian 9 [20:23] no reboots [20:23] oh [20:23] that's interesting [20:23] the only diff is that on debian 9 I coundt make tpm work [20:23] ok, interesting [20:23] debugging [20:23] I need to take a look to that [20:23] but looks like forced host tools [20:24] but why, maybe some silly bug [20:24] but tmp does not affect on the reboots [20:24] anyway, thank for integration tests [20:24] I'll know on the next cycle [20:24] I tested ubuntu without tmp and ti reboots [20:25] so perhaps a solution for us is to replace ubuntu focal by debian 9 [20:25] cachio: debian 9 has really old qemu [20:25] perhaps it doesn't do something fancy enough [20:25] zyga, I am gonna try usign the same qemu on focal [20:25] or doesn't interact with recent security mitigations [20:26] zyga, both things could be the problem [20:27] cachio: but if you can't make tpm work with debian then it seems not useful since we need tpm [20:27] zyga, I'll try with debian sid [20:27] ijohnson, that qemu does not support tpm emulation [20:27] cachio: right but my point is that we need nested vm's with tpm to test uc20 [20:28] ijohnson, yes yes agre [20:28] and afaik the reboots only happen with tpm [20:28] ijohnson, no [20:28] but yes anyways very interesting point about using debian 9 [20:28] ijohnson, reboots happen when we use ovmf [20:28] independently if we use tpm [20:29] I tried removing tpm and the reboots still happen [20:29] cachio: ah I see [20:29] ijohnson, I'll try now with debian sid [20:30] it should support tpm by software [20:30] if sid fails the problem is in qemu/kvm version used [20:32] Yeah good find nonetheless [20:32] sid has qemu 5.1 I believe [20:34] PR snapcraft#3290 opened: build providers: unified provider refactoring for provider setup [20:34] I am creating a new image to support virtualization on sid [20:34] let see [20:39] ah [20:39] what is /etc/sysconfig/snapd:SNAP_REEXEC=0 [20:39] * zyga looks [20:41] ah [20:41] packaging/fedora/snapd.spec:echo [20:41] why? [20:42] at least that explains it [20:43] the test needs adjusting [20:58] if this passes the next error is on core [20:59] I'll keep pushing, open the PR and go to sleep [20:59] but I may be a bit tired tomorrow [21:04] PR snapcraft#3289 closed: build providers: fix issues running on Windows [21:04] fedora passed [21:04] ok, core [21:08] need to stretch back [21:08] brb [21:16] back with water, [21:16] core is rebooting [21:16] I'll know soon [21:20] ah [21:20] hh [21:20] ok, weird [21:20] let's check [21:20] I think the test has a mistake [21:25] ijohnson, cmatsuoka, zyga fails on debian sid [21:25] it reboots [21:25] mmm [21:25] so the qemu version [21:26] I need to find a version with supports tpm and no reboots [21:26] is it using kvm or just software qemu? [21:26] kvm [21:27] if using kvm it should depend on the kernel too [21:27] cmatsuoka, in tha tpast I tried with a very old kernel [21:27] and it rebooted [21:28] an old kernel which supported kvm [21:28] I think I should find a version of qemu which works [21:30] I think we should ask some qemu people [21:33] our case is very specific even for qemu people (nested with ovmf) [21:34] the last time I asked some kvm engineers they said they never worked with that specific scenario :| [21:53] cmatsuoka,just ran in xenial and no reboots [21:53] qemu 2.5 [21:54] hum [21:54] and does it work with tpm? [21:54] no [21:55] now I'' try to find which version works with tpm [21:55] I nee dto go now [21:55] I'll continue after I am back [21:55] need to buy some stuff [21:57] figured it out [21:57] and documented [21:57] man so many sharp edges [21:58] restarting another run [21:58] all systems now [22:11] ok [22:11] I bail [22:11] tomorrow [22:11] see you all