[02:08] <jamesh> amurray: if you've got a chance at some point, I'd appreciate some feedback on https://forum.snapcraft.io/t/proposal-add-polkit-and-polkit-agent-interfaces-to-snapd/23876
[02:09] <jamesh> I know the post is pretty long, but I think it covers most of the bases for what these interfaces need to do
[05:49] <mborzecki> morning
[06:19] <mup> PR snapd#10160 opened: tests, overlord: extend unit tests, extend spread tests to cover full command line support <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10160>
[06:32] <zyga> good morning
[06:32] <mborzecki> zyga: hey
[06:32] <zyga> mborzecki hey
[06:32] <mborzecki> heh, unlucky me: ownload snap "core" (10958) from channel "stable" (received an unexpected http response code (503) when trying to download https://api.snapcraft.io/api/v1/snaps/download/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_10958.snap)
[06:32] <zyga> :)
[07:09] <pstolowski> morning
[07:13] <pedronis> pstolowski: hi
[07:15] <mborzecki> pstolowski: hey
[07:18] <mvo> good morning pstolowski, pedronis and mborzecki
[07:19] <mborzecki> mvo: hey, can I ask you to take a look at https://github.com/snapcore/snapd/pull/10156 ? :)
[07:19] <mup> PR #10156: boot, bootloader, bootloader/assets: support for full command line override from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10156>
[07:19] <mvo> mborzecki: sure!
[07:20] <mborzecki> mvo: and this one: https://github.com/snapcore/snapd/pull/10148 maybe if you could start with this one first
[07:20] <mup> PR #10148: overlord/devicestate, overlord/snapstate: add task for updating kernel command lines from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10148>
[07:45] <mborzecki> quick errand, back in 30
[07:50] <zyga> mvo good morning
[07:51] <zyga> mvo I've sent a patch for snapd, probably needs more discussion and tweaks, wanted to know what you think: https://github.com/snapcore/snapd/pull/10158
[07:51] <mup> PR #10158: packaging: build without dwarf debugging data <Created by zyga> <https://github.com/snapcore/snapd/pull/10158>
[07:51] <mvo> zyga: good morning!
[07:51] <mvo> zyga: let me check
[07:52] <zyga> mvo: separately, I have an idea o how to make pi recovery work for bad kernels without uboot in the loop
[07:52] <mvo> zyga: iirc debuild/dh-golang will strip already
[07:52] <zyga> mvo: not sure if you are interested in that product-wise (it's more of a demo platform)
[07:52] <mvo> zyga: that's probably why ian sees no difference in the build snapd
[07:52] <zyga> mvo: my installed snapd is larger than the one I build locally
[07:52] <zyga> mvo: I realize stripping happens but perhaps it's not the same (toolchain immaturity?)
[07:52] <mvo> zyga: the pi recovery would use piboot and the os-prefix?
[07:53] <zyga> mvo: the native bootloader but not os-prefix
[07:53] <mvo> zyga: oh, interessting, that's strange then. if you build using snapcraft/dpkg-buildpackage and not see stripped binaries that's something worth looking into of course :)
[07:53] <zyga> mvo: I need to write it down, the essence is that the firmware supports boot-once logic
[07:54] <zyga> mvo: and then another feature of the bootloader that can allow you to have a fallback to what worked
[07:54] <mvo> zyga: waveform had some ideas about fallback for pi using piboot (the native bootloader), not sure the details written somewhere that is accessible for you
[07:54] <zyga> mvo: and lastly a feature of the partition table
[07:54] <zyga> mvo: all in all, no uboot needed
[07:54] <zyga> mvo: I would love to exchange ideas
[07:54] <mvo> zyga: that partition table bit is new
[07:54] <mvo> zyga: interessting! yeah, totally in favour of this :)
[07:55] <zyga> mvo: it would be incompatible with current formatting
[07:55] <zyga> mvo: it would require a gadget with different partition layout and some small amount of code to handle this on snapd side
[07:55] <zyga> mvo: os-prefix is very useful but there's only one you can set
[07:56] <zyga> mvo: and while there is recovery kernel, you cannot trigger anything to go into that if you have a non-empty kernel that is busted
[07:56] <zyga> waveform: ^^
[07:57] <zyga> mvo: on the sizes, what is the size of snapd you get now?
[07:57] <zyga> mvo: my local system has a 27MB binary
[07:58] <zyga> mvo: the one I have built is 23MB
[07:59] <zyga> mvo: with snap{,d,ctl,-repair,-bootstrap} combined it should add up quickly
[07:59] <zyga> I probably missed a binary or two by now
[08:06] <mvo> zyga: yeah, I have 27 as well
[08:07] <zyga> mvo: so I suspect either 1) strip is not the same as the flag I pass
[08:07] <zyga> mvo: or 2) strip is not really done
[08:07] <mvo> zyga: yeah, something is off and 5mb per binary is nothing to sneeze at
[08:07] <zyga> mvo: yeah, totally
[08:07] <zyga> mvo: I'll go work on my day job now, let me know if you figure something out
[08:09] <mvo> zyga: yeah, thanks for this! will try to find time, we are at the end of cycle scramble right now
[08:10] <zyga> mvo: oh right
[08:10] <zyga> mvo: good luck!
[08:10] <mvo> zyga: thank you!
[09:22] <mborzecki> re
[09:23] <mborzecki> damn, that took long
[09:41] <mvo> pedronis_: any concerns if I merge 10110 (the dsp PR) without your review? has two +1 (from security and from me)
=== alan_g_ is now known as alan_g
=== pedronis_ is now known as pedronis
[09:52] <pedronis> mvo: I think we were waiting for testing results? did we know if it works for its audience
[09:52] <pedronis> *do we
[09:52] <pedronis> mvo: we should probably chat about it at the standup
[09:55] <mvo> pedronis: sure, we can chat there. worst is is that we would revert, having it on edge seems useful but let me ping the users if it works
[09:55] <pedronis> mvo: I think Ian made a branch but not sure
[09:56] <mvo> pedronis: I don't see one but let me chase this then
[10:00] <pedronis> mvo: anyway I asked a question there about the flavor name
[10:01] <mvo> thanks!
[10:25] <mup> PR snapd#10161 opened: boot, gadget: move opening the snap container into the gadget helper <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10161>
[10:35] <mborzecki> ehh no luck with tests today:  E: The repository 'https://packages.microsoft.com/repos/azure-cli focal Release' no longer has a Release file.
[11:13] <waveform> zyga, sorry - just noticed the pings above! Do you know about the "tryboot" facility that got added to the pi's bootloader late last year?
[11:14] <zyga> about the reboot2 thing?
[11:14] <zyga> or is there something else that allows that?
[11:16] <zyga> I know about a way to reboot and leave a note in the vc register to boot from another partition
[11:16] <waveform> something else: late last year the foundation added a "tryboot" facility which is an ephemeral fallback facility. It's used by running "sudo systemctl reboot tryboot" IIRC (requires a kernel patch and an up to date bootcode.bin/EEPROM); that sets a read'n'reset register which on the subsequent reboot causes the bootloader to load tryboot.txt instead of config.txt. If that boot fails, a subsequent boot will drop back to config.txt as usual
[11:16]  * pstolowski lunch
[11:16] <zyga> oh that's interesting
[11:16] <zyga> so same partition
[11:16] <waveform> yeah, it's different to the watchdog register that permitted directing boot to another partition -- that predates the tryboot facility
[11:16] <waveform> yes, same partition
[11:16] <zyga> and separate conifg.txt?
[11:16] <waveform> yes
[11:16] <waveform> called tryboot.txt
[11:17] <zyga> is that documented? I only found the register documentation and config.txt/autoboot.txt references in noobsw
[11:17] <zyga> *noobs
[11:17] <waveform> let me see if I can find the relevant commits (that's the only documentation at the moment)
[11:17] <zyga> I was thinking of using a pair of boot partitions
[11:17] <zyga> and booting to the 2nd one for "try" boot with a one-time reboot2 trick
[11:18] <zyga> then if that worked, edit mbr in place to swap A/B boot partitions
[11:18] <waveform> yup -- provided you've got a "guaranteed bootable" kernel on the first partition that's certainly workable too
[11:18] <zyga> so the idea is that partition 1 and 2 are swapped "in place" by editing MBR
[11:18] <zyga> and the other partition is the safe one
[11:19] <waveform> interesting -- I should note that the pi's bootloader now supports GPT too
[11:19] <zyga> so 1st partition is always good
[11:19] <zyga> even though it may be the second partition on disk (but first in mbr)
[11:19] <zyga> oh that's great
[11:19] <zyga> I was worried about MBR
[11:19] <waveform> yeah, think that got added in ... eerm  ... December last year? I forget exactly
[11:19] <zyga> nice
[11:20] <zyga> so systemctl reboot tryboot sets the same register?
[11:20] <zyga> it takes a string, parses that to a number and dumps that into that four-letter register (forgot the name) that picks the partition
[11:20] <zyga> is there a magic value that does "tryboot.txt"
[11:21] <waveform> good question -- just looking for the kernel commits
[11:21] <zyga> I was also looking at the ubuntu kernel
[11:21] <zyga> to see if I can read the register with reboot reason
[11:21] <zyga> but that module is not present somehow
[11:21] <zyga> so I used videocore RPC to read it
[11:24] <waveform> ah, apparently it was november when they added the "full" version that supported all pi models (the initial tryboot implementation in october 2020 was pi4 only)
[11:24] <pedronis> mborzecki: thanks for review jamesh PR
[11:25] <waveform> https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md#2020-11-24-bcm2711-xhc-boot-support---beta
[11:25] <waveform> ah, and here's the kernel change: https://github.com/raspberrypi/linux/pull/3937
[11:25] <mup> PR raspberrypi/linux#3937: Add support for 'tryboot' OS upgrade fallback mechanism on BCM2711 <Created by timg236> <Merged by pelwell> <https://github.com/raspberrypi/linux/pull/3937>
[11:25] <mborzecki> pedronis: np, i see that jamesh linked to a test that does something close what i suggested
[11:26] <pedronis> yes, also my follow adds more coverage as well
[11:26] <pedronis> from various angles
[11:26] <pedronis> if you look at it
[11:26] <pedronis> *follow-up
[11:27] <mborzecki> pedronis: yeah, the tests suites add expected access level now, which is nice
[11:27] <zyga> waveform nice, thank you
[11:27] <waveform> no prob :)
[11:27] <zyga> waveform so that's nice, is there a plan to move snapd to this mechanism?
[11:28] <jamesh> mborzecki: yeah, thanks for the review!
[11:29] <mborzecki> jamesh: yw
[11:30] <waveform> I'm not sure -- I did pitch using that as the fallback mechanism back when it got added, but last I heard uboot was still required for some of the boot sequence so I'm not sure what the current status is
[11:35] <zyga> waveform I think uboot is only required to implement this feature in the first lpace
[11:35] <zyga> *place
[11:48] <ogra> yeah, it is only the scripts to try and fall back the boot that we use u-boot for
[11:50] <ogra> though as i understand, that feature is only supported on pi4 dues to using the EEPROM ... so we'd need a special pi4 image again
[11:51] <mborzecki> ogra: image, gadget and an eeprom update too, and then make snapd aware of this snowflake of a bootloader
[11:52] <ogra> yeah
[12:50] <mup> PR snapd#10162 opened: tests: new test static checker <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10162>
[13:15] <mup> PR snapd#10157 closed: o/snapstate: remove unused DeviceCtx argument of ensureInstallPreconditions <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/10157>
[13:39] <mborzecki> grrr - Ensure prerequisites for "swtpm-mvo" are available (cannot install snap base "core18": cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh")
[13:40] <mborzecki> ofc it failed in the test i really wanted to pass :/
[14:23] <ijohnson> anybody know of a quick example of mocking a device context outside of snapstate/devicestate ?
[14:23] <ijohnson> ah it seems I forgot to unlunch myself
[14:26] <ijohnson> aha
[14:26]  * ijohnson found snapstatetest.TrivialDeviceContext
[14:41] <mborzecki> meh https://github.com/snapcore/snapd/pull/10148 nested 20.04 job seems to be stuck in queued 😕
[14:41] <mup> PR #10148: overlord/devicestate, overlord/snapstate: add task for updating kernel command lines from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10148>
[14:41] <ijohnson> pedronis: mvo I filed a PR with a spread test for the vitality issue we discussed this morning https://github.com/snapcore/snapd/pull/10163
[14:41] <mup> PR #10163: o/configstate/configcore/vitality: fix RequireMountedSnapdSnap bug <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10163>
[14:45] <ijohnson> bboozzoo: which prs should I review for your kernel command line work ?
[14:45] <mup> PR snapd#10163 opened: o/configstate/configcore/vitality: fix RequireMountedSnapdSnap bug <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10163>
[14:45] <mborzecki> ijohnson: it'd be great if you looked at the last 3 commits in https://github.com/snapcore/snapd/pull/10160
[14:45] <mup> PR #10160: tests, overlord: extend unit tests, extend spread tests to cover full command line support <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10160>
[14:46] <ijohnson> ack
[14:46] <mborzecki> ijohnson: thanks!
[14:47] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/10148 ? the failure on 18.04 is unrelated to the PR
[14:47] <mup> PR #10148: overlord/devicestate, overlord/snapstate: add task for updating kernel command lines from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10148>
[15:08] <mvo> mborzecki: sure
[15:10] <mup> PR snapd#10148 closed: overlord/devicestate, overlord/snapstate: add task for updating kernel command lines from gadget <Run nested> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10148>
[15:13] <mborzecki> mvo: thank you!
[15:16] <mborzecki> #10156 has been updated
[15:16] <mup> Bug #10156: First user must be in the "disk" group by default. <base-config (Ubuntu):Invalid by cjwatson> <https://launchpad.net/bugs/10156>
[15:16] <mup> PR #10156: boot, bootloader, bootloader/assets: support for full command line override from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10156>
[15:54]  * cachio_ lunch
[16:41] <mup> PR snapd#10156 closed: boot, bootloader, bootloader/assets: support for full command line override from gadget <Run nested> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10156>
[16:41] <mborzecki> now for the last part
[16:45] <mborzecki> pedronis: mvo: i've updated #10160 that's the last part
[16:45] <mup> Bug #10160: shares-admin should run as sudo <gnome-system-tools (Ubuntu):Invalid by seb128> <https://launchpad.net/bugs/10160>
[16:45] <mup> PR #10160: tests, overlord: extend unit tests, extend spread tests to cover full command line support <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10160>
[16:46] <mborzecki> ijohnson: please take a look at #10160 again if you can, i've pushed one more test that pedronis asked for today which basically simulates an unexpected reboot when updating command lines
[17:27] <ijohnson> bboozzoo sure will do
[18:21] <mup> PR snapcraft#3499 closed: Update Docker image instructions <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3499>
=== JanC_ is now known as JanC
[22:06] <mup> PR snapd#10164 opened: o/servicestate/servicemgr.go: add ensure loop for snap service units <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10164>