[00:00] Is there an easy way to nuke all my lxd configuration and just start from scratch? [00:00] Now lxc delete is giving me errors [00:00] a btrfs subvolume is the other option, if you have a large disk (like your /data) already mounted, LXD can also use an empty directory from that as its source [00:00] rm -rf /var/snap/lxd/common/lxd followed by a reboot would be quite efficient at resetting everything [00:01] should get you to the same state as just having installed LXD for the first time [00:01] Okay, great [00:02] Well, that's all I need [00:03] Thank you so much, you've been so helpful! Can't believe that the lxd project lead had time to help me sort through my fuck-up. [00:06] sorry about your containers, hopefully your next setup will be more solid :) [04:28] PR snapd#9779 opened: testutil: make DBusTest use a custom bus configuration file [06:45] morning [07:00] hi mborzecki [07:00] jamesh: hey [07:18] mborzecki: could you have a look at https://github.com/snapcore/snapd/pull/9779 ? -- it's short and should make the dbus unit tests a little more robust [07:18] PR #9779: testutil: make DBusTest use a custom bus configuration file [07:18] jamesh: sure, will do [07:19] mborzecki: it basically just disables service activation for the DBusTest private session bus [07:20] hey mborzecki and jamesh [07:20] hi mvo [07:23] jamesh: yeah, that sounds like a good idea, it'd be a bummer if some known service got activated on a test bus [07:24] mvo: sorry for confusing comments in #9776, i clearly shouldn't be doing reviews that late ;) [07:24] PR #9776: gadget: add validation for "$kernel:ref" style content [07:39] jamesh: +1 [07:52] mborzecki: thanks [08:00] morning [08:42] mvo: https://github.com/snapcore/snapd/pull/9776#discussion_r539976882 i'll play with it locally to see if i can propose a diff that would not use the regex [08:42] PR #9776: gadget: add validation for "$kernel:ref" style content [08:48] mborzecki: thanks, looks like it needs to be stricter. feel free to push something else, if so please make it a helper because the regexp is used in the followup [08:48] mborzecki: something like parserKernelRef(ref) (tag, path, error) or something [08:50] I'm very confused by https://github.com/snapcore/snapd/pull/9775 it has unit tests failures that don't make sense to me [08:50] PR #9775: gadget,o/devicestate,tests: drop EffectiveFilesystemLabel and instead set the implicit labels when loading the yaml [08:51] anyway I need to push to it again [09:14] Bug #1906621 changed: System doesn't do FDE when installing with secure boot enabled [09:23] mvo: there's a mismatch between what kernel/kernel.go treats as valid asset name and #9776, i'll tweak it to allow [a-zA-Z0-9][a-zA-Z0-9-]* like your PR does [09:23] PR #9776: gadget: add validation for "$kernel:ref" style content [09:24] mborzecki: \o/ thank you [09:49] mvo: pushed a couple of patches to 9776, please take a look, if the asset name validation is too lax we can revert the relevant patch [09:52] ta, in a meeting I have a look in a wee bit [10:17] pstolowski, mborzecki hi, could you take a look to #9737 please [10:17] PR #9737: tests: use os.query tool instead of comparing the system var [10:17] cachio: hey, will do [10:17] thanks [10:18] pedronis: sure [10:19] mvo, hey, still this test failing for sbuild test on debian https://paste.ubuntu.com/p/76pSQXqS52/ [10:19] mvo, the only one [10:22] mborzecki: ? [10:22] pedronis: uhh, sorry [10:22] cachio: sure :) [10:23] mborzecki, tx [10:24] ah, I was confused because the obvious other p* recipient would have been Pawel [10:29] cachio: uh, right. thanks for the reminder [10:29] mvo, yaw [10:34] pstolowski, hey, I see the hotplug test failing for 20.04 and 2.10 https://travis-ci.org/github/snapcore/spread-cron/builds/748673129#L5564 [10:35] pstolowski, I'll try to reproduce it [10:41] cachio: ok [10:43] cachio: did start failing today? [10:44] not sure, because previous days it was failing because a problem with travis [10:44] the dependencies problem started during the weeken on travis [10:44] and then I fixed that yesterday and next run I see this error on hotplug [10:45] cachio: ok. but before that it was passing right? [10:45] yes [10:45] or we didn't notice? [10:45] ok [10:46] https://travis-ci.org/github/snapcore/spread-cron/builds/748546888 [10:46] yesterday after the fix it passed [10:58] cachio: I'm getting this: 2020-12-10 10:30:03 Cannot allocate google-nested:ubuntu-18.04-64: cannot find any Google image matching "ubuntu-1804-64-virt-enabled" on project "computeengine" or "ubuntu-os-cloud" [10:59] do we need to clean the image list? [10:59] pedronis, I just did it 20 minutes ago [10:59] pedronis, is it still happening? [10:59] maybe I started just before [10:59] I'll wait a bit and re-run [11:00] pedronis, nice, thanks [11:00] cachio: i don't see classic/hotplug in yesterday's log [11:00] only core/hotplug [11:01] pstolowski, right [11:01] it is a different run [11:02] pstolowski, I don't have previous runs [11:03] all of them have failed with the dependencies error [11:03] cachio: ok [11:10] PR snapd#9780 opened: many: use ResolvedSource() from gadget content when writing boot assets [11:11] mvo: I reviewed #9758 [11:11] PR #9758: secboot: add new LockSealedKeys() that uses either TPM/fde-reveal-key [11:11] pedronis: \o/ thank you [11:12] mvo, I see this on uc20 nested tests https://paste.ubuntu.com/p/vTqb9dTZfS/ [11:12] on uc20 [11:12] it is trying to find core snap [11:20] cachio: reviewed [11:21] pstolowski, thanks [11:28] cachio: oh, this is strange indeed, why is it trying to start snapd from core on a uc20 system :/ what is the full log? [11:29] mvo, https://paste.ubuntu.com/p/WngswJTXFs/ [11:29] I am researching why some tests are failing on uc20 [11:29] I saw that [11:29] I ran from my machine [11:30] this test google-nested:ubuntu-20.04-64:tests/nested/core20/gadget-reseal [11:30] cachio: thank you! [11:46] hm, I see a tests/core/netplan test failure with undefined symbol netplan_parse_yaml() - is this a fluke or did others see this too? [11:49] mvo, I saw many tests fail with similar errors [11:49] all of them on uc20 test suite [11:50] mvo: i think we can land https://github.com/snapcore/snapd/pull/9779 failures are unrelated [11:50] PR #9779: testutil: make DBusTest use a custom bus configuration file [11:52] mborzecki: yes [11:52] cachio: thanks [11:53] ijohnson: looks like test-snapd-netplan-apply is auto-uploaded by you currently, what recipe is providing this currently? [11:55] PR snapd#9779 closed: testutil: make DBusTest use a custom bus configuration file [11:56] stgraber: hey, quick question, would it be possible for lxd snap to drop install hook completely and move it's logic (which is just mkdir/chmod) to daemon.activate script? [12:00] ijohnson: nevermind, found it [12:05] PR snapd#9781 opened: gadget/quantity: introduce Offset, start using it for offset related fields in the gadget [12:18] pstolowski, hey, I don't get this comment https://github.com/snapcore/snapd/pull/9737#discussion_r540083054 [12:18] PR #9737: tests: use os.query tool instead of comparing the system var [12:20] cachio: yeah sorry, i think i was confused [12:20] pstolowski, nice, [12:20] np [12:22] +1 [12:25] interesting failure in unit tests https://paste.ubuntu.com/p/9MBwSdktSv/ [12:27] so my gadget changes might be breaking something for real, many core20 nested tests failed to prepare [12:27] fwiw, I filed https://github.com/anonymouse64/test-snapd-netplan-apply/issues/1 for the netplan test fialures [12:27] though the error is not obvious [12:45] PR snapd#9768 closed: daemon: start splitting snaps op tests out of api_test.go [12:46] i need 2nd reviews for #9732 and #9429 (order doesn't matter, they are independent) [12:46] PR #9732: asserts: snapasserts method to validate installed snaps against validation sets [12:46] PR #9429: o/daemon: validation sets api and basic spread test [12:51] pstolowski: related, I forgot that my change going forward has now landed: https://github.com/snapcore/snapd/pull/9429/files#r540141892 [12:51] PR #9429: o/daemon: validation sets api and basic spread test [12:51] pedronis: ah right, that crossed my mind yesterday, will update [14:33] do we still need /usr/lib/snapd/system-shutdown helper? [14:36] mvo: we should probably talk anyway about the reseal issue, I have some ideas [14:42] pedronis: sounds good, please give me 2min [14:42] pedronis: I pushed something trivial as a starting point, I can be in the HO in 2min [14:44] I'm in the standup [14:45] PR snapd#9782 opened: devicestate: make DeviceManager.hasFDESetupHook() more robust [15:00] pedronis: sorry! I have 30min more, meeting either got moved or I misremembred the time. but we were done, right? [15:02] mvo: we are done [15:02] I'm taking a break [15:02] pedronis: I work on the discussed fix now, enjoy your break [15:25] PR snapd#9782 closed: devicestate: make DeviceManager.hasFDESetupHook() more robust [15:25] pedronis: addressed your feedback on #9778 [15:25] PR #9778: asserts/repair.go: add "bases" and "modes" support to the repair assertion [15:25] * ijohnson goes to work on netplan now [15:30] pedronis: pushed the first bit of what we discussed and should unbreak master but need to run for meeting now :( [15:30] PR snapd#9783 opened: gadget: use "sealed-keys" to determine what method to use for reseal [15:32] hey mvo do you have logs from the netplan failure, I can't reproduce it [15:32] I tried on a uc20 system, perhaps I should try on uc18 ? [15:34] ijohnson: I think it's only python3.5 [15:34] mvo: so where did you see it fail? [15:35] ijohnson: I did see it on 16.04 [15:35] so ubuntu core 16 or ubuntu 16.04 ? [15:35] ijohnson: ubuntu 16.04 [15:35] afaik that snap should only be used on core systems, not classic [15:35] hmm [15:36] ah I see it is used on classic with the fake netplan service we run in tests/main/fake-netplan-apply === mup_ is now known as mup [16:19] hmm I don't think that layout is enough, it still complains about not being able to load the fil [16:20] *not being able to load/find that symbol from the file [16:25] PR snapd#9784 opened: interfaces/builtin/network-setup-control: allow using netplan apply directly [16:43] pstolowski: hmm, if you look at the comment in the install hook, it states that it creates the path needed by the unit, so the snap.lxd.daemon.unix.socket unit would fail to initialize if that wasn't present. [16:43] pstolowski: (or would initialize and allow everyone to list the path content which may arguably be worse) [16:45] can someone please do a second review for #9758 ? [16:45] PR #9758: secboot: add new LockSealedKeys() that uses either TPM/fde-reveal-key [16:49] stgraber: ah of course, i see it now, thanks [16:49] mvo I will review it today, I started yesterday [16:49] ijohnson: \o/ [16:49] ijohnson: thank you! [16:49] pedronis: I responded to a suggestion in #9784, thoughts ? [16:50] PR #9784: interfaces/builtin/network-setup-control: allow using netplan apply directly [16:51] ijohnson: sorry, I meant not to include err [16:51] pedronis: ah ok [16:51] sure that's fine [16:52] ijohnson: there's code like that also in model.go [16:52] got it, makes sense [16:53] pedronis: pr is updated [16:56] ijohnson: thx === ijohnson is now known as ijohnson|lunch [19:09] * cachio afk === pedronis_ is now known as pedronis === ijohnson|lunch is now known as ijohnson [22:47] PR snapd#9785 opened: tests/main/fake-netplan-apply: disable test on xenial for now <âš  Critical>