[06:52] <mborzecki> morning
[07:32] <mborzecki> school run
[07:51] <zyga> good morning
[07:55] <mborzecki> re
[07:55] <mborzecki> mvo: zyga: hey
[07:55] <zyga> :-)
[07:55] <zyga> mvo hey
[07:55] <mvo> good morning zyga and mborzecki !
[07:56] <zyga> mvo I learned of a very useful feature of raspberry pi yesterday
[07:56] <zyga> mvo pi can be booted from USB (as in driven by USB connection entirely) without any SD cards
[07:56] <zyga> there are official tools and support for that
[07:57] <zyga> the configuration is quite flexible, allowing "override" from usb or fallback to regular boot
[07:57] <zyga> there's also some very useful thing you should look at at some point, allowing watchdog recovery during boot process that hanged
[07:57] <zyga> and the best thing is, it's just a toggle, very easy to set up, unrelated to anything on SD cards
[07:58] <zyga> I also had a look at the try boot mode
[07:58] <zyga> but I didn't run that yet
[07:58] <mvo> zyga: sounds super interssting, I would love to hvae the watchdog boot, I think that would be a great win
[07:59] <zyga> 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] <zyga> let me show you how to enable it
[08:00] <zyga> this is the try boot mode: https://github.com/raspberrypi/linux/commit/757666748ebf69dc161a262faa3717a14d68e5aa
[08:00] <zyga> 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] <zyga> the boot selection and watchdog are described on https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md
[08:01] <zyga> the things to grep for are MAX_RESTARTS
[08:01] <mvo> zyga: yeah, dave told us about the tryboot, we plan to use this, ideally in close cooperation with dave
[08:02] <zyga> mvo, that's it so far, I'm off to learn yoto layering
[08:02] <zyga> mvo oh, I submitted zmk to fedora
[08:02] <zyga> opensuse is next
[08:03] <zyga> and then I can see if it would be possible to improve small bits of snapd makefiles with it
[08:06] <mvo> zyga: cool! thanks for the pointers, I check that out
[08:06] <zyga> mvo I also found POWER_OFF_ON_HALT interesting, it might be a good thing to expose via gadget
[08:06] <zyga> so if you have no hats, your pi can really shut down and stay off
[08:06] <zyga> and not just reboot like it does today
[08:07] <zyga> pstolowski good morning :)
[08:07] <pstolowski> heya
[08:07] <mborzecki> pstolowski: hey
[08:18] <pstolowski> 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] <mup> PR #9883: cmd/snap-preseed: initialize snap.SanitizePlugsSlots for gadget in seeds <Bug> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9883>
[08:24] <mvo> pstolowski: thank you!
[09:13] <Fleck> hello, is there a way to get snapd working on old ubuntu 11.10? (Don't ask why not upgrade etc :D)
[10:00] <pstolowski> Fleck: no, due to systemd, apparmor & old kernel. 14.04 was the oldest that got snapd support, and that already was challenging
[10:01] <Fleck> ok, thank you pstolowski
[10:16] <ogra> there is https://help.ubuntu.com/community/EOLUpgrades to get you to a supported release though
[10:51] <mvo> mborzecki: fwiw, I replied to 9873
[10:51] <mvo> mborzecki: tl;dr happy to change thing but it would not be symetrical to what we do with layOutStructureContent anymore
[11:12] <Fleck> ogra: yes, I know that, thanks! :)
[11:41] <mvo> 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] <ijohnson> hey mvo
[11:42] <ijohnson> let me take a look, I don't remember what 9885 is
[11:42] <mvo> ijohnson: no worries
[11:42] <mvo> ijohnson: also no rush
[11:42] <ijohnson> 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] <ijohnson> 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] <mvo> ijohnson: oh, ok
[11:44] <mvo> ijohnson: I add a note there
[11:44] <ijohnson> let me try and write some quickly since it doesn't appear that anyone else has pickedu p the mantle
[11:44] <mvo> ijohnson: thanks! no rush fwiw
[11:46] <mvo> pstolowski: is it ok to squash merge 9883?
[11:46] <pstolowski> mvo: yes!
[11:46] <mvo> ta
[12:13] <pedronis> mvo: commented in #9873
[12:13] <mup> PR #9873: gadget: add new ResolvedContent and populate from LayoutVolume() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9873>
[12:20] <mvo> pedronis: nice!
[12:34] <om26er> How does UbuntuCore ensure that systemd is able to see installed snap packages' .mount unit files on boot ?
[12:34] <om26er> in our case we are seeing https://github.com/systemd/systemd/issues/8732 -- Does UbuntuCore incorporate some sort of "hack" for that ?
[12:34] <om26er> maybe ogra you know that ^
[12:35] <om26er> I tried creating bind mounts for /etc/systemd/system on an external partition and systemd seems to always "miss" those units
[12:36] <ogra> no, there is no hack regarding systemd stuff on core
[12:36] <ogra> snapd just puts the files into /etc/systemd/system IIRC and relies on systemd to DTRT with them
[12:38] <ogra> and /etc/system i writable per /etc/system-image/writable-paths
[12:38] <ogra> s/i/is/
[12:38] <ogra> err ... /etc/systemd indeed
[12:39] <om26er> 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] <om26er> systemctl daemon-reload and systemctl start default.target seems to "fix" that but that's a hack really.
[12:40] <om26er> 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] <mvo> 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] <mvo> pedronis: sorry for that, I only ran the local tests but not the overlord tests initially
[12:44] <pedronis> mvo: ok
[13:09] <mborzecki> 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] <mborzecki> om26er: this files defines relevant locations: https://github.com/snapcore/core20/blob/master/static/etc/system-image/writable-paths
[13:15] <om26er> 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] <ijohnson> 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] <om26er> ijohnson ah, that would definitely explain it.
[13:18] <mborzecki> om26er: hmm otoh fstab generator runs early, afaict it should pick up those mounts and then they would get ordered before snaps?
[13:20] <om26er> 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] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/9867
[14:21] <mup> PR #9867: overlord/devicestate: task for updating boot configs, spread test <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9867>
[14:21] <mvo> ta
[14:28] <mborzecki> mvo: gadget assets update is only added on !classic
[14:28] <mvo> mborzecki: \o/
[14:29] <mvo> 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] <pedronis> mvo: #9867, ijohnson was also planning to look at it
[14:29] <mup> PR #9867: overlord/devicestate: task for updating boot configs, spread test <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9867>
[14:30] <pedronis> mvo: Pawel's:  #9842 #9850
[14:30] <mup> PR #9842: store: switch to v2/assertions api <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9842>
[14:30] <mup> PR #9850: store: method for fetching validation set assertion <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9850>
[15:28] <mup> PR snapd#9873 closed: gadget: add new ResolvedContent and populate from LayoutVolume() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9873>
[15:48] <mup> PR snapd#9886 opened: gadget: cleanup MountedFilesystem{Writer,Updater} <Run nested> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9886>
[17:19] <mup> PR snapd#9842 closed: store: switch to v2/assertions api <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9842>
[17:54] <mup> PR snapd#9887 opened: seed: add LoadEssentialMeta to seed16 and allow all of its implementations to be called multiple times <Created by pedronis> <https://github.com/snapcore/snapd/pull/9887>
[18:48] <mup> PR snapcraft#3433 closed: Allow revoking validation assertions (LP: #1912332) <Created by nessita> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3433>
[19:54] <mup> PR snapd#9850 closed: store: method for fetching validation set assertion <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9850>
[21:19] <mup> PR snapcraft#3434 opened: build providers: clean environment if project directory is changed <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3434>