| === Eickmeyer is now known as Eickmeyer__ | ||
| === Eickmeyer__ is now known as Eickmeyer_E | ||
| mborzecki | morninb | 05:10 |
|---|---|---|
| mborzecki | morning | 05:10 |
| mborzecki | mvo: good morning | 06:29 |
| mvo | mborzecki: good morning | 06:30 |
| mborzecki | mvo: do we need https://github.com/CanonicalLtd/subiquity/pull/770 and https://github.com/snapcore/snapd/pull/8661 for beta? | 06:32 |
| mup | PR CanonicalLtd/subiquity#770: console-conf: always run when triggered for the chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/770> | 06:32 |
| mup | PR #8661: configcore: add "service.console-conf.disable" config option <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661> | 06:32 |
| mvo | mborzecki: it's not beta critical | 06:32 |
| mvo | mborzecki: I will not even backport it :) | 06:32 |
| mborzecki | mvo: ah ok | 06:33 |
| zyga | Good morning | 06:45 |
| mborzecki | zyga: hey | 06:47 |
| mvo | hey zyga | 06:50 |
| pstolowski | morning | 06:59 |
| ackk | good morning, I'm seeing a weird behavior with a core20-based snap. If I call the snapraft-runner script in a configure hook, it segfaults | 07:01 |
| ackk | it worked fine with core18 | 07:01 |
| mborzecki | pstolowski: hey | 07:09 |
| ackk | oh, actually I might know what's the issue | 07:11 |
| ackk | have snap hook always been duplicated in snap/hooks and meta/hooks ? | 07:16 |
| mborzecki | hmm google:ubuntu-18.04-64:tests/main/mount-ns:reboot failing? | 07:20 |
| zyga | mborzecki: how? | 07:21 |
| mborzecki | zyga: https://paste.ubuntu.com/p/NSHS5rHk34/ | 07:22 |
| mborzecki | look slike / is moutned with different options and efivars is present | 07:22 |
| zyga | Are you up to date in relation to master? | 07:22 |
| zyga | This changed yesterday to match the new image | 07:23 |
| mborzecki | ah ok, i need to update tht branch then | 07:23 |
| zyga | ackk: hooks must be in meta/hooks | 07:24 |
| zyga | Perhaps snapcraft is copying them? | 07:24 |
| ackk | zyga, yeah I mean you put them in snap/hooks for snpcraft to find them right? | 07:25 |
| zyga | I don’t really know, 90% of my snaps are hand made | 07:25 |
| ackk | heh | 07:26 |
| ackk | ah yeah, it seems they've always been in both places. | 07:28 |
| ackk | maybe snapcraft could not populate snap/hooks? | 07:29 |
| zyga | That does seem weird | 07:29 |
| mup | PR snapd#8667 opened: interfaces/fwupd: allow bind mount to /boot related on core <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/8667> | 07:38 |
| ackk | zyga, IIUC snapcraft copies snap/ as-is, with the exception of snap/local | 07:43 |
| mup | PR snapd#8663 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8663> | 07:57 |
| mup | PR snapd#8664 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8664> | 08:05 |
| mup | PR snapd#8665 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8665> | 08:05 |
| pstolowski | xnox: hey | 09:04 |
| ackk | mvo, hi, to confirm, there's currently no way via sudo/su to drop from root the snap_daemon user, right? | 09:09 |
| mvo | ackk: hey, not sure I understand the question, can you please give me a little bit more context? what do you want to archive exactly. you are root and drop to the snap daemon-user inside the snap? | 09:11 |
| ackk | mvo, yes, I want to run a process as daemon user, ideally from a bash script. afaict sudo/su don't work in the snap | 09:13 |
| ackk | mvo, I thought we did that in maas, but actually we have a python script that does that | 09:15 |
| mvo | ackk: I'm out of my depth here unfortunately, I think we need jdstrand to help if you can use su/sudo inside a snap to drop from root to the snap-daemon user | 09:15 |
| ackk | mvo, ok, np, thanks | 09:15 |
| pstolowski | zyga: what was the PR you wanted reviewed to unblock you (mentioned yesterday in the standup)? | 09:43 |
| zyga | pstolowski: let me find it | 09:43 |
| zyga | https://github.com/snapcore/snapd/pull/8566 | 09:43 |
| mup | PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566> | 09:43 |
| pstolowski | k | 09:44 |
| mborzecki | wow, https://github.com/snapcore/snapd/pull/8650 is green | 09:47 |
| mup | PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650> | 09:47 |
| ijohnson | ackk: if you want to drop privs to snap_daemon from a shell script you need to use one of the tricks mentioned in "Usage considerations" on https://snapcraft.io/docs/system-usernames | 09:51 |
| ackk | ijohnson, ah, thanks | 09:53 |
| zyga | re | 09:53 |
| zyga | sorry, helped wife with lucy for a moment | 09:53 |
| zyga | mborzecki: makes all the test fixing worth it :) | 09:54 |
| zyga | pstolowski: I removed the hacks around /home/ubuntu from https://github.com/snapcore/snapd/pull/8633 it now simply ignores it | 10:00 |
| mup | PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633> | 10:00 |
| zyga | pstolowski: also extended tests to show this | 10:00 |
| pstolowski | thanks | 10:00 |
| zyga | pstolowski: and extended help to show the invariants | 10:00 |
| zyga | pstolowski: I think it's good now | 10:00 |
| zyga | and rebased on master to get all the fixes | 10:00 |
| zyga | I didn't do the extra test suite as that's somewhat more work | 10:01 |
| pstolowski | zyga: naive question to the lock PR | 10:12 |
| zyga | looking | 10:12 |
| zyga | pstolowski: as in when the lock file exists but is empty? | 10:13 |
| zyga | pstolowski: if you look at unlock() that's exactly an unlocked lock :) | 10:13 |
| zyga | pstolowski: we truncate to unlock | 10:13 |
| pstolowski | zyga: exists & not-empty | 10:13 |
| zyga | if it exists and is non-empty then it is locked | 10:13 |
| pstolowski | zyga: yes and if reboot happens it remains non-empty, is it going to ihibit snap run? | 10:14 |
| zyga | perhaps the confusing aspect is that there are two locks in one: the contents of the file and the flock protecting reading/writing the contents | 10:14 |
| zyga | yes | 10:14 |
| zyga | pstolowski: that's the fature | 10:14 |
| zyga | *feature | 10:14 |
| zyga | it can very much happen that you reboot to uninhibit | 10:14 |
| pstolowski | zyga: is there a guarantee it gets released? | 10:14 |
| pstolowski | (i'm missing bigger picute) | 10:14 |
| pstolowski | *picture | 10:14 |
| zyga | pstolowski: it's not a part of this branch | 10:14 |
| zyga | pstolowski: it's the same question as link/unlink snap | 10:15 |
| zyga | pstolowski: those are just the primitives | 10:15 |
| zyga | pstolowski: and the primitives do allow having a lock for indefinite amount of time | 10:15 |
| pstolowski | ok. my only concern is that this interrupts a snapd op in flight and we leave snap run unusable for given snap | 10:15 |
| pstolowski | but yes, i can see it belongs elsewhere to handle this | 10:15 |
| zyga | pstolowski: if you look at the usage of this in another PR | 10:15 |
| zyga | I currently inihibit before unlinking | 10:15 |
| zyga | and uninhibit after linking | 10:16 |
| zyga | though my preference is to expand that period so we inhibit when we decide to refresh | 10:16 |
| zyga | and uninhibit when refresh is either done or aborted | 10:16 |
| ijohnson | mborzecki: have you seen https://bugs.launchpad.net/snapd/+bug/1878505 ? | 10:20 |
| mup | Bug #1878505: recovery chooser doesn't trigger on rpi with core20 <snapd:New> <https://launchpad.net/bugs/1878505> | 10:20 |
| mborzecki | ijohnson: hm not surprised really, it's probably a usb keyboard, so it may come up whenever during the boot | 10:21 |
| ijohnson | mborzecki: yes he mentioned it was a usb keyboard, in fact he has multiple attached | 10:22 |
| mborzecki | ijohnson: probably after loadign the modules, and udev has to settle and create input devices by the time the trigger detection runs | 10:22 |
| ijohnson | mborzecki: so perhaps the chooser should gain a systemd depends on systemd-modules-load and systemd-udev-settle (or whatever it's called) ? | 10:22 |
| mborzecki | ijohnson: the post-pivot one runs after snapd seeding is done iirc | 10:23 |
| ijohnson | ah I see | 10:23 |
| mborzecki | ijohnson: what i would expect to work pretty well is using gpio-keys in dtb, setting up one gpio to emit KEY_1 | 10:23 |
| pstolowski | quick errand, bbiab | 10:25 |
| mup | PR snapd#8650 closed: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8650> | 10:26 |
| mborzecki | ijohnson: added a note, not sure udev settle would fix that reliably tho | 10:33 |
| mborzecki | it's a usb stack after all :/ | 10:33 |
| zyga | brb | 10:38 |
| ijohnson | mborzecki: ack thanks for looking at it | 10:44 |
| mup | PR snapd#8668 opened: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 10:45 |
| ijohnson | pedronis: mvo: I opened https://github.com/snapcore/snapd/pull/8668 which is the first step to cross-check, complete with some tests, not sure if y'all will want more tests or not, it's already at ~1k lines | 10:45 |
| mup | PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 10:45 |
| pedronis | ijohnson: thanks I will look, we would also like to move partition somewhere else before 1.0, so need also to think whether this bits belong here or not | 10:46 |
| ijohnson | ok | 10:47 |
| pedronis | *these bits | 10:47 |
| mvo | ijohnson: thanks | 10:50 |
| zyga | re | 10:51 |
| zyga | TIL, well, not T but recently, gparted cannot resize FAT16 | 10:52 |
| zyga | those small boot partitions, you need some hand holding and remaking from scratch to grow them | 10:52 |
| ijohnson | mvo: also could you do a sudo git merge on https://github.com/snapcore/snapd/pull/8659 ? | 10:52 |
| ijohnson | the test failures are unrelated | 10:52 |
| mup | PR #8659: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8659> | 10:52 |
| abeato | o/ is it possible to do 'snap run --gdb' on UC? It complains about gdb command not found | 10:59 |
| zyga | abeato: IIRC not at present | 10:59 |
| zyga | abeato: we discussed some work required for that but it's not scheduled | 11:00 |
| abeato | ok, thanks | 11:00 |
| mborzecki | an errand, back in 2-3h | 11:03 |
| mup | PR snapd#8659 closed: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8659> | 11:03 |
| === Eighth_Doctor is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Eighth_Doctor | ||
| pstolowski | re | 11:26 |
| mvo | pstolowski: thanks your view in 8531! great comments | 11:33 |
| zyga | hmm | 11:33 |
| zyga | that binfmt misc change is annoying | 11:33 |
| zyga | let me take it out of the equation | 11:33 |
| pstolowski | mvo: yw, glad you found it useful | 11:37 |
| mvo | pedronis: fwiw, I updated the vitality score pr, need to address the comemnts from pawel still though, feel free to have a look still | 11:43 |
| mup | PR snapd#8669 opened: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669> | 11:47 |
| zyga | https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test | 11:47 |
| mup | PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669> | 11:47 |
| zyga | mvo: ^ | 11:55 |
| pstolowski | cachio: hi, i commented on your nested.sh PR | 12:04 |
| cachio | pstolowski, thanks | 12:04 |
| xnox | pstolowski: hi | 12:13 |
| pstolowski | xnox: hey! i've sent you an email | 12:14 |
| zyga | mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/ | 12:17 |
| mup | PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656> | 12:17 |
| zyga | I think it's okay now | 12:17 |
| zyga | mvo: I have one tiny fix for you https://github.com/snapcore/snapd/pull/8670 -- debian packaging | 12:17 |
| mup | PR #8670: packaging: update sid packaging to match 16.04+ <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670> | 12:17 |
| zyga | ijohnson: do you want to review https://github.com/snapcore/snapd/pull/8566 -- it has +2 and I'd like to merge it to make progress | 12:18 |
| mup | PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566> | 12:18 |
| zyga | you marked yourself as a reviewer | 12:18 |
| mup | PR snapd#8670 opened: packaging: update sid packaging to match 16.04+ <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670> | 12:18 |
| zyga | but that was two weeks ago | 12:18 |
| ijohnson | zyga: go ahead without me, I started a review but didn't finish | 12:19 |
| zyga | ok | 12:19 |
| zyga | thanks :) | 12:19 |
| pedronis | ijohnson: I reviewed #8668, it probably could help if it go split at least in two, I comment as much. I need to go take of an errand, but happy to chat about it later if you have questions. I also think it should live under osutil/disks or something like that. | 12:24 |
| mup | PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 12:24 |
| pedronis | *take care of an errand | 12:24 |
| pedronis | mvo: notice that I commented on one of pstolowski considerations and your answer | 12:26 |
| * pedronis errands | 12:26 | |
| * zyga found a curious failure in session agent test, looking | 12:29 | |
| zyga | a daily reminder that spread -seed is your friend | 12:29 |
| mvo | zyga: thank you | 12:56 |
| * zyga breaks for a moment, for the next meeting | 13:49 | |
| cachio | zyga, please tell be what you mentioned about the spread user | 13:51 |
| ijohnson | pedronis: yes let me finish going through your comments, splitting out is probably a good idea and fine to do, I had forgotten I still had the exported mocking methods in the file, those are used in a followup | 13:51 |
| cachio | zyga, couldn't hear | 13:51 |
| mborzecki | re | 14:03 |
| zyga | cachio: in a moment, in another call | 14:04 |
| mvo | pedronis: what was the second comment you had about 8351? I will work on the seeding spread test now but forgot what comment 2 was | 14:07 |
| pedronis | mvo: we should block people from putting snapd itself in the list | 14:07 |
| pedronis | because we are not going to support making it less important than other things | 14:08 |
| mvo | pedronis: nice, will do | 14:09 |
| pedronis | ijohnson: I asked a question, and answered/made a suggestion to something else in that PR | 14:17 |
| pedronis | pstolowski: mvo's PR has landed (and maybe we got new enough kernels), #8533 needs master merge | 14:40 |
| mup | PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533> | 14:40 |
| pstolowski | pedronis: ok, thanks | 14:40 |
| zyga | 20 minutes until next call | 14:40 |
| zyga | mvo: I feel your pain :D | 14:40 |
| zyga | jdstrand: before the next call, do you have time to look at https://github.com/snapcore/snapd/pull/8578 | 14:43 |
| mup | PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578> | 14:43 |
| zyga | jdstrand: it's doing the same thing, just some naming changes | 14:43 |
| ijohnson | thanks pedronis sounds good | 14:43 |
| pedronis | ijohnson: made a suggestion based on your answer | 14:52 |
| mborzecki | pedronis: do you have a minute to talk abou the tweaks to keeping track of the current system? i implemented the changes we discussed and have some concerns that we may be overcomplicating it | 14:53 |
| ijohnson | thanks yes a Dev() method is fine too | 14:53 |
| ijohnson | also a quick review on https://github.com/snapcore/snapd/pull/8652 by anybody would be great :-) | 14:53 |
| mup | PR #8652: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8652> | 14:53 |
| pedronis | mvo: should I come to the next meeting? mborzecki wants to chat about something with me | 14:54 |
| jdstrand | zyga: before the next call? no. as mentioned yesterday when talking about the coordination email I sent, I will be getting to PR reviews today/tomorrow. I have a bunch of meetings so likely tomorrow | 14:54 |
| zyga | jdstrand: sure, no worries | 14:56 |
| jdstrand | ackk, mvo: you may not use sudo/su in a snap to drop to the snap_daemon user. those go through the pam stack. I outlined in https://forum.snapcraft.io/t/system-usernames/13386 with a link to code on how to do it. I believe there is something in the snapcraft realm that (cc cjp256) to make it even easier | 14:57 |
| jdstrand | one of the reasons why is that sudo and su use the pam stack. but you don't need pam for this | 14:58 |
| mup | PR snapd#8669 closed: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669> | 14:58 |
| ijohnson | thanks zyga for the review! | 14:59 |
| zyga | :) | 14:59 |
| zyga | I need to look at the snap routine portal info test | 14:59 |
| zyga | but | 14:59 |
| zyga | more meetings | 14:59 |
| mup | PR snapd#8652 closed: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8652> | 14:59 |
| mborzecki | pedronis: no worries, we can talk after your meeting | 15:04 |
| cachio | pstolowski, hey | 15:04 |
| cachio | nested is working again | 15:05 |
| cachio | cmatsuoka, told me the problem | 15:05 |
| === erich is now known as E_Eickmeyer | ||
| pstolowski | cachio: yay, that's great | 15:05 |
| cachio | pstolowski, I'll push in a bit | 15:05 |
| pstolowski | thx | 15:07 |
| zyga | woot | 15:11 |
| pedronis | mborzecki: I'm available now, standup? | 15:12 |
| mborzecki | pedronis: ok | 15:12 |
| pedronis | zyga: yes, I looked at your PR, we indeed should talk, also because if I understand that's not the final place you want to put those in, right? | 15:12 |
| pedronis | I mean the inhibit locks | 15:12 |
| zyga | pedronis: that's right, I'd like to grab the lock earlier, when we do the soft check and it succeeds | 15:13 |
| zyga | pedronis: I will look at it in detail tomorrow | 15:13 |
| zyga | my main question was where should this live | 15:13 |
| zyga | as there will be more code for a non-demo version (undo, all exit paths covered, tests) | 15:13 |
| cachio | pstolowski, I pushed the change | 15:15 |
| cachio | I already tested that | 15:16 |
| zyga | cachio: my question was about the external user | 15:16 |
| zyga | cachio: what's the reason for using a non-root user to log into the test device in spread, when using the ad-hoc backend | 15:16 |
| zyga | cachio: and a follow-up, if we could use regular root instead | 15:16 |
| cachio | zyga, I suppose that in core device we need a user | 15:17 |
| cachio | different than root | 15:17 |
| zyga | cachio: do you know why? | 15:17 |
| pstolowski | cachio: could you push this fix as a separate PR? i think this could land quickly if independent of your nested lib PR | 15:17 |
| cachio | I mean, if you can setup the password for root you can use root | 15:18 |
| cachio | zyga, but you need to specify the passwotd in the spread.yaml | 15:18 |
| zyga | cachio: and how is that different from the external user? we specify a password for it | 15:18 |
| zyga | cachio: I want to avoid the difference between ad-hoc and all the other backends | 15:19 |
| cachio | zyga, I mean, it is the same | 15:19 |
| zyga | cachio: because we get more and more session level things | 15:19 |
| zyga | and now we will get a new session that only occurs in a rarely-exercised test interaction | 15:19 |
| cachio | zyga, we could use root | 15:19 |
| cachio | zyga, I dindt' | 15:19 |
| cachio | didn't try with root in a core device but I dont see any restriction | 15:20 |
| cachio | zyga, let me make a try | 15:20 |
| zyga | cachio: cool, if we can do it that is preferable | 15:20 |
| zyga | cachio: if we cannot do it I will try to accommodate the external user instead | 15:20 |
| cachio | pstolowski, yes I can, but I'll need a bitr of time because there are few other thinks needed as well | 15:20 |
| cachio | zyga, ok | 15:21 |
| pstolowski | cachio: ah, if it is more than this 2 line change to apply it on master than maybe it's not worth it | 15:21 |
| cachio | pstolowski, I'll make a try after lunch | 15:22 |
| cachio | I need to review what is needed | 15:22 |
| zyga | ijohnson: hey, if you have a moment, I'd love to get a 2nd review for https://github.com/snapcore/snapd/pull/8633 -- I have some extra checks piled after that, which might help with flaky tests | 15:23 |
| mup | PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633> | 15:23 |
| zyga | I merged master to get some more fixes but it should otherwise pass (unless network issues show up) | 15:24 |
| zyga | mvo: I guess I could look at proposing prompting in to master | 15:26 |
| zyga | mvo: it needs considerable setup so it would be a distinct suite / backend perhaps | 15:26 |
| cachio | mvo, is it possible to add a password to root in ubuntu core? | 15:27 |
| cachio | zyga, ~ | 15:27 |
| zyga | home :) | 15:27 |
| ijohnson | zyga: sure I will take a look at it | 15:30 |
| zyga | ahhh | 15:32 |
| zyga | I just understood why we still see some failures | 15:33 |
| zyga | the failover fixes | 15:33 |
| zyga | they don't reload root's session systemd --user | 15:33 |
| zyga | I'll send a follow up shortly | 15:33 |
| zyga | the things we learn :) | 15:33 |
| pedronis | zyga: btw not urgent, but I also spent some time thinking about how to name the *-tool things. we should think a good time to talk about that | 15:34 |
| zyga | pedronis: I'm off tomorrow but we can try early next week | 15:34 |
| pedronis | ok | 15:34 |
| zyga | pedronis: or by email if it's low bandwidth | 15:34 |
| zyga | pedronis: I see the problem but I also love the -tool suffix is recognizable as our internal thing and it's short | 15:35 |
| pedronis | yes, I agree, we need recognizable or at last standing out names | 15:36 |
| pedronis | but the problem with -tool is that is not easy to know what to actually expect from them | 15:36 |
| pedronis | zyga: anyway this is a bit an area were it's easy to bikeshed, I might have to simply make a call about where to got at some point | 15:37 |
| zyga | pedronis: SURE | 15:38 |
| zyga | sure | 15:38 |
| zyga | :) | 15:38 |
| zyga | sorry, tabbed out of vm with the wrong key | 15:38 |
| pedronis | also we have snap-tool that being consistent should be called snapd-tool-tool | 15:39 |
| pedronis | :) | 15:39 |
| pedronis | anyway | 15:40 |
| zyga | pedronis: snapd-metatool | 15:41 |
| zyga | https://github.com/snapcore/snapd/pull/8671 should fix the cases that fail with errors like | 15:42 |
| mup | PR #8671: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671> | 15:42 |
| zyga | - Make snap "test-snapd-user-service-sockets" (unset) available to the system (Post http://0/v1/service-control: read unix @->/run/user/0/snapd-session-agent.socket: read: connection reset by peer) | 15:42 |
| mup | PR snapd#8671 opened: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671> | 15:42 |
| zyga | and with that I'd like to do some paperwork and EOD | 15:42 |
| zyga | cachio: ^ | 15:42 |
| zyga | ijohnson: I should probably move the defer.sh + tac trick into a helper | 15:44 |
| zyga | ijohnson: cleanup-tool (accepting any rename after we agree on new names) | 15:44 |
| mup | PR snapd#8654 closed: tests: test registration with serial-authority: [generic] <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8654> | 15:45 |
| zyga | this is so nice | 15:46 |
| zyga | I wanted to do my own model a few times | 15:46 |
| zyga | and now with the generic authority I can just really do that | 15:46 |
| zyga | and not feel like it's half baked | 15:46 |
| * cachio lunch | 15:48 | |
| * zyga EOWs | 15:50 | |
| zyga | see you on Monday everyone | 15:50 |
| pedronis | pstolowski: there seem to be some selinux failures showing up in #8533 | 16:03 |
| mup | PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533> | 16:03 |
| pstolowski | looking | 16:03 |
| mup | PR snapd#8672 opened: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672> | 16:09 |
| pstolowski | hmm that's weird, seems unrelated | 16:09 |
| mvo | cachio: adding a password to the root user is pretty hard, it's /etc/passwd,shadow are readonly so we would need to play bind-mount tricks | 16:10 |
| ackk | is it possible to share unix sockets via a content interface between snaps? | 16:20 |
| zyga | ackk: yes | 16:23 |
| zyga | ackk: it's also tested | 16:23 |
| zyga | ackk: and really works :) | 16:23 |
| ackk | zyga, lol. yeah I think I have misconfiguration on my side | 16:26 |
| ackk | thanks | 16:27 |
| zyga | :) | 16:27 |
| zyga | I'm EOD but can respond to questions with small alg | 16:27 |
| zyga | *lag | 16:27 |
| pstolowski | pedronis: ok, it's not obvious with selinux and the test alone against master didn't fail, i'll investigate tomorrow | 16:27 |
| zyga | pstolowski: looking | 16:28 |
| pstolowski | zyga: it's about #8533 | 16:29 |
| mup | PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533> | 16:29 |
| pstolowski | afk | 16:29 |
| zyga | ok, next week | 16:29 |
| pedronis | ijohnson: questions: https://github.com/snapcore/snapd/pull/8668#discussion_r425309127 | 17:27 |
| mup | PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 17:27 |
| mup | PR snapd#8671 closed: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8671> | 17:38 |
| mup | PR snapd#8633 closed: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8633> | 17:39 |
| ijohnson | pedronis: well iiuc from xnox is that what we are trying to do re: cross checking may be racy in that we are walking through entries in sysfs and udev, and "the-tool" currently doesn't wait for udev, it just waits for systemd-modules-load | 17:47 |
| ijohnson | I think maybe making the-tool run after udev would eliminate some of the raciness, in which case maybe it's okay to say it's deterministic, but I just don't honestly know | 17:48 |
| ijohnson | I have not seen it fail at any point mid way through the function with incomplete output fwiw, but that also isn't a good representation | 17:49 |
| pedronis | ijohnson: sorry, so we write a lot of code to avoid the raciness of lsblk but actually we have raciness anyway? | 17:54 |
| ijohnson | pedronis: well I don't know how much / what is racy | 17:55 |
| ijohnson | pedronis: so to combat not knowing I am just assuming it's racy and doing a best effort in the function | 17:56 |
| ijohnson | pedronis: if you'd rather I can just turn all of the "continue"s into return nil, err` but then there will be very many checks there and it feels all a bit fragile to me | 17:56 |
| pedronis | ijohnson: we should step back a bit I think | 17:57 |
| ijohnson | also fun fact the "unsafe encoding" actually comes from blkid, and the format is already deprecated yet udev continues to use it:-/ | 17:57 |
| ijohnson | or rather the "safe encoding" format comes from blkid | 17:57 |
| ijohnson | pedronis: ok, sure how should we proceed | 17:58 |
| ogra | snap changes | 18:04 |
| ogra | error: no changes found | 18:04 |
| ogra | is there any particular reason why we consider this an "error" ? | 18:04 |
| xnox | ijohnson: "currently doesn't wait for udev" => we did discuss this before, to order it after udev trigger is done.... | 18:07 |
| ijohnson | xnox: true but we didn't do this yet | 18:07 |
| ijohnson | xnox: so if we ordered the-tool to run after udev, would you expect things in /sys/dev/block/<maj:min>/uevent to change ? | 18:07 |
| xnox | ijohnson: what do you mean to change? | 18:08 |
| xnox | uevent is a kernel api file there. | 18:08 |
| xnox | it's dynamic write/read response api | 18:08 |
| ogra | is "udevadm settle" not existing anymore ? | 18:08 |
| ogra | (that used to block until udev is done) | 18:09 |
| xnox | ogra: why would you run that under systemd? | 18:09 |
| xnox | when there is a unit to order one after? | 18:09 |
| ijohnson | i.e. in order to implement mounting of a consistent set of partitions, we need to look at all of the devices with uevent files like that that match some filter, in this case the same major number | 18:09 |
| ogra | xnox, dunno ... probably because i'm from last century ;) | 18:09 |
| ijohnson | and I'm wondering if in the course of finding the set of devices that match the same major device number, would anything read from say the first uevent we look at change by the time we are done and look at the last uevent? | 18:10 |
| ijohnson | xnox: from the sounds of it you are saying it wouldn't change | 18:10 |
| xnox | ijohnson: i'm not sure, why you key onto the uevent file. but the /sys/dev/block/<maj:min> numbers are stable from device inception as seen in userspace from kernel. | 18:10 |
| zyga | https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test | 18:10 |
| mup | PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669> | 18:10 |
| ijohnson | sorry we're not keying on the uevent file, we just need to read that file | 18:10 |
| zyga | sorry, paste frommdauaf\t\ | 18:10 |
| zyga | keyBa | 18:10 |
| zyga | fghhh | 18:10 |
| zyga | lol | 18:11 |
| zyga | she loves backlit keys | 18:11 |
| ijohnson | really we glob /sys/dev/block/NUM:*/uevent and read all those files basically | 18:11 |
| zyga | (that was Lucy smashing keys) | 18:11 |
| xnox | ijohnson: yeah, reading it is fine. | 18:11 |
| ijohnson | xnox: ok, next question for each device that matches the filter above, we also run `udevadm --name <devname> --query property`, would you expect the output from that to change at all from the first device we query to the last one? | 18:12 |
| xnox | ijohnson: note, that will only have kerenl uevent details, not the udev uevent details. Normally one subscribes to the kernel netlink uevents and just listens the stream of them. | 18:12 |
| ijohnson | xnox: again, if we ordered after udev | 18:12 |
| xnox | or like subscribe to udevd's events, which have more information. | 18:12 |
| ijohnson | xnox: perhaps this would be easier if you just reviewed my PR and tell me if what I'm doing looks racy/non-racy | 18:13 |
| xnox | ijohnson: you are asking very low level questions, without the overall goal known. | 18:13 |
| ijohnson | xnox: see disks.go in https://github.com/snapcore/snapd/pull/8668/files#diff-6c8f8423221c269ce0465372c62a9751 | 18:13 |
| xnox | ijohnson: yeah. Normally, one uses udev apis and talks against it's database which is cached / consistent. | 18:13 |
| mup | PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 18:13 |
| ijohnson | xnox: the overall algorithm is, we have a mountpoint, how do we get 1) the mapper partition from that mountpoint, 2) the underlying encrypted partition from that mapper partition, 3) the disk that the encrypted partition comes from | 18:14 |
| xnox | sounds fun | 18:16 |
| xnox | ijohnson: and you don't want to use libudev bindings to query all of those things? cause it has like apis to query all the things, including "who is parent of this device", and again, and again, etc. | 18:17 |
| xnox | ijohnson: https://pkg.go.dev/github.com/farjump/go-libudev?tab=doc ? you rather have your own code, instead of using libudev1, right? | 18:17 |
| * xnox is kind of surprised that snapd doesn't already use libudev bindings => it's the fastest thing to query drives | 18:18 | |
| xnox | and is the ultimate source of truth. | 18:18 |
| ijohnson | xnox: last I heard is that we don't want cgo | 18:18 |
| ijohnson | if there are pure go bindings to libudev then probably that would help, but would it help by much? | 18:19 |
| xnox | there are pures ones too, but executing udevadm imho is safer than any custom native bindings. | 18:22 |
| xnox | ijohnson: you seem to do a lot of work walking all the things in /dev/ when you have all of that information in the udev database already. | 18:22 |
| ijohnson | xnox: is there a way that we can get udev params from device major minor directly ? | 18:22 |
| xnox | yes | 18:22 |
| ijohnson | how? | 18:22 |
| ijohnson | using udevadm directly I mean | 18:23 |
| ijohnson | not the libudev library | 18:23 |
| xnox | i normally, just do `udevadm info --export-db` which exports a consistent snapshot of _everything_ | 18:23 |
| xnox | and in there you have all the major:minor, all the DM_UUID, all the parents already pre-declared. | 18:23 |
| ijohnson | xnox is there a way you can get that in the --query output format though? | 18:23 |
| xnox | xnox: and you can ask udevadm to tell you which major:minor a given device is on | 18:23 |
| ijohnson | the format that udevadm outputs by default is slightly more complicated to parse than I would like | 18:24 |
| xnox | ijohnson: there is also this: | 18:25 |
| xnox | $ udevadm info --device-id-of-file /boot/ | 18:25 |
| xnox | 259:5 | 18:25 |
| xnox | which prints major:minor of the device a given file is on | 18:25 |
| xnox | such that if something is mounted, you can just query give me the device of the things. | 18:25 |
| ogra | geezs ... allthehiddenknobs ! | 18:25 |
| === KindTwo is now known as KindOne | ||
| === KindTwo is now known as KindOne | ||
| jdstrand | ackk: fyi, I updated "Dropping privileges" in https://forum.snapcraft.io/t/system-usernames/13386 to discuss the 'setpriv' command with an example snap: https://git.launchpad.net/~jdstrand/+git/test-setpriv/tree/snapcraft.yaml | 19:01 |
| jdstrand | ackk: with snapd 2.45 you can just use setpriv without LD_PRELOAD | 19:02 |
| jdstrand | ackk: hope that helps | 19:02 |
| ackk | jdstrand, oh, great, thanks! that will make things easier | 19:03 |
| jdstrand | cool :) | 19:04 |
| jdstrand | fyi emitorino ^ | 19:04 |
| ijohnson | jdstrand: why does setpriv in snapd 2.45+ work without LD_PRELOAD? | 19:06 |
| jdstrand | ijohnson: https://github.com/snapcore/snapd/pull/8220 | 19:07 |
| mup | PR #8220: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8220> | 19:07 |
| ijohnson | jdstrand: so does that mean that setpriv is doing the same thing as dnsmasq and is arguably a coding error? | 19:09 |
| jdstrand | ijohnson: yes | 19:09 |
| emitorino | jdstrand, ack | 19:10 |
| ijohnson | hmm jdstrand but couldn't upstream setpriv change to not do this and effectively break snaps that are relying on this behavior ? | 19:11 |
| mup | PR snapd#8673 opened: tests: enable degraded test on uc20 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8673> | 19:13 |
| jdstrand | ijohnson: sure, but that is true of anything that you stage when you change bases | 19:15 |
| jdstrand | ijohnson: fyi, this is the code: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/setpriv.c#n1035 | 19:19 |
| jdstrand | ijohnson: but actually, the only way they could break it would be to call setgroups(<something not 0>,) | 19:19 |
| jdstrand | ijohnson: ie, it doesn't matter what they do with the second argument (use the document NULL or something else), cause our filter no longer cares | 19:20 |
| jdstrand | documented* | 19:20 |
| jdstrand | (and it is safe that we don't care as per the PR discussion) | 19:21 |
| pedronis | ijohnson: so I'm looking at #8668, and even ignoring the raciness I think there's too much going on, given in the end we are going to call udevadm info, we don't need to use /sys/ that much, we can pass /sys paths to udevadm | 19:21 |
| mup | PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668> | 19:21 |
| pedronis | directly | 19:21 |
| ackk | jdstrand, does that mean that apps using initgroups/setgroups will also work without preload in 2.45? | 19:34 |
| jdstrand | ackk: no. this is about using setgroups(0, <something>) only | 19:37 |
| jdstrand | ackk: before we required setgroups(0, 0). dnsmasq didn't do that so we investigated and got comfortable with setgroups(0, <something>) | 19:38 |
| jdstrand | ackk: as it happens, that makes setpriv with --clear-groups also work | 19:38 |
| jdstrand | ackk: setgroups with a size of > 0 is not mediatable by the sandbox, since we can look at what is in the second argument | 19:39 |
| jdstrand | ackk: so, we can't differentiate between setgroups(1, 584788) and setgroups(1, 0) | 19:40 |
| jdstrand | meh | 19:40 |
| jdstrand | setgroups(1, [584788]) and setgroups(1, [0,1,1000,...]) | 19:40 |
| jdstrand | (we can't dereference a user space point at the time of mediation as a limitation of seccomp's design and implementation) | 19:41 |
| jdstrand | it should be possible to mediate setgroups when apparmor grows its syscall filtering, but that is not on a near term roadmap | 19:42 |
| mup | PR snapcraft#3122 closed: pluginhandler: make the build environment available to all steps <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122> | 19:43 |
| * cachio afk | 19:43 | |
| jdstrand | ackk: (and initgroups() is a glibc wrapper around the setgroups system call, so it has all the same issues) | 19:44 |
| jdstrand | ackk: erf | 19:45 |
| jdstrand | s/since we can look at.../since we can*not* look at.../ | 19:45 |
| jdstrand | ackk: hopefully I answered your question (sorry for the typos) | 19:46 |
| mup | PR snapcraft#3123 opened: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123> | 19:55 |
| zyga | heh | 20:16 |
| zyga | are we again waiting on travis? | 20:16 |
| zyga | https://github.com/snapcore/snapd/pull/8566 is stuck on travis | 20:16 |
| mup | PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566> | 20:16 |
| zyga | close/reopen to fix it, as usual | 20:17 |
| ijohnson | pedronis: part of the issue with the code tho is that udevadm just doesn't give us enough info for various bits | 20:30 |
| ijohnson | We still need to go to sysfs for various things unless there's more magical flags to udevadm that tell us what we need | 20:30 |
| pedronis | ijohnson: what doesn't it tell us? | 20:31 |
| ijohnson | (sorry internet cutting out here) | 20:32 |
| ijohnson | pedronis it doesn't have heirarchical info and doesn't know much about the dm devices | 20:32 |
| pedronis | ijohnson: well the hierarchical issues are kind of the same | 20:33 |
| pedronis | ijohnson: afaict it has the same info about dm devices that /sys has | 20:33 |
| ijohnson | pedronis how do you mean | 20:33 |
| ijohnson | I run udevadm on the dev mapper and it gives me very little info | 20:33 |
| ijohnson | But regardless I see your suggestion now, if you would rather me iterate with udevadm calling on the minor incremented I can do that, I don't see the advantage of that vs inspecting sysfs | 20:34 |
| pedronis | ijohnson: there is a lot of back and forth between reading /sys and udevadm, each of that needs an error check | 20:35 |
| pedronis | it's all very roundabout | 20:35 |
| pedronis | ijohnson: afaict dm name and dm uuid here are present as DM_UUID and DM_NAME | 20:36 |
| ijohnson | Well I mean yes all of this is extremely roundabout since there's not a complete set of info from udev or sysfs | 20:36 |
| pedronis | ijohnson: i still don't understand the complete info bit, they kind of have the same information | 20:36 |
| pedronis | in slightly different ways | 20:36 |
| ijohnson | pedronis those were defined for udev env vars for me before we started mounting as /dev/mapper, but now that we use that I don't get that info | 20:36 |
| ijohnson | Pedronis can you share what you see running udevadm where you get that info | 20:37 |
| ijohnson | Perhaps my uc20 install is buggy somehow | 20:37 |
| ijohnson | pedronis: this is what I see now with udevadm | 20:38 |
| ijohnson | https://www.irccloud.com/pastebin/xy1iR8UT/ | 20:38 |
| ijohnson | (my internet seems to be back so back at my computer now) | 20:38 |
| ijohnson | I get the same output if I try to access it by /dev/disk/by-label/ubuntu-data or by the major device number as well | 20:39 |
| pedronis | ijohnson: I was playing with a focal system, not uc20, I get a ton more info for dm devices | 20:41 |
| pedronis | strange | 20:41 |
| pedronis | I wonder what is different | 20:41 |
| ijohnson | pedronis: yes on my focal classic system I have more info too, but not in uc20 | 20:41 |
| ijohnson | could be in the options we use in creating the luks device, etc. | 20:42 |
| pedronis | I doubt that | 20:42 |
| pedronis | this is about the mapper info | 20:42 |
| ijohnson | well I mean I really don't know, what I know is that the code I have works with the info we currently have on uc20 and that there is probably about 1000 other ways we could do the same thing | 20:43 |
| pedronis | ijohnson: that code is full of continue, that is the part that worries me, I would really like to have as little things returning errors as possible | 20:44 |
| pedronis | to have to deal with | 20:44 |
| pedronis | and also even with less info is still seems a bit too roundabout | 20:45 |
| ijohnson | pedronis: I can try to refactor it to use udevadm calls with incremented minor numbers perhaps that will make it easier/have less `continue`/`return nil, err` but I think at the end of the day unless we have some kind of magical udevadm flag or config option or something that I don't know about we're going to have to get our hands dirty with this code | 20:45 |
| pedronis | ijohnson: like I don't think we need to do all the find DEVNAME then use the DEVNAME | 20:46 |
| pedronis | udevadm will happily take things under /sys/ | 20:46 |
| ijohnson | sure let me try to refactor that and see how much goes away | 20:47 |
| pedronis | ijohnson: do your partion all have ID_PART_ENTRY_DISK at least ? | 20:49 |
| ijohnson | pedronis: you mean physical partitions or dm partitions | 20:49 |
| ijohnson | dm partition does not have | 20:49 |
| pedronis | I mean the physical partitions | 20:49 |
| ijohnson | dm partition does not have ID_PART_ENTRY_DISK | 20:49 |
| ijohnson | the physical partitions all seem to have that prop though yes | 20:50 |
| pedronis | well, it's not a partition | 20:50 |
| pedronis | it has DEVTYPE=disk | 20:50 |
| pedronis | but it here it has a little bit more info | 20:51 |
| pedronis | but we can deal with that | 20:51 |
| ijohnson | ok, but yes all of the vda* have that defined | 20:51 |
| pedronis | anyway as I also remarked it doesn't make sense to find all the partition, especially when we just want to find if the mount points come from the same disk | 20:51 |
| pedronis | it seems we need two primitives diskFromMountPoint(path) -> major:minor | 20:52 |
| pedronis | diskIter(major:minor, func(udev props) (done bool)) or something like that | 20:53 |
| ijohnson | by diskIter you just mean a function which finds all the partitions for the specific disk? | 20:54 |
| pedronis | yes, and calls a function passing the result udevadm for each partition until the function is happy | 20:54 |
| pedronis | this are the internal primitives | 20:54 |
| pedronis | not what we expose as api to be clear | 20:54 |
| ijohnson | seems overly complicated to me, why do that over a for loop ? | 20:55 |
| mup | PR snapcraft#3124 opened: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124> | 20:55 |
| ijohnson | do we need different kinds of searches ? | 20:55 |
| pedronis | ijohnson: we need to mock both of those in this world | 20:55 |
| ijohnson | so I think what the impl will look like is diskfrommountpoint returns a wrapper object around the major/minor and doesn't do any searching yet and then the MountPointIsFromDisk and FindMatchingPartitionUUID functions actually do the searching, in the case of mount point from disk we may not actually need to do any searching | 20:57 |
| pedronis | ijohnson: yes, something like that | 20:58 |
| ijohnson | because MountPointIsFromDisk really just gets the dev maj:min for the mount point and compares | 20:58 |
| ijohnson | so we only have to do one search, which is for FindMatchingPartitionUUID | 20:58 |
| ijohnson | see originally I had different function names where you called one function and not two like this and it seems the refactor carried a bit too much implementation much the before the factor | 20:59 |
| pedronis | ijohnson: yes, I still think that the helper would make clearer what's constraints and responssibility, and also make mocking a bit more limited | 21:00 |
| ijohnson | right | 21:00 |
| ijohnson | alright well I will re-work this a little bit later today, need to go run an errand, perhaps we can sync on this shortly tomorrow after/before SU to see if I'm in a better direction then | 21:00 |
| pedronis | anyway looking at a focal system it seems the extra DM_ info comes from /lib/rules.d/55-dm.rules | 21:01 |
| pedronis | I wonder if they are not in core 20 or something they need is not there | 21:01 |
| pedronis | anyway this is the initramfs | 21:02 |
| pedronis | so maybe it has less rules anyway | 21:02 |
| ijohnson | pedronis: I have that file in /usr/lib/udev/rules.d/55-dm.rules from the core20 snap | 21:02 |
| ijohnson | let me quickly check the initramfs | 21:02 |
| ijohnson | hmm actually that same file is also in the initramfs | 21:03 |
| pedronis | interesting | 21:04 |
| pedronis | anyway as you said we are not waiting for udev, whatever that means | 21:04 |
| ijohnson | yes there's a systemd udev service that runs in the initramfws | 21:05 |
| ijohnson | we should make the-tool depend on it | 21:05 |
| ijohnson | but also I've been looking at userspace where it should also have run | 21:05 |
| pedronis | reading that rule files it sounds that we probably have only what we got from the initrd | 21:10 |
| pedronis | given that we carry the mount device through from it | 21:10 |
| pedronis | so userspace doesn't matter | 21:10 |
| pedronis | the question is just why that doesn't work in the initrd | 21:11 |
| pedronis | not our biggest concern anyway atm, but interesting/confusing | 21:11 |
| pedronis | ijohnson: actualy does _FLAG you have sounds like they have been turned off (maybe) | 21:13 |
| pedronis | *those _FLAG | 21:13 |
| ijohnson | pedronis what _FLAG ? | 21:16 |
| pedronis | ijohnson: you have things like: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 | 21:16 |
| pedronis | in your udevadm output | 21:16 |
| pedronis | it sounds like things are turned off | 21:16 |
| mup | PR snapd#8566 closed: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8566> | 21:54 |
| mup | PR snapcraft#3123 closed: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123> | 22:13 |
| mup | PR snapcraft#3124 closed: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124> | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!