[00:53] PR snapd#9661 opened: osutil/disks: add DiskFromName to get a disk using a udev name [02:04] PR snapd#9662 opened: bootloader/many: return error from ConfigFile and new* functions [02:19] PR snapd#9663 opened: tests/main/lxd/prep-snapd-in-lxd.sh: wait for archive DNS before apt things [06:55] PR snapd#9646 closed: tests/many: enable some uc20 tests, delete old unneeded tests or TODOs [06:59] morning [07:23] good morning guy [07:23] *guys [07:23] my s key is still broken here ;D [07:26] zyga-x240: heya [07:45] PR snapd#9649 closed: seed: make a shared seed system label validation helper

[08:01] morning [08:08] pstolowski: hey [08:08] weird, our 18.04 images have systemd-resolved running, resolv.conf points to 127.0.0.1:53 (so resolved), but there's no resolvectl in $PATH [08:12] wth there's no resolvectl in 18.04? [08:15] heh in systemd 239 they did s/systemd-resolve/resolvectl/ [08:17] mvo: hey [08:17] hey mborzecki and pstolowski [08:24] mvo: squash merged https://github.com/snapcore/snapd/pull/9649 can you cherry pick? [08:24] PR #9649: seed: make a shared seed system label validation helper

[08:25] mborzecki: correct [08:27] mborzecki: is that an issue? [08:28] mvo: hm not a big one, but one of the tweaks was to allow only lowercase letters in system label so that we don't end up in a silly state when seed is on FAT [08:31] mborzecki: oh and you would like to have cherry picked this tweak elesewhere too? [08:32] mborzecki: oh, sorry, I think I misunderstood, I want to cherry pick this, yes :) [08:33] mborzecki: and done [08:35] hey mvo :) [08:35] mvo: thanks! [08:35] good morning zyga-x240 ! [08:36] mvo: idk if i mentioned this, but it looks like the fonts issue may have been fixed in snapcraft https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/79 i found a PR https://github.com/snapcore/snapcraft/pull/3299 but it's 4.4+ [08:36] PR snapcraft#3299: extensions: configure hook for fonts [08:40] mborzecki: oh, that is amazing [08:40] mborzecki: I had hoped this would happen, really cool that it actually did [08:41] mvo: mhm, one nitpick, one needs to rebuild the snap using snapcraft 4.4 [08:53] mborzecki: meh, right [08:54] did you guys also see "fsck-on-boot" failing on ubuntu-core-20 ? [08:54] it seems like a new thing [08:54] mvo: did you build the image today? [08:55] mvo: and is the system encrypted? [08:56] PR snapd#9651 closed: tests: fix basic20 test on arm devices

