[01:01] ijohnson: edge Snapcraft might let you create device files under LXD now: https://github.com/snapcore/snapcraft/pull/3218 [01:01] PR snapcraft#3218: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes [05:16] morning [06:32] ayy store is down? [06:48] mvo: hey [06:48] mvo: snap downloads fail, store is down apparently https://status.snapcraft.io/ [06:50] mvo: how does one add 2.45.3 milestone to lp? [06:52] mborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk" [06:52] mborzecki: uh, store down not great [06:53] mvo: cool, added 2.45.3 now [06:53] mborzecki: thank you [07:03] morning [07:03] good morning pstolowski [07:09] pstolowski: hey [07:12] Bug #1887760 opened: Installing snap app is not updating required content snap [07:13] mvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/3 [07:15] mvo: aiui storage requirements are higher due to recovery, but not sure about ram, guessing it's roughly the same [07:15] mborzecki: yeah, should be the same size for ram [07:15] mborzecki: we always wanted to create a nested spread test that runs with e.g. 256mb to see if it survives our testsuite [07:16] mvo: hmm didn't claudio try that and then he hit the grub problem? [07:16] (for uc20) [07:16] mborzecki: yeah, I mean for uc16/uc18 [07:16] mborzecki: would still be nice to have such a nested test to ensure we don't regress [07:18] Bug #1887760 changed: Installing snap app is not updating required content snap [07:21] Bug #1887760 opened: Installing snap app is not updating required content snap [07:25] mvo: we don't have an official ballpark number for storage though? [07:27] Bug #1887760 changed: Installing snap app is not updating required content snap [07:27] hmm wonder whether there is liek a reference gadget that's within the minimal requirements range [07:30] Bug #1887760 opened: Installing snap app is not updating required content snap [07:33] mborzecki: it depends a bit on the kernel size [07:33] mborzecki: like you can have custom kernels that are smaller [07:33] ehh, can't build an image, because snapd can't fetch any assertions :/ [07:35] mborzecki: otherwise it's 2*(55Mb+31Mb+1Mb+kernel-size) [07:35] mborzecki: the reference kernel is very big (168mb) but no real device is using that [07:35] mborzecki: well, not *no* but most have a custom optimized kernel [07:36] mhm [07:37] need to run an errand, back in 1h or so [07:54] hmm i store unhappy? even https://api.snapcraft.io times out [07:57] okay, it works but super slow here [08:02] pstolowski: yes, unhappy [08:02] mhm [08:20] re [08:21] the store is back, yay [08:33] good [08:49] is pedronis off today? [10:10] PR snapd#9017 opened: o/snapstate: disk space check in Ensure (4/N) [10:18] pedronis: hi! can we discuss preseed debug after the standup today? [10:40] PR snapd#9018 opened: cmd/snap-preseed: check that target path exists and is a directory on --reset [11:03] mvo: what is the fix-preseed branch for? [11:05] pedronis: this looks like a mistake [11:05] yes, was my mistake [11:05] sorry [11:06] ah [11:06] no worries, I will just delete it [11:06] github confused me yesterday [11:06] removed [11:06] ty [11:09] pstolowski: yes, I'll try to write something down beforehand as well [11:11] pedronis: ok, great, thank you [11:57] pstolowski: I shared a doc [11:59] pedronis: yes, got it, thanks [12:21] PR snapd#9019 opened: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements [12:44] pstolowski: I did a pass on #8960 [12:44] PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) [12:46] pedronis: ty! [13:01] PR snapd#9020 opened: cmd: add new "snap recovery" command [13:22] cachio: switching to test/main/manual now, i'll push a patch soon [13:22] mborzecki, nice, thanks [13:23] mborzecki: do you mean tests/nested/manual ? [13:23] ijohnson: yeah, silly typo ;) [14:05] cachio: i've updated #9019 [14:05] PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements [14:07] mborzecki, nice, thanks, I'll take a look [14:09] cachio: I've run the core20-early-config nested spread test 3 times now and it hasn't failed yet, I'm running this on master: [14:09] spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config [14:09] is that the right test ? [14:10] ijohnson: so it booted then, hmm [14:10] mborzecki: I was trying to reproduce the issue cachio explained about the nested test with cloud-init users not being sudoers [14:11] ijohnson: can you try running google-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke from 9019 too? [14:11] mborzecki: sure I can give it a try [14:11] ijohnson: thanks [14:17] PR snapcraft#3219 opened: meta: detailed warnings for resolution of commands [14:22] ijohnson, yes, it is ok [14:23] sometimes it works 5 times [14:23] and then fails [14:23] cachio: ack I'll keep trying then [14:26] ijohnson: cachio: ha, so i'm starting the vm manually with -serial stdio, and i'm getting `error: invalid signature` (probably coming from grub) and then it gets back to the prompt [14:26] mborzecki: are you using google-nested or qemu-nested ? [14:26] ijohnson: google-nested [14:26] ah then you start a uc20 nested vm right ? [14:27] yes [14:27] yeah that will need the special spread version with mvo's patches to support specifying the -bios option from an env var [14:27] I don't know if the spread that is downloaded from that s3 link has support for that env var or not [14:27] do we use that spread binry in any of the tests arleady? [14:28] good question, I don't know [14:28] I have a locally built version I use [14:28] cachio: ^^ do you know where i can get it from? [14:28] ijohnson: but.. the test is running qemu directly [14:28] mborzecki, I think you need to build it [14:28] ijohnson: as in calling qemu-system-x86_64 arg arg .. [14:29] mborzecki: ah hmm good point and you're using external backend [14:29] mborzecki: maybe you're missing some of the special nested env vars to make booting uc20 work [14:29] mborzecki, spread pr not merged yet [14:30] hmmm i think the test is doing something wrong, we're supposed to boot with efi always [14:30] spread2 does not included that yet [14:30] I could add that [14:30] i mean, start_nested_core_vm_unit, it's not setting -bios unless secure boot is enabled [14:33] yeah, now it's booting all right [14:35] need to run an errand, i'll push the fix when i get back [14:36] cachio: ijohnson: afaict we're always expecting efi for uc20, so we need to pass -bios /usr/share/ovmf/OVMF.fd even if secure boot is not enabled in the test [14:36] mborzecki: should I review 9005 first or 9006 ? [14:37] pedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub [14:53] mborzecki, I'll try that after lunch [14:53] * cachio lunch [14:59] mborzecki: is 9006 ready for review, it doesn't seem to match our last discussion? [15:03] I marked it blocked for now [15:17] pstolowski: I think #9002 should be split (it's smallish now, but the install case likely needs more tests) [15:17] PR #9002: o/snapstate: integrate free space checks with install/refresh and remove (3/N) [15:19] pedronis: sure, will do, thanks [15:21] PR snapd#9014 closed: snapshotstate: move sizer to osutil.Sizer() [15:23] pstolowski: thx [15:29] pedronis: I'm confused as I thought 9006 does implement what we agreed on [15:30] ijohnson: is there a mapping between edition and command line? [15:30] I undersand it has one element atm but there isn't [15:30] yes, see my comment it's through the assets registration [15:30] i.e. [15:30] registerInternal("grub.cfg:edition=1:static_cmdline", []byte(grubBootConfigStaticCmdline)) [15:32] heh [15:32] it's a little odd using the edition=1 in that, but I think it works fine [15:33] it's fairly odd [15:52] ijohnson: mborzecki: I made some more punctual comments [15:55] re [15:57] PR snapd#9021 opened: snap: implement new `snap reboot` command [15:59] ijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while [16:04] mborzecki: sorry to have turned a bit more prescriptive in 9006, I'm happy to have a chat tomorrow but I think I explained what I think is a workable approach, that doesn't get annoying the first time we need to change one of the two things [16:14] pedronis: thanks for the comments, i see what you mean now, i'll tweak how per edition assets are stored internally the, the current string->[]byte would be cumbersome without coming up with a key like i did now [16:15] pedronis: yes that makes sense [16:16] mborzecki: to be clear I think it fine to store the assets as we do now, and have a different storage [16:16] for the snippets (as I called them) [16:17] pedronis: as for 9005, i think that having some code to consume the api would make it clear how SetExtraCommandLineArgs should work (i.e. reseal internally or not?), maybe i should split out the bits that fix the command line and just leave a PR with the setter? [16:19] mborzecki: ijohnson: also about 9006, does it make sense to change the commandline without bumping the edition (this is not supported by my approach either) ? [16:19] mborzecki: 9005, you mean *without* the setter? [16:21] pedronis: yes, without, there's bits that make it clear that the order is and a tweak to bootloader.ManagedAssetsBootloader.CommandLine() [16:21] pedronis: mmm so in that case we would be changing the static portion of the kernel command line. tbh I don't think that will change much if at all for amd64/grub, so I don't think it's imperative we have that accounted for right now, what I think would change more likely over the lifetime of a device is the gadget defined extras [16:22] mborzecki: sounds ok for now [16:23] mborzecki: I meand 9005 without the setter [16:23] pedronis: yup, the chats interleave, but that's what i understood [16:24] ijohnson: yea, anyway to support changing the commandline without bumping the edition, we would need both edition (that controls the updating) and some kind of version to track variation [16:24] we can retrofit it in I suppose if we end up there [16:25] pedronis: you could synthetically create an edition from the asset version + kernel cmdline version [16:25] I think it is probably fine to retrofit something later on [16:25] ijohnson: by definition edition is not synthetic, it's way to say I think old devices should get this [16:26] it's a decision we make [16:26] like for gadget asserts [16:26] *assets [16:26] sorry all I meant is that the decision on whether devices get an update is a function of both edition + cmd line [16:26] that's why we reused the term edition [16:27] ijohnson: yea, but I don't see the static command line as separate from the asset [16:27] I think we are in agreement that it's probably fine to not support that right now internally [16:27] anyway I think we can retrofit things if needed, as long as we are conscious if we stumble on trying to do that [16:28] PR snapcraft#3220 opened: review tools: link or copy snap to snap common [16:28] anyway it's another reason why I don't like templating in the commandline [16:28] it's prone to confusion [16:28] it's a case were repetition is feature [16:28] where [16:29] well repetition is also prone to bugs using different things in different places [16:29] well that's why I said we need a test [16:30] ijohnson: the risk here is doing a change without understanding the consequences [16:30] agreed on a test [16:30] I don't disagree that there are many risks in this area [16:30] mborzecki: also one of my comments is that it's probably time to do use "go generate" or similar [16:31] pedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed [16:32] pedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird [16:33] mborzecki: we can yes, I don't we do for other things though [16:33] I mean I don't have a strong opinion either way, as long as it works [16:33] with the packaging [16:33] this shouldn't change that often (at least after a while) [16:34] pedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated iirc [16:34] yea [16:37] hmm why does ssh start in install mode? [16:37] we don't turn it off unless it's turned off in all modes I think [16:37] (not saying we shouldn't change that) [16:38] ijohnson: cachio: pushed a tweak to #9019 [16:38] PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements [16:39] mborzecki: for clarity: https://github.com/snapcore/snapd/pull/9006#discussion_r455922181 [16:39] PR #9006: bootloader: compose command line with mode and extra arguments <⛔ Blocked> [16:41] ijohnson: hmm i see both /usr/share/ovmf/OVMF.fd and /usr/share/OVMF/OVMF_CODE.fd, i've always used the first one, so what's the difference? :) [16:42] ah I don't know what's the difference haha [16:42] ijohnson: to make it more interesting, botha re owned by ovmf package [16:43] they also are slightly different sizes with different hashes :-/ [16:45] ijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe [16:46] ah so the lowercase dir one is the combined vars and code ? [16:46] ijohnson: that'd make OVMF.fd all-in-one package [16:47] ijohnson: probably makes sense given that you can use your own file to store vars? [16:47] yes so in this context it's probably fine for CI to use a single file [16:54] ijohnson: force pushed a little note === benfrancis6 is now known as benfrancis [18:37] PR snapd#9022 opened: usersession/userd: do not modify XDG_DATA_DIRS when calling xdg-open [18:42] PR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type [18:47] PR snapd#9024 opened: sysconfig/cloudinit: add RestrictCloudInit [18:47] PR snapd#9025 opened: overlord,o/devicestate: restrict cloud-init on Ubuntu Core [18:58] PR snapd#9026 opened: tests/nested/manual: add spread tests for cloud-init vuln [19:55] ijohnson, I could reproduce the error also in another test [19:55] the cloud init one [19:55] and using an image downloaded from cdimage [19:55] so it is not related to that test [19:56] cachio: yeah that's what I kinda expected [19:57] cachio: I have now run that other test 6 times and couldn't reproduce it, if you get a debug shell let me know I would love to take a look at the system [19:57] ijohnson, yes, I'll try to reproduce it here [19:57] ijohnson, quick question [19:57] yeah sure [19:57] I refresh snapd snap from beta to edge and it reboots the systems [19:58] uhhh [19:58] then I revert and the reboot does not happen [19:58] is it expected? [19:58] on uc20 [19:58] why does it reboot when you refresh the snapd snap ? [19:58] afaik we shouldn't reboot with snapd snap refreshes [19:59] well, I expected the same [19:59] cachio: was that just a one time thing or does it always happen ? [19:59] ijohnson, I am trying to finish the test to refresh/revert snandp [19:59] and this happened last time [19:59] now I am running again [20:08] ijohnson, so, the only which requires reboot is the kernel? [20:08] cachio: the kernel, the base snap (core20 for uc20, core18 for uc18, core for uc16), and the gadget snap if and only if there are gadget updates [20:11] ijohnson, ok [20:11] so I need to update the gadget scenario beause I am waiting the reboot [20:16] 👍 === ijohnson is now known as ijohnson|EOD