/srv/irclogs.ubuntu.com/2020/08/11/#snappy.txt

mupPR snapcraft#3243 opened: Add skip-keys to catkin plugin <Created by Levi-Armstrong> <https://github.com/snapcore/snapcraft/pull/3243>04:37
mborzeckimorning06:08
mvomborzecki: good morning - should I merge 9128 or is it not meant to be on master?06:39
mborzeckimvo: hey, hm it's probably ok to merge it, it's only adding some debug output to the test06:41
mupPR snapd#9126 closed: boot: introduce current_boot_assets and current_recovery_boot_assets to modeenv <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9126>06:45
mupPR snapd#9128 closed: tests/main/cgroup-tracking: try to collect some information about cgroups <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9128>06:45
zygagood morning07:04
pstolowskimorning07:06
mborzeckizyga: pstolowski: hey07:16
mborzeckizyga: left some comments under https://github.com/snapcore/snapd/pull/912807:16
mupPR #9128: tests/main/cgroup-tracking: try to collect some information about cgroups <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9128>07:16
mborzeckizyga: some weird thing happening on 16.04 and  cgroups07:17
mvogood morning zyga07:32
mvohm, so07:39
mvo2020-08-11T07:31:29.8774856Z     - google:ubuntu-20.04-64:tests/main/cgroup-tracking-failure07:39
mvo2020-08-11T07:31:29.8775399Z     - google:ubuntu-20.04-64:tests/main/snap-user-service07:39
mvothat is known, right?07:39
pedronismvo: I fear you'll need zyga to undersand the state of that, there's a PR open but I don't know if it's the final story on this07:48
mvopedronis: that's fine, just wanted to double check07:49
mvopedronis: also it was a bit of a general question, not directly targeted to you :)07:49
mvopedronis: did you had a chance to think about the name for the kernel-crypto-api interface? or is the name good already?07:50
pedronisI didn't interpret it as targeted to me, but nobody was saying anything :)07:50
pedronismvo: no, I haven't seriously thought about that PR since Friday07:51
mvopedronis: heh :) thanks!07:51
mborzeckipedronis: hey, s/TrustedAssetsChain/TrustedAssets/?07:51
mborzeckipedronis: tbh i assumed that we'll glue that higher up the call stack, somewhere in boot when (re)sealing07:53
pedronismborzecki: yes, as I said, I think the content matches the doc comment, but the name confused Ian07:53
mborzeckiok07:54
pedronisor so I think07:54
pedronisthe glueing is a bit messy because it is across recovery and run bootloaders07:54
pedronisbut we will deal07:55
mborzeckiyeah, otoh i'm not sure one bootloader (eg. run) should know that it's being loaded by the recovery one07:55
mupPR snapd#9111 closed: releases: release 2.46~pre1 to groovy <Simple 😃> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9111>07:55
pedronismborzecki: I don't think that's the main problem07:55
pedronismostly for the final glueing we reall need the maps from modeenv07:56
mupPR snapd#9131 opened: debian: release 2.46~pre2 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9131>08:30
zygare08:47
zygasorry, I had a small unexpected errand08:47
zygaback now08:47
zygamborzecki: 0 is always the ID of unified cgroup08:47
zygamborzecki: cachio suggested that lxd test is responsible08:47
zygamaybe lxd mounts the unified hierarchy somehow08:47
mborzeckizyga: ha, as it mounts the hierarchy and it's left behind?08:47
zygamborzecki: I will try that in a moment08:47
zygaperhaps08:47
zygathat would explain it08:47
mborzeckizyga: and sys from the host is bind mounted to the container?08:47
zygaand fortunately we have a cleanup script for it08:48
zygaI don't fully know, there are some approaches, more than one08:48
mborzeckiduh, how about systemd container protocol then? :)08:48
zygathere's a special fake cgfs as well08:48
zygamborzecki: I think that's beyond my confidence zone08:48
zygabut we have a clue08:48
zygaI spent a bit too long last night trying to fix core 1608:48
mborzeckiif it is lxd, then stgraber will probably know more08:48
zygamade progress but I EOD past midnight and I was a bit tired in the morning]08:49
zygamborzecki: yeah but it's quick and easy to verify this with -shell-after08:49
zygaI'll try that now08:49
zygahey mvo, sorry for starting late08:49
zygamborzecki: actually, first priority is to fix master08:50
zygaso give me a moment to wrap up that issue first08:50
mborzeckierrand, back in 30 or so08:50
zygaok08:53
mvozyga: no worries08:56
mborzeckire09:12
* zyga tries to sit in the office today09:16
zygayesterday that didn't go very well09:16
mvomborzecki: any highlevel concerns/feedback about #9130? especially aobut the plan to make the mountedfilesystemwriter use the ResolvedSource (i.e. an absolute path) and stop passing in the gadget root there?09:17
mupPR #9130: [RFC] Support for gadget.yaml "$kernel:" style references <Created by mvo5> <https://github.com/snapcore/snapd/pull/9130>09:17
mborzeckimvo: haven't looked yet, i'll do it today09:17
mvomborzecki: it will cause some churn so I want to somewhat be certain it's not in vain :)09:17
mvomborzecki: ok, no worries09:17
mupPR snapd#9132 opened: o/hookstate/ctlcmd: add optional --pid argument to "snapctl is-connected" <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9132>09:25
mupPR snapd#9133 opened: osutil: add CommitAs to atomic file <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>09:30
mborzeckihopefully a trivla PR ^^09:32
zygamborzecki: https://github.com/snapcore/snapd/pull/9133#pullrequestreview-46490232309:33
mupPR #9133: osutil: add CommitAs to atomic file <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>09:33
zygayes, but with a typo :)09:33
mborzeckihaha09:33
mborzeckiok, let me force push, not worth another patch09:33
zygayeah09:33
zygaand cancel current run09:33
zygasave $$$09:33
* zyga tries another iteration of core16 fix09:34
mborzeckibtw. gh actions still does not support canceling a workflow when a branch is pushed to?09:35
mborzeckicanceling a running workflow i mean09:35
zygaI don't know09:35
zygawhat else is broken in master09:37
zygawe have systemd-logind failing often09:37
zygabut there was one more thing IIRC09:37
mborzeckizyga: cgroups on xenial09:38
zygaah right09:38
zygathanks09:38
mborzeckizyga: and unit tests using gpg fail occasionally09:38
zygathanks :)09:38
zygayeah09:38
zygaabout that09:38
zygait fails in azure09:39
mborzeckisnap sign tests iirc09:39
zyganot in our gce tests09:39
zygaazure VM has all kinds of modifications that are well documented09:39
mborzeckibut gpg?09:39
mupPR snapd#9095 closed: boot/bootstate20: unify commit method impls, rm bootState20MarkSuccessful <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9095>09:40
mupPR snapd#9116 closed: tests: add system information and image information when debug info is displayed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9116>09:40
zygamborzecki: they update lots of things to more recent versions09:42
zygaI mean, really anything that people use09:43
zygaand pre-install a load of things09:43
zygamaybe some interaction there leaks09:43
mupPR snapd#9001 closed: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9001>09:45
mupPR snapd#9079 closed: gadget/install: retrieve command lines from bootloader <Simple 😃> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9079>09:45
pedronismborzecki: should we just merge #9127 ? we can change again when it's used, if we discover we really need it to be different09:48
mupPR #9127: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9127>09:48
mborzeckipedronis: i think we should land it and tweak later on09:48
mborzeckipedronis: this will probably be clearer when i start opening more bits09:48
pstolowskizyga: what's the status of https://bugs.launchpad.net/snapd/+bug/1867193 ? the test PR referenced there was merged long time ago, not a bug once "robust-mount-namespace-updates" are enabled?09:51
mupBug #1867193: failure refreshing snap with content interface <snapd:In Progress by zyga> <https://launchpad.net/bugs/1867193>09:51
pedronismborzecki: I'm adding this comment to the merge:  Notice that this in practice splits across the divide of recovery vs run mode bootloaders, the complete chains for sealing will need to bridge that. We might use a different helper to produce that.09:51
zygaI'd mark it as fix released09:51
zygathe last comment may be a different bug09:51
mborzeckipedronis: sounds good09:52
mupPR snapd#9124 closed: gadget: introduce content update observer <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9124>09:55
mupPR snapd#9127 closed: bootloader: introduce TrustedAssetsBootloader, implement for grub <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9127>09:55
mborzeckiyay09:56
* mvo hugs mborzecki 09:56
mvosil2100: snapd is in beta now so we can re-enable beta image builds to pending. let me know if you prefer a mail10:09
zygacore16 tests are running10:10
zygamaybe no more typos10:10
zygafingers crossed10:10
mvozyga: what pr is that?10:12
zygamvo: still local10:12
zygathere's a PR but it's only missing core1610:12
mvook10:12
zygaPR number is10:12
zyga912510:12
zygaif it passes then master will be better10:12
zygawell, locally, then I push and open the draft for review10:12
=== facundo__ is now known as facubatista
pstolowskipedronis: #9084 is ready for review (prereq PR landed)10:16
mupPR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>10:16
zygatests are running, I need to stop sitting now10:17
zygaman standing desk is a godsend10:18
zygaI wish I knew that years ago10:18
sil2100mvo: thanks! On it!10:22
mupPR snapd#9134 opened: boot, o/devicestate: TrustedAssetUpdateObserver stubs, hook up to gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9134>10:26
zygaone more tweak and I think it will be good10:37
pstolowskipedronis: also, do you have a moment today to talk about disk space check & multi snap install/refresh?10:53
mborzeckimvo: can you merge https://github.com/snapcore/snapd/pull/9133 ? the test failure are unrelated11:12
mupPR #9133: osutil: add CommitAs to atomic file <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9133>11:12
mvomborzecki: sure, done - could you please check 9131 ?11:28
mborzecki2020-08-11T08:38:45.2793033Z 2020-08-11 08:38:45 Cannot allocate google:ubuntu-core-20-64: google: read JWT from JSON credentials: 'type' field is "authorized_user" (expected "service_account")11:29
mborzeckiwow11:29
zygahmm?11:31
zygaJWT?11:31
mupPR snapd#9133 closed: osutil: add CommitAs to atomic file <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9133>11:31
zygajavascript web token11:31
zyga(just making stuff up)11:31
mborzeckizyga: close ;)11:31
zygaso hot11:31
zygaI was outside for a sec11:31
zygato move walk around the block11:31
mborzeckimvo: have you added skip spread tag after opening 9131?11:32
mvomborzecki: yes, just now11:34
mvomborzecki: actually silly that I require spread for this11:34
mborzeckimvo: i've closed and reopened it, the tag should be picked up now11:35
mvomborzecki: aha, nice11:35
sil2100mvo: dailies for beta should now be enabled! You want a new build kicked now?11:41
mvosil2100: yes please11:41
pedronispstolowski: we can chat after the standup if that works for you?11:51
pedronispstolowski: thanks for merging master into #908411:52
mupPR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>11:52
mupPR snapd#9131 closed: debian: release 2.46~pre2 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9131>11:56
zygaI think it works now12:02
zygasingle test passes12:02
zygalet me push12:02
* mvo crosses finger for zygas pr12:04
zygayeah, I want this to be over12:05
zygaI'll take a quick shower and I'll start working on the other bug12:05
zyga(cgroups)12:05
pstolowskipedronis: yes, after standup is fine12:16
zygalooking into the cgroup + lxd thing12:17
zygacore16 is almost done testing, no failures12:24
pedronismborzecki: some questions/comments in #9134 ?12:25
mupPR #9134: boot, o/devicestate: TrustedAssetUpdateObserver stubs, hook up to gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9134>12:25
mborzeckipedronis: thanks for the reviews (and mvo too)12:26
zygacore16 is green12:28
zygalet's see if everything else passes now12:28
zygaI'm focusing on the lxd thing now12:28
zygafirst I need to see it12:28
zygathe fix should not be complicated12:28
zygamborzecki: yeah, that's really happening12:32
zygaI wonder how12:32
mborzeckizyga: lxd mounting a unified hierachy?12:32
zygayep12:33
mborzeckizyga: or maybe systemd in lxd doing that12:33
zygaclear as day12:33
zygaI will run again and see which part of the test causes that12:33
zygaI will push a quick fix so that we're okay12:33
mupPR snapd#9019 closed: tests/nested/manual/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9019>12:36
zygaoh man12:36
zygamborzecki: I understand now12:36
zygamborzecki: that cgroupv2 is not mounted inside12:37
pstolowskipedronis, mvo thanks for feedback on disk space awareness12:37
zygait was mounted in the container12:37
zygabut those are global12:37
zygaall processes see all cgroups12:37
zyganow where the hell is it mounted?12:38
zygaand I think this is more than tests12:38
zygawe need to adjust snapd code as well12:38
zygamborzecki: I'm still unclear where this thing is mounted12:39
zygait's not inside the container12:39
zygait's not mounted in the inner container either12:40
zygabut the inner container is bionic12:41
zygamaybe it's just systemd?12:41
zygahmmm12:48
zygaok I'll bisect12:48
zyga-mbpI'll go for lunch now, ttyl13:50
* cachio lunch14:54
zyga-mbpre15:14
mupPR snapd#9087 closed: o/snapstate: check available disk space before downloading a snap on install (4/N) <Disk space awareness> <Needs Samuele review> <â›” Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9087>15:22
mupPR snapd#9135 opened: boot: move bootloaderKernelState20 impls to separate file <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9135>15:42
mupPR snapd#9064 closed: .github/workflows: move snap building to test.yaml as separate cached job <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9064>15:47
* zyga explores a fix for the cgroup2 thing16:01
zygait's a kernel bu16:01
zyga*big16:01
zyga*bug16:01
zygaor feature16:01
zygadepending on how you look16:01
zygawe can only work around it16:01
jdstrandkenvandine: that's weird. on focal I seem to have gnome-software installed as a deb (fine). I have the review-tools latest/stable installed so I wanted to show someone the permissions dialog, but gnome-software showed that the review-tools were not installed. I pressed the Install button and they install latest/edge16:13
ijohnsonzyga: the unified cgroup mount after lxd container started ?16:17
zygait's not just thta16:17
zygajust mount cgroupv216:17
zygaand unmount it16:17
zygadone16:17
zygano containers required16:17
jdstrandkenvandine: I wonder if it is because I haven't done 'snap login'? (ie, polkit promted me)16:18
ijohnsonzyga: ah interesting, maybe we just mount cgroupv2 all the time unconditionally in project prepare and deal with the consequences ?16:29
zygaijohnson: nah, that's unnatural16:29
zygaI've adjusted both snapd and the test that's sensitive to it16:30
zygajust making final touches16:30
mupPR snapd#9136 opened: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>16:32
ijohnsonzyga: The dark side of cgroups is a pathway to many abilities some consider ... unnatural16:32
zygahaha, is that a star wars quote?16:32
ijohnsonyes haha16:33
* ijohnson goes away now and does real things16:33
* ijohnson well tries too anyways16:33
zygaijohnson: I pushed more fixes to https://github.com/snapcore/snapd/pull/912516:38
mupPR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <âš  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>16:38
ijohnsonzyga: nice let me take a look, would be nice to land that16:38
zygaI will observe if it passes and we can then either review the ensemble or review in split branches16:38
zygait's still a draft but please have a look for early impression16:39
ijohnsonzyga: yeah I was just gonna say looking at this and the title it's not obvious how much you had to change, but yes +1 to splitting off the actual Go code changes16:39
ijohnsonI'll still submit a review for you though16:39
zygaok16:39
zygathe go code changes are optional16:39
zygawe were lucky16:39
zygathis is just for completeness16:39
ijohnsonah ok, I thought the Go code was necessary to fix the test16:40
zygaI thought so too but again, we were lucky :)16:40
ijohnson:-)16:40
zygalook at https://github.com/snapcore/snapd/pull/9125/commits/4b3bf6cbb08302b1878a9452e8ddcf9190ab861716:40
mupPR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <âš  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>16:40
ijohnsonzyga: so does this present only on 4.15 kernel or is it 4.15+ ?16:40
zygait's any version really16:44
zygajust that xenial's systemd does not mount v2 at all16:44
zygaso we noticed16:44
ijohnsonah right that makes sense16:48
ijohnsonI just left a review16:48
zygathanks!16:51
zygareplied16:53
zygaand looking at kernel docs first16:53
pedronisijohnson: I'm not entirely sure whether #9136 is or isn't on the path I described in the previous, to be clear I'm not sure the path is an improvement, we would have to try, it has the propery of making boostate20, closer to bootstate1617:42
mupPR #9136: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>17:42
ijohnsonpedronis: mmm sorry I didn't see that you want the modeenv in the structs to go away entirely, I thought you just wanted the modeenv struct to go away17:46
pedronisijohnson: yes, my plan was to have it go away completely, that's why I was suprised that not touching initramfs bits was not a problem17:46
zygaijohnson: it seems to be a kernel bug17:47
zygaI'll report it and add the reference to the code17:47
zygaijohnson: I guess no bug report17:55
zygaijohnson: quote from #lxcontainers17:56
zyga> <zyga> do you have a reference? I will link to that next to our workaround17:56
zyga<stgraber> nope, that kind of upstream discussion is all private IRC and telegram ;)17:56
zygaI don't mind, I guess that's enough for now17:56
zygatests on https://github.com/snapcore/snapd/pull/9125 are in progress17:56
mupPR #9125: tests: fix issues related to restarting systemd-logind.service <Test Robustness> <âš  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9125>17:56
zygaI'll review the services PR and EOD17:56
stgraberdebating whether it's an issue or not, it's unlikely to be security relevant (as no controllers are auto-loaded on cgroup2) but still  trying to argue that it could confuse badly written software on the host17:57
zygastgraber: yeah, I think it's more surprising than dangerous17:58
* zyga is tired17:59
zygamaybe that review needs to wait17:59
zygait's 8PM17:59
* zyga EODs, more reviews tomorrow18:01
zygahave a good rest of your day friends!18:01
ijohnsonpedronis: ok, then in this case let's just abandon this PR and do it post uc20 1.0, I really don't know how we could get rid of modeenv entirely without changing a bunch of function/interface signatures and you're about to go on holiday, so not much point to trying to hash it out now I think18:03
ijohnsonzyga: nice find thanks for looking into it more18:03
stgraberzyga: consensus seems to be that it's been that way since 2016, nobody is supposed to assume that because something is listed in /proc/self/cgroup that it's mounted, you need to look at mount table too (as controllers never go away)18:04
zygaack18:04
zygaI always found that surprising btw,18:04
zygathat there are those nice CG identifier numbers18:05
zygathat are dangling and unrelated to the filesystem18:05
zygaand that you need to match on the controllers and mountinfo18:05
zygait's probably uninteresting as future has cgroup2 only18:05
zygabut v1 was somewhat messy from this point of view18:05
pedronisijohnson: yes, I expected we'll need to change some signatures18:07
ijohnsonyeah I guess I totally missed that point sorry18:07
ijohnsonI don't think it's worth it right now to try and simplify that at all, seems quite complex18:07
ijohnsonIMHO this PR is still a win because it's less structs and less abstractions, but I suppose it is more type casting and slightly duplicative code, so I could see it not as a win too18:08
ijohnsonif you don't think it's worth it I will just close it and we can revisit the refactor $SOME_DAY+2 now18:08
pedronisijohnson: in light of the fact that we want to do something larger it doesn't feel like a win because of your point two about the extra duplication18:09
cachiozyga, hey18:15
cachiodid you fix the test tests/core/uc20-recovery at some point right?18:16
pedronisijohnson: can you explain me this change though: https://github.com/snapcore/snapd/pull/9136/files#diff-bff1ced30ed4581302ca81b7b53908f9L727  is that needed for that case?18:16
cachioijohnson, or you did it?18:16
mupPR #9136: bootstate20: rm bootState20Modeenv, pass around modeenv directly <Cleanup :broom:> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9136>18:16
pedronisijohnson: isn't that needed18:16
pedronisijohnson: ah, it's done lazily by revisions in the new code?18:17
* cachio afk18:21
ijohnsonsorry was at lunch18:24
ijohnsonpedronis: it actually was never needed18:24
ijohnsonpedronis: we already setup the modeenv when we create the bootState20Base in initramfs.go18:25
ijohnsoncachio: I think I looked at it and I thought we fixed something there18:25
pedronisijohnson: ah18:25
ijohnsoncachio: is it failing again now ?18:25
pedronisI forgot about that18:25
ijohnsonyeah that's kinda why I disliked how InitramfsRunModeSelectSnapsToMount is working where it just creates the objects and calls a method on them and kinda forgoes all the rest of the stuff in that file18:26
ijohnsonbut meh18:26
stgraberzyga: I'm adding a tweak to our apparmor policy to prevent mounting cgroup2 if host doesn't have it, so we'll avoid that kind of issue for now18:28
pedronisijohnson: now I'm very tempted to try to see if what I have in mind is smaller or not overall (it might not be, which again would make it a bit meh)18:29
ijohnsonpedronis: I mean hey go for it if you want, feels a bit superfluous right now but it is fun to try and write simple elegant code sometimes :-D18:30
pedronisijohnson: are you blocked on something from me?18:34
ijohnsonpedronis: if you wanted to review the last commit on my cross check PR that is a draft that would be nice, but that is blocked on systemd-mount PR, which is then blocked on x n o x18:35
ijohnsonpedronis: that would be https://github.com/snapcore/snapd/pull/9081/commits/147e3058ed55ff88e2c3aae0b598b346b6af557618:35
mupPR #9081:  secboot,cmd/snap-bootstrap: cross-check partitions before unlocking, mounting <UC20> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9081>18:35
pedronisijohnson: that last commit says it's +1711 ?18:36
ijohnsonpedronis: no github is silly, that diff line is for the whole PR I'm pretty sure18:36
ijohnsonwhich contains all the systemd-mount PR18:36
ijohnsonpedronis: git says ` 7 files changed, 424 insertions(+), 96 deletions(-)`18:37
pedronisyea, that seems more reasonable18:37
mupPR snapd#9135 closed: boot: move bootloaderKernelState20 impls to separate file <Simple 😃> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9135>18:38
ijohnsonthanks18:38
pedronisijohnson: I did a quick pass there, some comments/questions18:44
ijohnsonthanks18:45
pedronisijohnson: so I tried, it gains 30 lines, not sure it's clearer or not, the cost is a new interface. There's probably a bit more that can be tried in initramfs.go19:30
ijohnsonpedronis: mmm interesting, but yes there's a lot more that can be done in initramfs.go19:32
ijohnsonI need to go to the bank19:32
* ijohnson afk for hour or two19:32
mupPR snapd#9137 opened: boot: refactor such that bootStateUpdate20 mainly carries Modeenv <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9137>19:43
cmatsuokaijohnson: do you see a reason for uc20 installation to be failing on sd (on the nuc, not pi)?20:25
ijohnsoncmatsuoka: by "sd" do you mean like /dev/sda or like an actual SD card20:27
cmatsuokaijohnson: I always installed to internal storage on real pc hardware, it never occured to me to boot the image and install on external media20:27
cmatsuokaijohnson: sd card20:27
cmatsuokaijohnson: like a giant raspberry pi20:27
ijohnsonHypothetically it should work20:27
ijohnsonDid you find an issue with that setup?20:27
cmatsuokayes, I think it should too, but that's the scenario that doesn't work for galem20:28
mupPR snapd#9138 opened: many: refactor tpm seal parameter setting <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9138>21:28
mupPR snapcraft#3244 opened: file utils: introduce get_host_tool_path() to find commands on host <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3244>21:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!