[09:03] mvo: Ian mentioned it in the SU notes [09:04] pedronis: thank you! [09:05] pedronis: in 9659 you suggest to move KenrelCommandLineSplit, what pkg do you have in mind? boot? [09:05] pedronis: or soemthing like boot/{k,}cmdline? [09:06] mvo: osutil seems also fine [09:06] pedronis: cool, I have a look [09:14] pedronis: updated 9659 [09:14] mvo: are you looking into fsck-on-boot test? [09:14] mborzecki: I was just booting a qemu to poke around [09:15] mborzecki: not sure how far I get, I let you know if I need to give up [09:16] mvo: I put it back into my queue [09:18] ta [09:41] duh, wth? `Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 16829 (unattended-upgr)` [09:41] mborzecki: where do you see that? [09:41] mborzecki: fwiw, we should probably disable u-u [09:42] mborzecki: fwiw^2 - modern apt will retry locking but iirc only when used interactively :/ [09:48] mvo: 20.04 [09:48] mvo: yeah, unattended-upgrades service is running in a 20.04 image we use [09:55] zyga-x240: I did a pass now on #9546, I can likely take care of some of my own comments when I have a moment but one is a question [09:55] PR #9546: overlord: add inert export manager [09:55] pedronis: woot, thank you [09:55] I will look at the comment shortly [09:55] thx [09:57] mvo: huh, unattended-upgrades is running in 18.04 images too [10:11] PR snapd#9653 closed: strutil/shlex,osutil/udev/netlink: minimally import go-check [10:11] PR snapd#9664 opened: spread: disable unattended-upgrades on ubuntu [10:16] Morning all [10:16] Would anyone recall if we have any task/change in snapd that is transient, in the sense it's supposed to run only during the lifetime of the current snapd execution? [10:17] I'm guessing the answer is no, since tasks precisely overcome the fact that we want the task to be accomplished no matter how many times we restart, but checking just in case [10:19] niemeyer: I don't think we have that [10:20] niemeyer: no, indeed not so far, the closest would be some of the hot plug tasks, but they are stil persistent and it's useful but we need to be a bit careful with them [10:20] Ah, interesting.. careful in what sense? [10:21] we need to make sure that we run them in order, even if they are in different changes. that is very unusual, for most other tasks the conflict logic avoid that kind of issue at all [10:21] Interesting indeed [10:22] otherwise you might end up trying to add and remove a slot at the same time [10:22] I see, thanks for the details [10:34] mborzecki: fwiw, no progress on "fsck-on-boot" not running but core20 was stuck in manual recore [10:34] mborzecki: manual review, I unblocked it and will run again once the store has published it [10:35] mborzecki: it looks legit though, there is really no fsck happening now [10:35] mborzecki: but the fsck.vfat binary is still there [10:35] mvo: maybe there is but not clearing the dirty bit? [10:40] zyga-x240: I commented on my comment, not sure what I'm saying there makes sense though [10:53] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/9556 ? [10:53] PR #9556: tests: testing new fedora 33 image [10:53] sure [11:00] mvo: mborzecki: I commeted again on #9659 [11:00] PR #9659: strutil/cmdline.go: add GetKernelCommandLineKeyValue [11:00] *commented [11:01] pedronis: looking [11:08] mborzecki: shouldn't we drop fedora-31-64 from spread.yaml per my existing comment? [11:09] Another trivial: in hookstate, this comment is bogus: [11:09] // check if we're a hook task, probably not needed but let's take extra care [11:10] It necessarily must check if it's a run-hook task, otherwise it'd be evaluating an unknown task [11:10] (the predicate runs for all tasks) [11:12] pstolowski: it's not EOL yet [11:13] hm let me double check actually [11:13] pstolowski: mhm, it'll eol in a couple of feeks [11:14] mborzecki: i misread Sergio's PR desc, it says 'Also fedora 31 is not executed anymore, it remains manual' i [11:14] mborzecki: makes sense to keep it for a while then [11:14] yup [11:16] mborzecki: but.. i confused about all the dropping for -fedora-31-* in this PR [11:16] *i'm* [11:17] mborzecki: so we got a new kernel yesterday with new initrd, I wonder if that could have broken the fsck, I see no systemd-fsck message for ubuntu-seed in journalctl [11:19] mborzecki: ohhh, I think it might be PR#8 from core-initrd ... we now bind mount /run/mnt/ubuntu-seed so *maybe* this triggers it [11:20] * mvo looks a bit deeper [11:29] pstolowski: otoh, f31 is eol on 24.11, so maybe we should just drop it now [11:31] mborzecki: +1, [11:51] PR snapd#9665 opened: tests: unmount /boot/efi in fsck-on-boot test <⚠ Critical> [11:55] mborzecki: are you updating that PR? [11:56] pstolowski: yeah, i pushed an update [12:05] niemeyer: thx, I took note of that [12:08] mvo: hm i see that the bit is set in a vm too [12:08] mvo: so the question is, are we even looking at the right bit? [12:08] mborzecki: maybe not, not sure, but my PR above fixes the issue [12:09] mborzecki: how did you test it in the vm? spread with qemu cannot run core20 currently :/ ? [12:09] mvo: i built the image myself and booted it [12:13] ok [12:16] PR snapd#9642 closed: boot: add scaffolding for "fde-setup" hook support for sealing [12:46] pedronis: Thanks! No big deal obviously.. [12:47] It just got my attention because I went looking into the predicates to see if something else might be filtering them up [12:51] mvo: #9627 has +1 from Alex; i can prepare followup for other interfaces that need access to tty [12:51] PR #9627: interfaces/raw_usb: allow read access to /proc/tty/drivers (LP: #1890365) [13:05] mbeierl, hey [13:05] mborzecki, hey [13:06] cachio: hey, what's up? [13:06] I see this error in open suse [13:06] + su -c 'SNAPPY_USE_STAGING_STORE=0 snap prepare-image --channel edge --snap test-snapd-tools /home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/developer1-pc.model /tmp/root' test [13:06] error: cannot fetch and check prerequisites for the model assertion: circular assertions are not expected: account (testrootorg) [13:06] preparing image [13:06] did you notice that? [13:06] * mbeierl thinks I need a new nick :) Sorry mborzecki for being a second "mb"! [13:06] it just fails in opensuse [13:10] cachio: no clue, but does not look like anything opensuse related [13:13] mborzecki: cachio: something broke in the build and we don't include the test key anymore ? [13:14] that would be something that provokes that [13:14] pedronis: hm maybe some option is being ignored and testkeys tags does not get set during build [13:14] systems: [-ubuntu-core-*, -fedora-*, -opensuse-*, -arch-*, -amazon-*, -centos-*] [13:14] looks like i should investigate [13:15] the test should not be executed on opensuse [13:15] morning folks [13:15] good morning [13:15] hey cachio [13:17] mborzecki, foud the problem [13:17] anybody look into the core/fsck-on-boot spread test yet ? [13:17] ah I see mvo found the issue in 9665 [13:19] ijohnson, you mean #9655 right? [13:19] PR #9655: tests: fix fsck on boot on arm devices [13:20] cachio: no core/fsck-on-boot started failing all the time yesterday [13:20] mvo fixed the issue in #9665 it seems [13:20] PR #9665: tests: unmount /boot/efi in fsck-on-boot test <⚠ Critical> [13:20] ijohnson, ahh, It was not me :) [13:20] cachio: but also please take a look at that PR, as I think you will want to handle that change in your PR [13:22] PR snapd#9665 closed: tests: unmount /boot/efi in fsck-on-boot test <⚠ Critical> [13:22] ijohnson, yes [13:22] done [13:24] thanks cachio [13:25] ijohnson, I think I need to update that for arm because /boot/efi does not exist [13:25] cachio: precisely [13:31] pedronis: Another nit for an eventual lazy afternoon: the hookstate manager is currently breaking through the overlord abstraction and being manipulated directly by the daemon. Instead, we should extend the StateManager API with something like a Halt early signal, which would replace GracefullyWaitForHooks in a general way [13:33] pedronis: I responded to #9662, hopefully it makes sense, if not we should chat today ideally because this will block further prs on supporting lk [13:33] PR #9662: bootloader/many: return error from ConfigFile and new* functions <⛔ Blocked> [13:43] ijohnson: it sounds like we need to chat, because you explained the problem, but is still unclear that the content of the PR is the right path [13:43] pedronis: ok sorry I just left another comment [13:43] pedronis: when are you free today? [13:44] I guess I could chat now before SU [13:45] ijohnson: let's chat now [13:45] k, joining now [13:51] pstolowski: sounds great, thank you [13:57] PR snapd#9627 closed: interfaces/raw_usb: allow read access to /proc/tty/drivers (LP: #1890365) [14:07] pedronis: I eod at 16:00 today, I can send some follow ups then [14:31] zyga-x240: ok, thx, I pushed a merge fixing conflicts btw [14:33] pedronis: thank you [14:37] PR snapd#9666 opened: tests: updated the systems to run prepare-image-grub test [14:41] cachio: mborzecki: ^ but we don't support explicitly building images on those other distros, that was the reason of the skipping [14:42] ijohnson: ^ [14:42] pedronis, ok, so I'll disable them and add a tag [14:42] pedronis: yeah I was wondering the same [14:42] PR snapd#9667 opened: devicestate: implement boot.HasFDESetupHook [14:42] pedronis: IMHO if it works let's just run it there anyways [14:42] if or when it breaks we can decide whether it's worth it to fix that or not I think [14:43] but that's just me [14:43] ijohnson: well, the issue is that is not an interesting test from tht pov [14:43] becaused it's only prepare-image [14:43] not ubuntu-image [14:43] I guess I'm just of the opinion if it passes on that system why not let it run there [14:43] so it passing doesn't mean much full-picture-wise [14:43] ijohnson: because tests take time [14:43] and those time adds up [14:44] and also see othe remark [14:44] as is it doesn't prove or disproves anything [14:44] sure then just disable it for those other systems [14:44] I don't feel strongly enough about it to argue otherwise [14:45] * ijohnson perhaps has just gotten too used to the fact that tests take ages and are never green anyways to not be worried about additional time for tests to execute [14:52] PR snapd#9668 opened: bootloader: use ForGadget when installing boot config (2.48) [14:52] fwiw, i'm using ubuntu-image which runs snap prepare-image on arch, so we get at least some testing on other distros here === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [15:15] ijohnson, I updated the change [15:15] included 2 other tests [15:25] * cachio lunch [15:26] cachio: approved [15:30] mvo: some comments/questions in #9667 [15:30] PR #9667: devicestate: implement boot.HasFDESetupHook [15:32] PR snapd#9669 opened: [RFC] interfaces: allow read access to /proc/tty/drivers to modem-manager and ppp [15:45] pedronis: thanks! I will look in a wee bit [15:49] pedronis I'm grabbing coffee and looking at that branch in a moment [16:01] zyga: ok, about to be in a meeting [16:01] ok === Ringtailed_Fox is now known as RingtailedFox [17:10] pedronis: is it a strong property that we want to error if snapd_recovery_mode is specified multiple times on the kernel command line we error in the initramfs ? that is the way it currently works with the code originally written by mborzecki in boot/cmdline.go, but if we don't have such strong checking we can simplify the code somewhat with the (imho) reasonable assumption that later values override earlier ones [17:11] (and same for snapd_recovery_label) [17:35] ijohnson: you need to double check but I think that's the kernel behavior as well https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html ? [17:36] pedronis: which behavior is the same as the kernel ? [17:36] ijohnson: last wins [17:36] pedronis: ah ok good [17:36] otoh when we measure it, it won't matter much anyway [17:36] or matter a lot in the sense that it won't both ;) [17:37] I mean it's kinda a nice property that if you define it multiple times uc20 freaks out at you for board enablement folks [17:37] but it's also cumbersome to code [17:37] right yes in the measurement case it doesn't really matter [17:40] ijohnson: though in my proposal it might be not too hard to code for either behavior, it would need to be a flag though [17:40] pedronis: well it seems the kernel is a little different, for known parameters it will invoke callbacks for each parameter, so in the case of duplicated parameters it will call the callback twice, first with the first value and then again with the second value [17:40] but for things like snapd_recovery_mode that the kernel doesn't care about, then it essentially doesn't matter [17:41] pedronis: yeah I thought maybe to handle it we could return a `map[string][]string` but it makes some other usages more complicated [17:41] I think for our purposes since we are not the kernel, it's ok to just let the last one win [18:08] PR snapd#9668 closed: bootloader: use ForGadget when installing boot config (2.48) === ijohnson is now known as ijohnson|lunch [19:54] ijohnson|lunch, is it ok #9650 ? [19:54] PR #9650: tests: skip boot state test on arm devices

[19:55] it is ready for merge [20:04] PR snapd#9666 closed: tests: updated the systems to run prepare-image-grub test

[20:04] cachio approved thanks [20:04] ijohnson|lunch, yaw [20:09] PR snapd#9650 closed: tests: skip boot state test on arm devices

[20:09] ijohnson|lunch: do you need input on anything right now? === ijohnson|lunch is now known as ijohnson [20:13] pedronis: no, not really but just to be clear it's okay to not fatally error if there is a duplicated kernel command line parameter for snapd_recovery_{mode,system} ? [20:14] ijohnson: it's ok (we can always change it again), I think the most affected case would be playing with it and then turning on encryption later, but we don't really support playing with the command line that much for relevant systems atm [20:14] right [20:15] ok, sounds good that's what I implemented and was about to push up changes for === diddledan_ is now known as diddledan [22:34] PR snapcraft#3380 opened: snap packaging: fix broken path check when copying local icon [22:39] PR snapd#9655 closed: tests: fix fsck on boot on arm devices