[00:46] ijohnson: thanks for the suggestion. It looks like security.syscalls.intercept.mknod was enough for my use case, so I might try getting that upstream into Snapcraft [00:46] ijohnson: might be worth seeing if that works for you in CI too [00:46] jamesh: interesting, how did you use that with lxc ? [00:47] ijohnson: I failed to build my project, stopped the container and ran "lxc config set snapcraft-core20-gdm security.syscalls.intercept.mknod=true" [00:47] and tried again [00:48] ijohnson: with this configuration, LXD allows a few mknod syscalls it considers safe [00:48] enough for the small number of bootstrap device files I needed in the base snap [00:48] nice, yeah I'll give that a try then [00:48] ijohnson: more details at https://linuxcontainers.org/lxd/docs/master/syscall-interception#mknod-mknodat [00:49] it will let you create /dev/null, but not /dev/sda1 :-) [00:50] right :-) === benfrancis2 is now known as benfrancis [02:33] PR snapcraft#3218 opened: WIP: support some mknod calls in LXD builds [05:23] morning [06:36] mvo: hey [06:38] hey mborzecki [06:44] mvo: can you take a look at https://github.com/snapcore/snapd/pull/9006 ? [06:45] PR #9006: bootloader: compose command line with mode and extra arguments [06:56] mborzecki: yeah, need to work a bit on packaging but will look while things are building etc [06:56] mvo: thanks! [07:03] morning [07:09] good morning pstolowski [07:10] pstolowski: heya [07:15] o/ [07:39] good morning [07:41] zyga: good morning [07:41] somewhat better night [07:41] still 4AM-7AM hole is not great [07:42] today will be the more traditional snapd hacking day [07:43] PR snapd#9008 closed: boot/initramfs_test.go: add Commentf to more Assert()'s [07:44] ijohnson: should we ask dimitri to review 9010 ? [08:13] mvo: pushed your suggestion from https://github.com/snapcore/snapd/pull/9006#discussion_r454847330 with some tweaks, please take a look, it's a regex so extra pair of eyes won'thurt [08:13] PR #9006: bootloader: compose command line with mode and extra arguments [08:29] ogra@pi4:~$ snap connect node-red-rpi:gpio pi4-devel😛cm-gpio-14 [08:29] error: cannot perform the following tasks: [08:29] - Connect node-red-rpi:gpio to pi4-devel😛cm-gpio-14 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs) [08:29] ogra_: nice error message you have there [08:29] hrm ... emojis ... [08:29] yeah, my hexchat emoji plugin is a bit dumb [08:30] zyga, so what is that ? what am i missing ? (my pi3 image works, my locally built pi4 one doesnt anymore) [08:30] it's a very specific error, it means that more than one thing would like to export the same GPIO IIRC [08:30] seems that's new with yesterdays core release [08:30] are the GPIO slots defined correctly? [08:31] * zyga looks at snapd source [08:31] so [08:31] it's when an interface defines a systemd service [08:31] like we do for GPIO [08:31] https://paste.ubuntu.com/p/yXCtRqP6QJ/ [08:31] thats my snap.yaml ... [08:32] and there's a service with a name but different definition [08:32] shoudl eb identical to our std ones [08:32] mborzecki: heh, nice - sure, I have a look. don't get me wrong, I'm usually not a let's-use-regex type but this seemed appropriate [08:33] ogra_: weird, I mean the error does look valid unless we are missing something [08:33] zyga, well i was indeed trying to get multiple apps read info from the same GPIO ... one is managing it, the other is monitoring it ... [08:33] mborzecki: looks great [08:33] mvo: heh, i still think adding regex is adding yet another problem, but yeah, this one seemed ok [08:33] ogra_: look at /etc/systmed/system/ [08:34] but since that error started occuring i cant connect/disconnect *and* GPIO interfaces anymore [08:34] *any [08:34] for .service files named after the slot snap name (gadget here) [08:34] and gpio-NNN [08:34] maybe there's some bug there [08:34] gra@pi4:~$ ls -l /etc/systemd/system/|grep gpio [08:34] -rw-r--r-- 1 root root 264 Jun 20 10:41 snap.pi4-devel.interface.gpio-14.service [08:34] -rw-r--r-- 1 root root 260 Jul 13 13:25 snap.pi4-devel.interface.gpio-4.service [08:35] this error is reported when the same file name has two differing definitions [08:35] interestingly i'm pretty sure i have never connected gpio-4 [08:36] ogra@pi4:~$ snap connections node-red-rpi|grep gpio [08:36] gpio node-red-rpi:gpio pi4-devel😛cm-gpio-4 manual [08:36] gpio-memory-control node-red-rpi:gpio-memory-control :gpio-memory-control manual [08:36] and ... [08:36] ogra@pi4:~$ snap disconnect node-red-rpi:gpio pi4-devel😛cm-gpio-4 [08:36] error: cannot perform the following tasks: [08:36] - Disconnect node-red-rpi:gpio from pi4-devel😛cm-gpio-4 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs) [08:36] (sorry for the smileys) [08:38] oh, WOW [08:38] ogra@pi4:~$ snap stop node-red-rpi [08:38] Stopped. [08:38] ogra@pi4:~$ snap disconnect node-red-rpi:gpio pi4-devel😛cm-gpio-4 [08:38] error: cannot disconnect node-red-rpi:gpio from pi4-devel😛cm-gpio-4, it is not connected [08:40] ogra@pi4:~$ snap connections |grep gpio [08:40] gpio node-red-rpi:gpio pi4-devel😛cm-gpio-4 manual [08:40] what a mess [08:41] pstolowski: ^^ hmm [08:44] could be the undo bug i fixed recently [08:45] and funnily enough, the app can read the gpio state now [08:45] (along with the other app managing it ) [08:46] there were 2 bugs around this area where under certain circumstances security profile wouldn't reflect disconnected state [08:47] ogra_: can you restart snapd and re-try? [08:48] pstolowski, funny ... that works ... i had rebooted inbetween [08:49] i mean i had rebooted anmd it still did not work ... [08:49] the manual snapd restart lets me disconnect now [08:49] ogra_: weird.. restart (reboot as well) would work around that bug [08:49] yes, very curious ... [08:50] the problem was caused by inconsistent in-memory state of snapd after undo of a failed operation [08:50] i can still not connect two apps to the same gpio interface though [08:51] ogra_: because of that "interface requires conflicting system .." error? [08:51] yep [08:51] * ogra_ arghs ... i forgot i have a meeting in 10min ... [08:52] ok, i don't know about that, would need investigation [08:52] ogra_: perhaps report a bug with all the details of these snaps [08:52] will do [08:52] thanks\ [09:19] * zyga is really close to putting his x240 into the bin [09:19] linux runs well on thinkpads my ass [09:21] hmm [09:23] zyga: what's the problem? [09:23] suspend resume is broken [09:23] input stops working [09:23] past my level of accepting broken stuff [09:24] too tired [09:25] as much as I like native linux stuff like that makes me question sensibility of spending $$$ on new linux portables [09:33] zyga: my x250 is doing fine since forever and my t460s too [09:33] oh well [09:33] draw a lottery [09:33] zyga: and the x220 in the house too, the t400 too, they all suspend/resume all the time [09:33] it suspends allright ;) [09:34] zyga: yeah, looks like you got a bad lot :( [09:34] just on resume there's no input [09:34] and the log is full of errors [09:36] mvo: morning! yes we will want dimitri to look at it eventually I'm pretty sure, not sure if that point is now or not [09:37] +1 [09:37] ta [09:54] ijohnson: hey, looking at your feedback in #9005, bootloader.Options is too confusing :/ [09:54] PR #9005: boot: support setting extra command line argument, bootloader interface tweaks === pedronis_ is now known as pedronis [09:55] mborzecki: I asked a question there [09:55] and hi [09:55] pedronis: hey [09:58] hey, welcome back pedronis :) [10:03] Welcome back pedronis [10:03] mborzecki: mmm you mean my feedback is confusing or it's too confusing to pass Options there? [10:04] pedronis: yeah, that's why i used InitramfsUbuntuBootDir there, should give us ubuntu-boot in install mode and run mode [10:04] ijohnson: options has become a bit confusing [10:05] we need to fix the names of things [10:08] ah yes options is rather confusing now with all the different names and implications [10:09] ijohnson: pedronis: anyways i did not add a helper for setting extra args in recovery mode, as we can do it directly in makeBootable20 [10:09] s/in/for/ [10:21] I I have updated my review queue, but not started on reviews yet, maybe this afternoon, I still have some catch up to do and also quite a few meetings in the afternoon [10:21] * pedronis but lunch first [10:42] uh, some annoying pain [11:08] uhh, managers tests are mocking/state setup heavy [11:33] mborzecki: haha yes indeed they are :-) [11:35] mborzecki: so I'm reviewing your code for setting up the cmdline for grub.cfg when managed by snapd PR's and I just want to take a step back and wonder why we need to have the static cmdline args inside the grub.cfg inside snapd at all? Why don't we have some other kind of internal asset setting which is just a list of strings (or a map[string]string) for the static / extra cmdline parameters separate from the grub.cfg [11:36] then we would not need to parse out the grub.cfg's setting of the cmdline from the grub.cfg at all, we would just compose it easily using go list of strings (or again a map) and then paste it into the grub.cfg when it is generated and written out to disk [11:36] that also seems like what we will end up doing when the gadget.yaml grows language to tell snapd about what kernel command line should be used [11:36] ijohnson: the last part is horrible [11:36] woah sorry what is horrible [11:36] composing grub.cfg [11:36] doesn't seem we need to parse it [11:37] I don't have a preference on that [11:37] it's literally just fmt.Sprintf with `cmdline=%s` ? [11:37] well seems it's slightly more complicated than that [11:37] ijohnson: yes, but the edition inside it loses any meaning [11:37] that's why I used the word horrible [11:38] so how will this work when the gadget.yaml wants to tell snapd what kernel command line to use ? [11:38] pedronis: ijohnson: maybe we should ahve another chat about cmdline wrt the doc that we discussed? [11:38] maybe I need to read your doc again [11:38] ijohnson: the plan is to use the envs to convey that [11:38] not the cfg [11:38] maybe that isn't clear from the current code [11:38] ijohnson: hence snapd_extra_cmdline_args [11:39] anyway none of this particularly means we should parse something out of the cfgs, I don't have a strong peference there [11:39] given how actually this is used is slightly misleading [11:39] in fact [11:41] mborzecki: ijohnson: yes, I think another chat might be appropriate [11:41] not sure we can fit it today though [11:43] sure I think a chat would be good [11:43] pedronis: maybe right before/after the standup? [11:43] before could work [11:43] works for me [11:44] but in case it is an easy answer, which direction is snapd_extra_cmdline_args used? is that set by the gadget on image build time into the bootenv and then read by install mode snapd to then be used in writing the run mode bootloader config / env ? [11:45] ijohnson: it's never read, it meant to be only written to [11:45] oh actually now I've gone and confused myself between the extra and static args [11:45] I mean is read by the cfg but snapd code should always only write it [11:46] pedronis: so extra is always written by snapd out of thin air, and static is always coming entirely from the bootenv / gadget ? [11:46] pedronis: it's read when we want to compose what the command line will look like [11:46] mborzecki: ? [11:46] sorry something is very wrong then [11:46] mborzecki: but it's "read" from inside snapd though right ? [11:46] it's not read from the system / bootloader [11:46] iiuc [11:47] ijohnson: mborzecki: it should be read from the gadget, never from the env by snapd [11:47] pedronis: when you say "it" just now, which one do you mean ? [11:48] the extra args [11:48] if I remember what was discussed [11:48] I haven't looked at the code [11:48] maybe we need pseudo code hre [11:48] yes what's confusing me is the ownership / reading direction of the env vars [11:49] it should be very clear when you consider the security implication what should and shouldn't happen [11:49] but I don't know what the current code is doing [11:49] yes, let's ignore the current code for now (sorry mborzecki :-) ) [11:50] pedronis: hmm right, but we don't have the gadget part yet because it was not discussed, so the code is reading it from the env until we figure out the gadget.yaml [11:50] mborzecki: it shouldn't do anything [11:50] then [11:50] this has all security implications [11:50] we cannot half build pieces [11:50] without thinking through the consequences [11:51] pedronis: yes, the same as reading static from disk, ok, let me drop that for now and leave a todo about gadget there [11:51] iiuc snapd should own the "static" env var and that should be entirely written by snapd for run/recover mode, and the gadget should own the "extra" part by writing into it's default bootenv for install mode, which snapd then just copy pastes from install bootenv into the run/recover boot env [11:51] is that understanding what you expect pedronis? [11:51] sounds about right [11:51] ok [11:52] I think I understand what the design is then [11:53] and i need to update the doc then [11:54] ijohnson: actually, no, the copy from install bootenv sounds wronng [11:55] oh [11:55] snapd should read this info out of the gadget [11:55] never the env [11:55] ah yes that was what I thought the original design was supposed to be [11:55] by read out of the gadget, do you mean read the bootenv out of the gadget snap, or do you mean read something like the gadget.yaml ? [11:55] it then should write to env and use the pieces it built to know what to put as expectzed in the fde policy [11:56] ijohnson: there's not bootenv in the gadget [11:56] afair [11:56] not for grub [11:56] or maybe there is [11:56] anyway, some info out of gadget.yaml or a .txt file [11:56] iirc we discussed gadget.yaml the last time [11:56] pedronis: for grub there is not [11:57] alright that all makes more sense and is closer to what I expected [11:57] fwiw, whether gadget or txt file is fetching it should be trivial [11:59] right [12:23] ijohnson: mborzecki: do we still need a meeting? [12:23] I think it would still be nice even if just for 10-15 minutes [12:23] pedronis: ijohnson: 5-10 minute one right before the standup maybe? so that we're on the same page [12:23] ok [12:23] sounds good to me [12:24] let's do 10 mins [12:24] k [12:50] PR snapd#9011 opened: release: merge 2.45.2 into release/2.45 [12:51] Is "MicroStack" worth a look? Or should i go another way? [12:52] okay, [12:53] ``` [12:53] error: cannot install "microstack": cannot query the store for updates: got unexpected HTTP status [12:53] code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh" [12:53] ``` [12:54] I think is not you ;-) Is my LAN ;-) [13:04] PR snapcraft#3216 closed: build providers: tweak environment clean detection and logging [13:04] PR snapcraft#3217 closed: cmake v2 plugin: add stage to CMAKE_PREFIX_PATH [13:54] * zyga breaks for 15 minutes and then back to branches [13:55] PR snapcraft#3218 closed: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes [13:57] sdhd-sascha: the snap store is a bit under load right now, you might have difficulty installing snaps for a little bit today, but give it an hour or two and itshould be back to normal I think [13:57] cmatsuoka: regarding your comment here https://github.com/snapcore/snapd/pull/9010#discussion_r455026520, what do you mean archive and snap versions? of govendor? [13:57] PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool [14:03] ijohnson: govendor, I remember I had a problem with mismatched hashes some time ago and I think it was caused by using a different govendor version [14:04] mmm I only have govendor from $GOBIN [14:04] ijohnson: now I'm using the focal deb which seems to be working well [14:05] mmm, perhaps I could try that, seems the focal version is 1.0.9 which is the same as my local $GOBIN, but I will look at what happens with the deb to see if that explains the SHA difference [14:07] or your new hash is right and the previous one was computed with a different version? [14:11] mvo: there's a conflict in https://github.com/snapcore/snapd/pull/9011 [14:11] PR #9011: release: merge 2.45.2 into release/2.45 [14:11] mborzecki: will fix after the meeting === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [14:41] cmatsuoka: actually with the focal version of govendor I see the same diff, I did a clean checkout of snapd into a separate GOPATH, and only had govendor from apt on my $PATH and running get-deps still makes that checksumSHA1 change [14:42] cmatsuoka: so I'm really confused what's up here [14:42] cmatsuoka: are you on focal and using the deb ? [14:42] let me double check here [14:43] mm, yes, version 1.0.9+ds1-1 [14:43] yeah same here [14:44] perhaps the previous hash is old, and the one you're computing now is what it should be? [14:44] isn't govendor using the stuff from your gopath? [14:44] (as in, it can put stuff from gopath into vendor) [14:45] PR snapd#9011 closed: release: merge 2.45.2 into release/2.45 [14:45] zyga: yes but I have a new clean gopath with nothing in it except a fresh snapd master clone [14:45] ah [14:45] hmmmm [14:45] no idea then [14:46] could it be looking at more than gopath? [14:46] e.g. goroot? [14:47] cmatsuoka: are you using go from the snap or from the debian package ? [14:47] * ijohnson only uses go from snap [14:48] mm, mine is from the deb, 2:1.13~1ubuntu2 [14:48] cmatsuoka: what is `go version` for you ? [14:49] go version go1.13.8 linux/amd64 [14:49] mine is `go version go1.14.4 linux/amd64` [14:50] I used to use the snap version then switched to the deb version at some point [14:50] PR snapd#9012 opened: release: merge 2.45.2 release [14:51] that's one unusual diff ;) [14:55] PR snapd#9013 opened: many: merge 2.45.2 fixes back into master === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [15:05] * cachio lunch [15:16] cachio: when you are back can you explain to me the early config test failure ? [15:17] store seems to be under load, spread jobs are failing [15:19] yes [15:22] hmm something odd happening with github, i've pushed changes to a branch, but the PR was not updated [15:25] github under load too ? [15:25] ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9006 later during your day? i've pushed the changes but the PR was not updated yet (hopefully it will be soon) [15:25] PR #9006: bootloader: compose command line with mode and extra arguments [15:25] sure [15:25] PR snapd#9014 opened: [RFC] snapshotstate: move sizer to osutil.Sizer() [15:29] ijohnson: thanks [15:30] closed and reopened, and now the commits show up, wtf [15:31] * ijohnson afk little bit [15:51] PR snapd#9015 opened: cmd/snap-preseed: handle relative chroot path [15:58] ijohnson, hi [15:58] hi [15:59] ijohnson, so, the problem is that when we create the image and tehn try to connect the user created through cloud init is not sudoer [15:59] mmm [15:59] this is the log I got from the cloud init https://paste.ubuntu.com/p/McnFjkHBVh/ [15:59] cachio: what specific test failed with what backend ? [15:59] ijohnson, it is happening 100% of the time [15:59] just sometimes [16:00] spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-confi [16:00] cachio: sorry you mean that it is _not_ happening 100% ? [16:00] ijohnson, sometimes works well [16:00] but sometimes it doesn't [16:00] this is the weird part [16:01] so if you run this test 3/4 times you will reproduce it for sure [16:01] cachio what's the username you were expecting to see? [16:01] user1 [16:01] do you have a log from a successful run? [16:02] zyga, no [16:03] zyga, I can generate one [16:03] maybe if we compare them something will show up [16:03] 18:00, time for meds [16:03] zyga, yes [16:03] agree [16:03] ouch, brb [16:17] cachio: ah now I can't reproduce that because store woes [16:17] cachio: I will try to reproduce again in a bit [16:40] ijohnson, this is the log when it works well https://paste.ubuntu.com/p/zWdn8kjb8Q/ [16:40] perhaps it contains usefull data [16:40] I am taking a loog [16:40] look [16:42] cachio: looking [16:42] take a lok to line 460 [16:42] the it adds the user [16:42] but in the other one that line does not appear [17:00] ijohnson, the weird part is that in both cases the user is created [17:58] ijohnson, could you reproduce it? [18:01] I triggered it again [18:01] I'll give you access if it fails [18:05] cachio I'll try again this morning the store was acting up for me [18:05] Err rather, I'll try again right now [18:31] PR snapd#8972 closed: gadget/install,secboot: use snapcore/secboot luks2 api [18:43] * cachio -> kinesiologist [20:19] diddledan: when you tried etrace and it didn't automatically close the window, were you using wayland ? [21:12] PR snapd#9016 opened: secboot: improve key sealing tests [22:02] PR snapd#9009 closed: tests/cmd/snap-bootstrap/initramfs-mounts: rm duplicated env ref kernel tests [22:26] ijohnson, hi [22:26] there? [22:28] ijohnson, could be affecting that rsyslog configuration in cloud init? [22:28] stages.py[DEBUG]: Running module rsyslog () with frequency once-per-instance [22:28] in this test we update the gadget configuration and disable rsyslog by default [22:29] I see that when it fails to created the user1 is when this line "Running module rsyslog" is executed early [22:29] before than the user [22:30] could that be affecting? [22:32] cmatsuoka, hey [22:32]