| mup | PR snapd#9300 opened: boot: build bootchains data for sealing <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300> | 01:22 |
|---|---|---|
| mup | PR snapd#9301 opened: tests/lib/cla_check.py: don't allow users.noreply.github.com commits to pass CLA <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9301> | 02:22 |
| mup | PR snapd#9273 closed: boot: mark successful with boot assets <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9273> | 04:57 |
| mborzecki | morning | 05:09 |
| mup | PR snapd#9298 closed: boot: represent boot chains, helpers for marshalling and equivalence checks <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9298> | 05:13 |
| mborzecki | yay | 05:13 |
| mvo | good morning mborzecki | 05:15 |
| mborzecki | mvo: hey | 05:24 |
| mborzecki | need to drive me daughter to school, back in a bit | 05:25 |
| mvo | sure thing | 05:27 |
| mborzecki | re | 06:26 |
| pstolowski | morning | 06:51 |
| mup | PR snapd#9301 closed: tests/lib/cla_check.py: don't allow users.noreply.github.com commits to pass CLA <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9301> | 07:03 |
| pedronis | mvo: mborzecki: hi, should we have a chat in a bit? | 07:09 |
| mborzecki | spread job on 20.10 is required now? | 07:10 |
| pedronis | mborzecki: I think mvo did that change | 07:11 |
| mborzecki | pedronis: sure, when do you want to have the chat? | 07:11 |
| pedronis | in 10 minutes? | 07:11 |
| mborzecki | works for me, mvo? | 07:13 |
| mborzecki | merged master into https://github.com/snapcore/snapd/pull/9300 easier to see the actual changes | 07:15 |
| mup | PR #9300: boot: build bootchains data for sealing <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300> | 07:15 |
| pedronis | mborzecki: I'm joining the standup | 07:22 |
| mvo | pedronis: hey, only now saw this message | 07:24 |
| mvo | pedronis: joining | 07:24 |
| zyga-kaveri | good morning | 07:43 |
| zyga-kaveri | I'll get ready for the call with JJ | 07:43 |
| zyga-kaveri | last night I got stuck on task ordering weirdness | 07:43 |
| zyga-kaveri | I need to look at the code with fresh eyes | 07:44 |
| zyga-kaveri | how are core20 bits? | 07:44 |
| mvo | zyga-kaveri: good morning | 07:54 |
| mvo | zyga-kaveri: things are progressing | 07:54 |
| zyga-kaveri | from the outside it looks like a lot of concentrated effort | 07:55 |
| zyga-kaveri | happy to chat later today if you have time | 07:55 |
| mvo | mborzecki: I think you asked about ubuntu-20.10 as required earlier - it is now but if that is a problem I can disable that again | 08:08 |
| pstolowski | mvo: thanks for the comments under remove-many, was really simple change | 08:08 |
| mborzecki | mvo: it failed in https://github.com/snapcore/snapd/pull/9297 but I see it's green now after i pushed a merge from master there | 08:09 |
| mup | PR #9297: boot: add "rootdir" to baseBootenvSuite and use in tests <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9297> | 08:09 |
| mvo | mborzecki: ta | 08:10 |
| zyga-kaveri | back from call | 08:13 |
| zyga-kaveri | this thing is making progress :) | 08:13 |
| mup | PR snapd#9237 closed: devicestate: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9237> | 08:13 |
| mup | PR snapd#9297 closed: boot: add "rootdir" to baseBootenvSuite and use in tests <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9297> | 08:13 |
| zyga-kaveri | okay, onto exports | 08:14 |
| mup | PR snapd#9302 opened: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9302> | 08:23 |
| pedronis | mborzecki: mvo: proposed, https://github.com/snapcore/snapd/pull/9303 | 09:48 |
| mup | PR #9303: boot,secboot: switch to expose and use snapcore/secboot load event trees <Created by pedronis> <https://github.com/snapcore/snapd/pull/9303> | 09:48 |
| mup | PR snapd#9303 opened: boot,secboot: switch to expose and use snapcore/secboot load event trees <Created by pedronis> <https://github.com/snapcore/snapd/pull/9303> | 09:49 |
| mvo | pstolowski: one small remark for 9294, thanks for this, looking really good | 09:51 |
| * mvo has some barely controlled rage against nested tests currently | 09:51 | |
| pstolowski | mvo: watch out, nested is dangerous for mental health | 09:52 |
| mborzecki | pedronis: thanks, i've opened the tweaks too: https://github.com/snapcore/snapd/pull/9304 (cc mvo) | 09:54 |
| mup | PR #9304: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304> | 09:54 |
| mvo | pstolowski: yeah, I was wondering if I should play hockey tonight or not but I think I will just to get rid of this agression that is building up | 09:54 |
| mvo | pstolowski: to be fair, a lot of it is shell | 09:55 |
| pstolowski | yeah, one simple typo grants you 40 minutes of waiting for another run ;) | 09:57 |
| pstolowski | and fun with quoting | 09:58 |
| pedronis | mborzecki: thanks, I'll review it after lunch | 09:58 |
| mvo | pstolowski: yeah, that's part of it. anyway, *rage* | 09:58 |
| mvo | pstolowski: debugging it is also impossible, ps afx shows "sleep 1" | 09:59 |
| mup | PR snapd#9304 opened: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304> | 09:59 |
| mvo | pstolowski: like why/where etc? *furryandrage* | 09:59 |
| mvo | pstolowski: anyway, sorry, I will see that at least debugging can be improved a little bit | 09:59 |
| zyga-kaveri | mvo: oh, what's up with nested? | 10:00 |
| pstolowski | mhm | 10:00 |
| mvo | zyga-kaveri: some tests in there are broken | 10:00 |
| mvo | zyga-kaveri: and it's unclear why and they are kind-of-important for our work :) | 10:00 |
| zyga-kaveri | :( | 10:00 |
| zyga-kaveri | I'm sorry this is frustrating | 10:00 |
| zyga-kaveri | can I help? | 10:00 |
| mvo | zyga-kaveri: maybe in some minutes, I plan to push some small tweaks | 10:01 |
| mvo | zyga-kaveri: review/ideas about those will be great | 10:01 |
| pstolowski | mvo: updated #9294 | 10:01 |
| mup | PR #9294: o/snapstate: check available disk space in RemoveMany <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9294> | 10:01 |
| mvo | pstolowski: \o/ | 10:01 |
| pstolowski | we will probably need to think about --purge flag support with remove-many; with the above check the client will hint at --purge which cannot be applied to multiple snaps at once | 10:03 |
| pstolowski | not super problematic but slightly confusing | 10:04 |
| * mvo will note that qemu is a piece of magic | 10:36 | |
| zyga-kaveri | mvo: large piece | 10:37 |
| zyga-kaveri | mvo: would the snapshot / restore feature help with nested tests perhaps? | 10:37 |
| * zyga-kaveri doesn't understand TestEnableRunThrough | 10:37 | |
| mvo | zyga-kaveri: maybe but it's really more fundamental at this point | 10:37 |
| mvo | zyga-kaveri: I mean, the nested vm is not creating a user right now for me | 10:38 |
| mvo | zyga-kaveri: and afaict I have no way to debug this | 10:38 |
| mvo | zyga-kaveri: so I need to collect some wood first to build a crafting table it seems | 10:38 |
| zyga-kaveri | can you mount the image and look at logs? | 10:38 |
| zyga-kaveri | you can use the virt tools package for that | 10:39 |
| zyga-kaveri | unless crypted | 10:39 |
| mvo | zyga-kaveri: this is what I'm currently doing http://paste.ubuntu.com/p/ZkGtr2pMpb/ | 10:40 |
| mvo | zyga-kaveri: I could but I really want to have a better way, see the new -sertial option there | 10:40 |
| mvo | zyga-kaveri: it started with qemu-nested not working for me and then I gradually crawled my way out | 10:41 |
| zyga-kaveri | I can see where the frustration is coming from :) | 10:41 |
| zyga-kaveri | mvo: should sleep_reason echo the reason? | 10:42 |
| mvo | zyga-kaveri: it could, I mostly did it for ps afx | 10:49 |
| zyga-kaveri | maybe I miunderstand but now the || part will always fail | 10:50 |
| zyga-kaveri | as you run it in a subshell and give it function names | 10:50 |
| * pstolowski lunch | 10:55 | |
| mvo | zyga-kaveri: it's just there so that a "ps afx" in the qemu shows why we wait. the first sleep xx will never fail so the right side of the || never runs | 10:59 |
| pedronis | mborzecki: I'm not sure I understand your question in 9303, if next was always one element there would be no point in doing this | 11:01 |
| pedronis | mborzecki: I answered in the PR | 11:07 |
| mvo | nested.sh defines PARAM_SERIAL 3 times in the same way | 11:12 |
| pedronis | mvo: after prepare.sh nested.sh is our largest shell file | 11:22 |
| pedronis | and prepare.sh has probably a simpler flow than nested.sh | 11:22 |
| mvo | pedronis: yeah, did I mention I'm full of rage and furry? | 11:23 |
| mvo | pedronis: anyway, I think there will be some good outcomes at least | 11:23 |
| pedronis | is uc20-recovery known to be flaky? | 11:27 |
| pedronis | or known to fail? | 11:27 |
| pedronis | it's failing in my PR | 11:27 |
| mvo | pedronis: not know to me, let me look | 11:28 |
| mvo | pedronis: this "2020-09-09T10:40:40.0118864Z retry: command sh -c test "$(wc -l < /tmp/mock-shutdown.calls)" = "2" keeps failing after 30 attempts" is a failure ijohnson fixed recently in 9299 - it's not in master yet | 11:29 |
| mborzecki | pedronis: yeah, i was a bit confused by the tests, but it's clear now, suggested little tweaks to formatting that makes the nesting clearer | 11:38 |
| pedronis | mborzecki: thx, I reviewed your PR | 11:43 |
| mborzecki | pedronis: thanks! | 11:44 |
| mvo | ijohnson: an interessting observation - I am debugging a failed nested uc20 minimal smoke test right now and it looks like the /run/mnt/ubuntu-seed/data/etc/cloud.cfg.d/data.cfg did not get copied into the system, it's a bit hard to see why because we have no persistent journal right now. note that this is before merging your uc20 changes. anyway, I guess that is not much, I will keep digging | 11:50 |
| pedronis | mborzecki: pushed your suggestions, please double check | 11:53 |
| mborzecki | pedronis: lgtm | 11:53 |
| pedronis | mborzecki: should we chat about the next step? | 11:56 |
| ijohnson | mvo yeah that would explain why the user didn't run | 12:00 |
| mvo | ijohnson: anything I can/should debug while I'm inside the nested vm? if not I will re-run with persistent jounral enabled | 12:01 |
| ijohnson | mvo I don't remember if I proposed the branch or not but I added a bit of code to make the journal persistent in nested VMs via the gadget.yanl defaults | 12:01 |
| mvo | ijohnson: yeah, I just added the same bit :) | 12:01 |
| mvo | ijohnson: well, don't know if it's the same | 12:01 |
| mvo | ijohnson: but same goal | 12:01 |
| ijohnson | mvo in this system do you see the disabled file in /etc/cloud ? | 12:02 |
| mvo | ijohnson: yes | 12:02 |
| mvo | ijohnson: and the timestamp is some seconds before my snapd log starts | 12:02 |
| mvo | ijohnson: so I don't know what it did before :/ | 12:02 |
| ijohnson | Yeah probably just need to re-run with persistent journal | 12:03 |
| ijohnson | After breakfast I will propose that branch if I haven't already proposed it | 12:03 |
| mvo | ijohnson: ok, only if it's no hassle for you. i have similar code already locally | 12:03 |
| mvo | ijohnson: part of some bigger and slightly messier work | 12:04 |
| mvo | ijohnson: that I will cleanup :) | 12:04 |
| ijohnson | Yeah I just checked I haven't proposed it yet, will do so when available this morning | 12:05 |
| mvo | no rush, I rerun and get some lunch | 12:06 |
| mborzecki | pedronis: sry, yes, 1430 maybe? does not look like cmatsuoka is online yet | 12:08 |
| pedronis | mborzecki: ok, works for me | 12:09 |
| pedronis | mborzecki: going into the standup | 12:29 |
| mup | PR snapcraft#3281 closed: build providers: hide systemd setup for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3281> | 12:41 |
| mvo | ijohnson, cachio just FYI, I'm poking at nested right now and this is my in progress stuff http://paste.ubuntu.com/p/6CTYJn3ZYs/ | 14:00 |
| mvo | ijohnson, cachio I will probably throw some away and hopefully push some things as their own PRs | 14:01 |
| cachio | mvo, nice, thanks | 14:02 |
| mvo | cachio: i triggered adt for i386/focal | 14:04 |
| cachio | mvo, tx | 14:05 |
| mup | PR snapd#9302 closed: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9302> | 14:10 |
| micah | hi, i'm trying to run mattermost-desktop snap inside of an lxc container, but I get a weird error it seems related to snap-confine | 14:12 |
| micah | an strace shows this: execve("/snap/snapd/8790/usr/lib/snapd/snap-confine", ["/snap/snapd/8790/usr/lib/snapd/snap-confine", "--base", "core18", "snap.mattermost-desktop.mattermost-desktop", "/usr/lib/snapd/snap-exec", "mattermost-desktop"], 0xc4202a57c0 /* 38 vars */) = -1 EACCES (Permission denied) | 14:13 |
| micah | and it results in a segfault | 14:13 |
| zyga-kaveri | micah: can you please look at apparmor DENIED messages in journald? | 14:14 |
| zyga-kaveri | micah: usually dmesg | grep DENIED is a good start | 14:14 |
| mup | PR snapd#9305 opened: tests: fix nested to work with qemu and kvm <Created by mvo5> <https://github.com/snapcore/snapd/pull/9305> | 14:15 |
| micah | zyga-kaveri: i found these: https://paste.debian.net/1163177/ | 14:17 |
| zyga-kaveri | micah: I think those are a bit over my head, definitely related to LXD's own apparmor profile | 14:19 |
| zyga-kaveri | what kind of setup is this? a debian host with lxd and a container that runs mattermost desktop with forwarded X? | 14:19 |
| micah | zyga-kaveri: debian host, running lxd with snap, and an ubuntu 20.4 container running mattermost desktop with forwarded X, yes | 14:20 |
| zyga-kaveri | micah: I think that may be a little bit beyond our test matrix | 14:21 |
| zyga-kaveri | micah: but the denial itself is related to lxd, maybe stgraber can help or delegate? | 14:21 |
| zyga-kaveri | making tiny bit of progress by digging into fake backend | 14:27 |
| ijohnson | thanks mvo | 14:37 |
| * ijohnson is back now | 14:37 | |
| mvo | ijohnson: the gadget default is wrong (as you probably already noticed, fixed locally) | 14:37 |
| ijohnson | yeah I like the bit about checking for a failed vm state immediately, I think that would make things die a lot quicker with some simple typos that can be rather frustrating :-) | 14:42 |
| mvo | ijohnson: yeah | 14:45 |
| mvo | ijohnson: I particularly like the change that I can telnet to the serial port of the nested qemu, qemu is really magic | 14:45 |
| ijohnson | mvo: yes though that is less useful for spread runs via i.e. github actions where you don't get dropped to a debug shell | 14:46 |
| ijohnson | mvo: I experimented with a pipe fd / tee solution where you would both get all of the serial output in a file for automated / non-interactive runs AND also still be able to login via serial somehow too if running an interactive debug shell, but I didn't spend enough time on it to make it all work properly unfortunately | 14:46 |
| ijohnson | perhaps there's a clean way with qemu to tell it to send to multiple things at once, but I don't think there is when I looked | 14:47 |
| pstolowski | cachio: google-sru:ubuntu-16.04-64:tests/main/snap-run-gdbserver passed for me with release/2.46 | 14:47 |
| cachio | pstolowski, yes | 14:48 |
| pstolowski | cachio: not sure if there is anything special about running these tests? | 14:48 |
| cachio | but | 14:48 |
| cachio | I'll show you how to run it | 14:48 |
| pstolowski | ok | 14:48 |
| cachio | pstolowski, you need to use this env | 14:48 |
| cachio | SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0 SPREAD_TRUST_TEST_KEYS=false SPREAD_SNAP_REEXEC=0 SPREAD_CORE_CHANNEL=stable SPREAD_SRU_VALIDATION=1 | 14:48 |
| mborzecki | pedronis: cmatsuoka: opened https://github.com/snapcore/snapd/pull/9306 with the helper | 14:49 |
| mup | PR #9306: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306> | 14:49 |
| pstolowski | cachio: ah ok | 14:49 |
| cachio | pstolowski, https://paste.ubuntu.com/p/HJpXJ9QrCG/ | 14:50 |
| mup | PR snapd#9306 opened: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306> | 14:50 |
| pstolowski | cachio: thanks | 14:50 |
| cachio | pstolowski, yaw | 14:50 |
| ijohnson | mvo: sorry can you clarify if you are running the qemu-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke or qemu-nested:ubuntu-20.04-64:tests/core20/basic ? | 14:53 |
| ijohnson | I forgot to ask which specific test you were debugging | 14:53 |
| mvo | ijohnson: minimal-smoke | 14:58 |
| ijohnson | ack thanks | 14:59 |
| mvo | ijohnson: I'm in the nested vm right now | 14:59 |
| mvo | ijohnson: but still have no persistent log from the time of the install :/ | 14:59 |
| mvo | ijohnson: I have the /var/log/journal dir though | 14:59 |
| mvo | ijohnson: and no data.cfg in /etc/cloud/cloud.cfg.d | 14:59 |
| ijohnson | mvo: hmm how did you apply the journal persistence logging? | 14:59 |
| mvo | ijohnson: via the gadget default, one sec, let me pastebin my latest diff | 15:00 |
| mvo | ijohnson: this is on top of sergios PR 9284 (just to avoid duplicating fixes) | 15:00 |
| mup | PR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284> | 15:00 |
| ijohnson | r9ght | 15:00 |
| ijohnson | *right | 15:00 |
| mvo | ijohnson: http://paste.ubuntu.com/p/p2NdDvHX9M/ - persistent log is in line 82pp | 15:01 |
| ijohnson | mmm fair enough I used a heredoc, but that's neither here nor there | 15:02 |
| mvo | ijohnson: well, the config apply did work | 15:02 |
| mvo | ijohnson: I can see the dir | 15:02 |
| ijohnson | mvo: did you confirm that the data.cfg file is in the right partition in the image and named correctly ? | 15:02 |
| zyga-kaveri | I've disabled more and more of the state engine and I still see auto-connect | 15:02 |
| zyga-kaveri | with only the snap manager | 15:03 |
| zyga-kaveri | I need to break for PT soon but at some point things to disable will run out | 15:03 |
| mvo | ijohnson: it's under /run/mnt/ubuntu-seed/data/etc/cloud/cloud.cfg.d/data.cfg | 15:03 |
| ijohnson | k, looks correct | 15:03 |
| mvo | ijohnson: so looks correct, snap model --assertion also give me a dangerous assertion so the copy should happen | 15:03 |
| * ijohnson is still waiting to reproduce | 15:03 | |
| * cachio lunch | 15:03 | |
| ijohnson | mvo: can you pastebin logs from the previous boot ? | 15:04 |
| mvo | ijohnson: however this is not master, so maybe I should merge in master to get your latest stuff | 15:04 |
| ijohnson | err the first boot I suppose | 15:04 |
| ijohnson | mvo: probably not necessary to merge in master | 15:04 |
| mvo | ijohnson: sure, I can try, it's layers of vms | 15:04 |
| ijohnson | it's vms all the way down | 15:04 |
| * ijohnson is a vm running a vm inside a vm on a vm | 15:04 | |
| * zyga-kaveri afk | 15:05 | |
| pstolowski | mvo, cachio: re gdbserver test failure, usr/bin/gdbsever is there on 16.04. the error "cannot snap-exec: cannot use "gdbserver" command" suggests that snap-exec doesn't recognize --gdbserver | 15:09 |
| pstolowski | mvo: see snap-exec/main.go, the default case of findCommand | 15:10 |
| mvo | pstolowski: oh, that's confusing, isn't that our snap-exec? | 15:10 |
| mvo | pstolowski: or does it first need to land inside the core stable snap or something? | 15:11 |
| cmatsuoka | mborzecki: thanks, will check after lunch | 15:11 |
| pstolowski | mvo: yeah i'm wondering if that means it's running old snap-exec. fwtw that code change was made 3 months ago | 15:11 |
| pstolowski | mvo: one sec, let me check something | 15:12 |
| mborzecki | need to taxi the kids around for a bit, will check back in later | 15:13 |
| mvo | mborzecki: good luck | 15:13 |
| pstolowski | mvo: so yeah, the core there is 16-2.45.3.1 9804, release 2.45 didn't have "gdbserver" flag in snap-exec | 15:15 |
| pstolowski | (afaict) | 15:15 |
| mvo | pstolowski: ok, mysery solved then | 15:16 |
| pstolowski | strings over snap-exec confirms that | 15:16 |
| mup | PR snapd#9307 opened: interfaces/tee: add TEE/OPTEE interface <Needs security review> <Created by ogra1> <https://github.com/snapcore/snapd/pull/9307> | 15:25 |
| pstolowski | tests/main/searching strikes again (in #9305) | 15:46 |
| mup | PR #9305: tests: fix nested to work with qemu and kvm <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9305> | 15:46 |
| mborzecki | pedronis: updated 9306, will need a merge from master when you PR lands | 16:05 |
| pedronis | cmatsuoka: https://github.com/snapcore/snapd/pull/9306 needs a review, also we used bootloader.Role now | 16:37 |
| mup | PR #9306: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306> | 16:37 |
| cmatsuoka | pedronis: yes, I just noticed that, that was an interesting solution | 16:53 |
| pedronis | encoding/json does the right thing, though reading the docs is not very obvious | 16:54 |
| pedronis | I had to read the code to double check | 16:54 |
| pedronis | cmatsuoka: related to your comment, yes I think in a follow up we should now use bootloade constants for Role | 16:55 |
| pedronis | to avoid confusion | 16:55 |
| ijohnson | pedronis: which pr's for resealing should I look at today | 17:02 |
| ijohnson | I'm about to break for lunch but can start looking after I get back | 17:02 |
| pedronis | ijohnson: we want to land my 9303 (that one has two reviews but tests are giving trouble) https://github.com/snapcore/snapd/pull/9304 and https://github.com/snapcore/snapd/pull/9306 | 17:04 |
| mup | PR #9304: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304> | 17:04 |
| mup | PR #9306: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306> | 17:04 |
| pedronis | ijohnson: I'm dong a run to see if your uc20-recovery PR helps with 9303 | 17:05 |
| * pedronis dinner | 17:07 | |
| pedronis | ijohnson: no, even with your PR merged uc20-recovery is failing on my PR but I'm not quite sure why, the files contains reboot requests | 17:25 |
| ijohnson | pedronis: hmm ok let me have a look | 17:29 |
| pedronis | ijohnson: I don't think the fix is completely right | 17:30 |
| pedronis | -r +10 reboot scheduled to update the system | 17:30 |
| pedronis | stop serial-getty@ttyS0 | 17:30 |
| pedronis | stop getty@tty1 | 17:30 |
| pedronis | is more than two lines | 17:30 |
| pedronis | but won't match one of the patterns | 17:30 |
| ijohnson | pedronis: right that's why afterwards we check for the two reboot lines we care about | 17:31 |
| pedronis | yes, but we might check too early | 17:31 |
| ijohnson | ah I see what you mean | 17:31 |
| pedronis | can't we add some filtering to mock-shutdown itself | 17:31 |
| ijohnson | mm, I suppose I could just put the retry's on checking the MATCH | 17:31 |
| ijohnson | that would work instead | 17:31 |
| pedronis | so tha we get only significative lines | 17:32 |
| ijohnson | sure I can make it such that only lines for "-r ..." go to the file we grep for | 17:33 |
| pedronis | yes | 17:33 |
| mup | PR snapd#9308 opened: tests: allow root to connect to ubuntu core using a certificate <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9308> | 17:41 |
| zyga-kaveri | back from PT | 18:14 |
| zyga-kaveri | food and back to work | 18:14 |
| ijohnson | pedronis: fixed #9299 | 18:16 |
| mup | PR #9299: tests/core/uc20-recovery: fix check for at least specific calls to mock-shutdown <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9299> | 18:16 |
| * cachio -> kinesiologist | 18:25 | |
| pedronis | ijohnson: thx, reviewed | 18:33 |
| pedronis | cmatsuoka: ijohnson: so as I said, we should try to merge 9303 9304 9306, the two latter needs 2nd review, also merging 9299 if it passed uc20-recovery would be good | 18:37 |
| mup | PR snapcraft#3282 opened: v2 plugins: add catkin-tools plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3282> | 18:37 |
| ijohnson | pedronis: ok yes 9304 and 9306 are in my queue now | 18:38 |
| cmatsuoka | pedronis: 9303 is failing on tests but it seems that it's not related to the changes there | 18:38 |
| pedronis | cmatsuoka: are you blocked atm? the next step is essentially reworking 9300 and 9287 on top of 9304 and 9306 | 18:38 |
| cmatsuoka | pedronis: I'm using these changes in my staging branch but having them on master would be better | 18:39 |
| pedronis | cmatsuoka: yes, 9303 failure should be fixed by 9299, I will force merge when the test have finished | 18:39 |
| * cmatsuoka checking 9304 now... | 18:40 | |
| pedronis | but yes, best would be landing them but we need to start from 9303 | 18:40 |
| pedronis | tests have been pain today | 18:41 |
| pedronis | also the store had/has some problems | 18:41 |
| cmatsuoka | yes, I tried to re-run on 9303 a couple of times but they keep failing | 18:41 |
| pedronis | cmatsuoka: we should close #9278, right? is supersed by new logic and 9300 ? | 18:43 |
| mup | PR #9278: boot: seal using boot chains from bootloader <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278> | 18:43 |
| cmatsuoka | pedronis: yes, it has been obsoleted by the new PRs, we should close it | 18:43 |
| pedronis | thx | 18:47 |
| mup | PR snapd#9278 closed: boot: seal using boot chains from bootloader <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278> | 18:51 |
| * cmatsuoka will make a short break | 18:55 | |
| pedronis | I force merged 9303 | 19:06 |
| mup | PR snapd#9303 closed: boot,secboot: switch to expose and use snapcore/secboot load event trees <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9303> | 19:11 |
| cmatsuoka | thanks | 19:16 |
| pedronis | so arch seems to fail sometimes on google:arch-linux-64:tests/main/cgroup-tracking:root | 19:43 |
| ijohnson | pedronis yes I've seen that a few times and mentioned it in the SU doc but I don't understand the error | 19:51 |
| mup | PR snapd#9304 closed: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9304> | 19:56 |
| pedronis | ijohnson: cmatsuoka: I merged 9304 ^ and I fixed conflicts in 9306 | 20:01 |
| ijohnson | pedronis: ah should I just skip striaght to 9306 then ? | 20:03 |
| cmatsuoka | pedronis: thanks! it will make things easier to reconcile here | 20:03 |
| pedronis | ijohnson: yes | 20:07 |
| ijohnson | ack | 20:07 |
| pedronis | ijohnson: cmatsuoka: I made #9309 on top #9306, it's just a cleanup but likely conflict prone | 20:14 |
| mup | PR #9309: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9309> | 20:14 |
| mup | PR #9306: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306> | 20:14 |
| cmatsuoka | pedronis: ack, checking this one... | 20:15 |
| mup | PR snapd#9309 opened: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9309> | 20:16 |
| pedronis | cmatsuoka: it's related to your comment in the other one | 20:17 |
| cmatsuoka | pedronis: ah, yes, I just checked the relevant commit. thanks. | 20:17 |
| cmatsuoka | why are tests so slooooow today?? | 20:32 |
| === jdstrand_ is now known as jdstrand | ||
| === ahayzen_ is now known as ahayzen | ||
| pedronis | ijohnson: what channel did you use for core20 when built your image to test nested? | 20:38 |
| ijohnson | pedronis: edge | 20:38 |
| pedronis | ? | 20:38 |
| ijohnson | what? | 20:39 |
| pedronis | ijohnson: afaict your fix https://github.com/snapcore/core20/pull/84/files is not in edge | 20:39 |
| mup | PR core20#84: static/writable-paths: use transition instead of none for /etc/cloud <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/84> | 20:39 |
| ijohnson | ... it should be? | 20:39 |
| ijohnson | pedronis: the fix for that is in edge | 20:40 |
| ijohnson | pedronis: at least for revision 819 | 20:40 |
| ijohnson | I also double checked and the image built for the nested test here has the fix as well | 20:41 |
| ijohnson | (and the same revision of the core20 snap too) | 20:41 |
| pedronis | ijohnson: mmh, notice that here https://github.com/snapcore/snapd/pull/9098 mimimal-smoke failed on 18 | 20:46 |
| mup | PR #9098: tests: new organization for nested tests <Run nested> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098> | 20:46 |
| pedronis | it was merged anyway | 20:46 |
| ijohnson | pedronis: mmm also 16.04 failed on minimal-smoke too | 20:47 |
| ijohnson | this would confirm my theory that something in nested.sh is broken | 20:47 |
| pedronis | why did we merge that though? are they super flaky anyway? | 20:47 |
| ijohnson | well the nested tests in general are slightly flaky but there were just too many other fixes in that PR, in the future we should really be more careful to split up changes | 20:48 |
| ijohnson | the nested tests are just suffering from so much churn right now | 20:49 |
| ijohnson | I'm now trying a fresh build with just snapd from that branch to see if the snapd snap is somehow broken from nested.sh now | 20:51 |
| pedronis | ijohnson: this run worked https://github.com/snapcore/snapd/runs/1038225314 13 days ago | 20:53 |
| pedronis | this one also workd: https://github.com/snapcore/snapd/runs/1052967599 | 20:55 |
| ijohnson | right | 20:56 |
| pedronis | also this one: https://github.com/snapcore/snapd/runs/1067305138 | 20:56 |
| pedronis | 6 days ago | 20:56 |
| pedronis | but this from today failed https://github.com/snapcore/snapd/pull/9302 | 20:58 |
| mup | PR #9302: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9302> | 20:58 |
| ijohnson | so yes if I just use the snapd snap that was produced for the nested run it fails | 20:58 |
| ijohnson | i.e. I build my own image and boot it with my tools, and the only snap I replace is the snapd snap, then cloud-init is not run | 20:59 |
| ijohnson | err rather it is immediately disabled instead of importing from ubuntu-seed | 20:59 |
| pedronis | so is snapd code, not nested.sh ? | 20:59 |
| pedronis | some of the sysconfig changes? | 21:00 |
| ijohnson | the only changes are here https://pastebin.ubuntu.com/p/m9SvCkkmkM/ | 21:01 |
| ijohnson | it could be the sysconfig changes I suppose | 21:02 |
| ijohnson | somehow? | 21:02 |
| pedronis | I notice we didn't run them with nested on | 21:02 |
| ijohnson | yeah I guess I didn't figure that sysconfig changes would need nested runs :-( | 21:03 |
| ijohnson | tbh I think we should have had the uc20 tag also trigger nested tests too for all pr's | 21:03 |
| ijohnson | a bit late for that now though | 21:03 |
| pedronis | ijohnson: I suspect https://github.com/snapcore/snapd/pull/9253/files | 21:07 |
| mup | PR #9253: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9253> | 21:07 |
| pedronis | do we set to true in the relevant places? | 21:07 |
| pedronis | that PR wasn't setting it anywhere | 21:07 |
| pedronis | so I suspect it just turned it off? | 21:08 |
| ijohnson | mmm | 21:08 |
| ijohnson | maybe | 21:08 |
| cmatsuoka | pedronis: 9306 tests finished with the usual fails | 21:08 |
| cmatsuoka | pedronis: could you force-merge it too? | 21:08 |
| ijohnson | pedronis: yeah I think you're right | 21:09 |
| pedronis | we landed your last one, that use it sometimes but not sure we set it in all the places | 21:09 |
| pedronis | this is a bit the risk of splitting things | 21:09 |
| pedronis | sometimes | 21:09 |
| ijohnson | pedronis: ok, so I rebuilt snapd exe from master with my last PR merged and just replacing snapd binary in the spread snapd I extracted now cloud-init works | 21:10 |
| ijohnson | so theoretically it should have been broken by the first PR's landed, then fixed with the last PR that was merged | 21:10 |
| ijohnson | also of interest is the fact that mvo was debugging things based on Sergio's PR which does not have the master merge from my final PR | 21:10 |
| pedronis | ijohnson: so the question is, to be have only one place right calling the relevant function? | 21:10 |
| ijohnson | so | 21:10 |
| ijohnson | yes we only have one place calling the sysconfig function | 21:10 |
| ijohnson | err to be more precise | 21:11 |
| ijohnson | we set sysconfig.Options for cloud-init in one place | 21:11 |
| ijohnson | and on master that is correct | 21:11 |
| ijohnson | so I think if I trigger a run of this on master it should pass actually | 21:11 |
| ijohnson | I need to go pick up my car though, so I will trigger a run on master to see what happens | 21:11 |
| ijohnson | maybe it passes | 21:11 |
| pedronis | cmatsuoka: I hoped ijohnson would also look at 9306 | 21:12 |
| ijohnson | pedronis: cmatsuoka: yes sorry I was midway through a review and got sidetracked with nested tests | 21:12 |
| ijohnson | I will have to finish my review in a bit like an hour or so from now though | 21:13 |
| * ijohnson afk little bit | 21:13 | |
| * zyga-kaveri EODs | 21:13 | |
| zyga-kaveri | good night! | 21:13 |
| pedronis | ijohnson: cmatsuoka: I can land it and we apply feedback after the fact (it does have two +1) | 21:13 |
| cmatsuoka | pedronis: i would be ok with that | 21:14 |
| pedronis | cmatsuoka: ijohnson: done | 21:20 |
| cmatsuoka | pedronis: thanks | 21:21 |
| mup | PR snapd#9306 closed: boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9306> | 21:22 |
| pedronis | cmatsuoka: I merged #9309 as well (it was just replacing strings in tests anyway) and had your +1 | 21:29 |
| mup | PR #9309: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9309> | 21:29 |
| pedronis | cmatsuoka: so master should have all the bits now that you need | 21:30 |
| pedronis | merged | 21:30 |
| cmatsuoka | pedronis: yes, I'm running an integrated test with load chains now | 21:30 |
| mup | PR snapd#9309 closed: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9309> | 21:32 |
| mup | PR snapcraft#3282 closed: v2 plugins: add catkin-tools plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3282> | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!