[06:52] morning [07:32] school run [07:51] good morning [07:55] re [07:55] mvo: zyga: hey [07:55] :-) [07:55] mvo hey [07:55] good morning zyga and mborzecki ! [07:56] mvo I learned of a very useful feature of raspberry pi yesterday [07:56] mvo pi can be booted from USB (as in driven by USB connection entirely) without any SD cards [07:56] there are official tools and support for that [07:57] the configuration is quite flexible, allowing "override" from usb or fallback to regular boot [07:57] there's also some very useful thing you should look at at some point, allowing watchdog recovery during boot process that hanged [07:57] and the best thing is, it's just a toggle, very easy to set up, unrelated to anything on SD cards [07:58] I also had a look at the try boot mode [07:58] but I didn't run that yet [07:58] zyga: sounds super interssting, I would love to hvae the watchdog boot, I think that would be a great win [07:59] not sure if I will pick any of that up as a part of my work yet, as priority for pi is currently low, but I think it's fairly complete in terms of features for both testing and proper IOT operation [07:59] let me show you how to enable it [08:00] this is the try boot mode: https://github.com/raspberrypi/linux/commit/757666748ebf69dc161a262faa3717a14d68e5aa [08:00] it's an out of tree patch, as far as I know, it would needed to be applied to the ubuntu pi kernel [08:01] the boot selection and watchdog are described on https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md [08:01] the things to grep for are MAX_RESTARTS [08:01] zyga: yeah, dave told us about the tryboot, we plan to use this, ideally in close cooperation with dave [08:02] mvo, that's it so far, I'm off to learn yoto layering [08:02] mvo oh, I submitted zmk to fedora [08:02] opensuse is next [08:03] and then I can see if it would be possible to improve small bits of snapd makefiles with it [08:06] zyga: cool! thanks for the pointers, I check that out [08:06] mvo I also found POWER_OFF_ON_HALT interesting, it might be a good thing to expose via gadget [08:06] so if you have no hats, your pi can really shut down and stay off [08:06] and not just reboot like it does today [08:07] pstolowski good morning :) [08:07] heya [08:07] pstolowski: hey [08:18] mvo: hey, i've tagged https://github.com/snapcore/snapd/pull/9883 for 2.49, going to add a unit test to it [08:18] PR #9883: cmd/snap-preseed: initialize snap.SanitizePlugsSlots for gadget in seeds [08:24] pstolowski: thank you! [09:13] hello, is there a way to get snapd working on old ubuntu 11.10? (Don't ask why not upgrade etc :D) [10:00] Fleck: no, due to systemd, apparmor & old kernel. 14.04 was the oldest that got snapd support, and that already was challenging [10:01] ok, thank you pstolowski [10:16] there is https://help.ubuntu.com/community/EOLUpgrades to get you to a supported release though [10:51] mborzecki: fwiw, I replied to 9873 [10:51] mborzecki: tl;dr happy to change thing but it would not be symetrical to what we do with layOutStructureContent anymore [11:12] ogra: yes, I know that, thanks! :) [11:41] ijohnson: hey, is it ok to squash-merge 9885 or would you rather keep the individual commits because they are "nicer" than lumbing them together? [11:42] hey mvo [11:42] let me take a look, I don't remember what 9885 is [11:42] ijohnson: no worries [11:42] ijohnson: also no rush [11:42] mvo: yeah it should be fine to squash merge them if you want to, but note that I didn't add any unit tests there yet, someone should do that before we merge I think [11:43] I meant to do that but didn't get time on Friday, I called this out in the SU doc, but I guess I forgot to explain that in the PR description [11:43] ijohnson: oh, ok [11:44] ijohnson: I add a note there [11:44] let me try and write some quickly since it doesn't appear that anyone else has pickedu p the mantle [11:44] ijohnson: thanks! no rush fwiw [11:46] pstolowski: is it ok to squash merge 9883? [11:46] mvo: yes! [11:46] ta [12:13] mvo: commented in #9873 [12:13] PR #9873: gadget: add new ResolvedContent and populate from LayoutVolume() [12:20] pedronis: nice! [12:34] How does UbuntuCore ensure that systemd is able to see installed snap packages' .mount unit files on boot ? [12:34] in our case we are seeing https://github.com/systemd/systemd/issues/8732 -- Does UbuntuCore incorporate some sort of "hack" for that ? [12:34] maybe ogra you know that ^ [12:35] I tried creating bind mounts for /etc/systemd/system on an external partition and systemd seems to always "miss" those units [12:36] no, there is no hack regarding systemd stuff on core [12:36] snapd just puts the files into /etc/systemd/system IIRC and relies on systemd to DTRT with them [12:38] and /etc/system i writable per /etc/system-image/writable-paths [12:38] s/i/is/ [12:38] err ... /etc/systemd indeed [12:39] for a "classic" system that is generally fine. For a system where rootfs is read-only we have to bind-mount /etc/systemd on a "writable" partition and when I actually do that, systemd seems to "miss" the .mount units all together [12:40] systemctl daemon-reload and systemctl start default.target seems to "fix" that but that's a hack really. [12:40] Anyways, it's good to know that UbuntuCore doesn't any such hacks, so I guess the issue is likely on my end [12:44] pedronis: I had a revert bits in 9873 again, sorry for that. the overlord tests fail and I think I can only add this in 9875 because before passing the kernelroot is not wired up yet in the higher layers :/ [12:44] pedronis: sorry for that, I only ran the local tests but not the overlord tests initially [12:44] mvo: ok [13:09] om26er: well that's what ubuntu core does, /etc/systemd/system comes from a writable partition, as do a couple of other locations [13:10] om26er: this files defines relevant locations: https://github.com/snapcore/core20/blob/master/static/etc/system-image/writable-paths [13:15] mborzecki my fstab, inspired by the above link looks like https://gist.github.com/om26er/0a331e5cd20b81ecd81fc9bd85c39c69 -- However it seem there is a race condition somewhere. Sometimes systemd is not able to see the mount units of my snap packages, hence their mounting gets skipped, causing broken snaps [13:16] om26er: ubuntu core mounts the units before systemd starts frm the initrd, hence why it works w/o race conditions on ubuntu core [13:17] ijohnson ah, that would definitely explain it. [13:18] om26er: hmm otoh fstab generator runs early, afaict it should pick up those mounts and then they would get ordered before snaps? [13:20] I think Lennart's reply here https://github.com/systemd/systemd/issues/8732 also supports what ijohnson said. I was curious to know what exactly UbuntuCore is doing to circumvent that [14:21] mvo: https://github.com/snapcore/snapd/pull/9867 [14:21] PR #9867: overlord/devicestate: task for updating boot configs, spread test [14:21] ta [14:28] mvo: gadget assets update is only added on !classic [14:28] mborzecki: \o/ [14:29] mborzecki: thanks! then I just need to update the test we have to either remodel on classic or to have a kernel snap :) [14:29] mvo: #9867, ijohnson was also planning to look at it [14:29] PR #9867: overlord/devicestate: task for updating boot configs, spread test [14:30] mvo: Pawel's: #9842 #9850 [14:30] PR #9842: store: switch to v2/assertions api

[14:30] PR #9850: store: method for fetching validation set assertion

[15:28] PR snapd#9873 closed: gadget: add new ResolvedContent and populate from LayoutVolume() [15:48] PR snapd#9886 opened: gadget: cleanup MountedFilesystem{Writer,Updater} [17:19] PR snapd#9842 closed: store: switch to v2/assertions api

[17:54] PR snapd#9887 opened: seed: add LoadEssentialMeta to seed16 and allow all of its implementations to be called multiple times [18:48] PR snapcraft#3433 closed: Allow revoking validation assertions (LP: #1912332) === gurmble is now known as grumble [19:54] PR snapd#9850 closed: store: method for fetching validation set assertion

=== the-mentor8 is now known as the-mentor [21:19] PR snapcraft#3434 opened: build providers: clean environment if project directory is changed