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

mupPR snapd#9661 opened: osutil/disks: add DiskFromName to get a disk using a udev name <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9661>00:53
mupPR snapd#9662 opened: bootloader/many: return error from ConfigFile and new* functions <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9662>02:04
mupPR snapd#9663 opened: tests/main/lxd/prep-snapd-in-lxd.sh: wait for archive DNS before apt things <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9663>02:19
mupPR snapd#9646 closed: tests/many: enable some uc20 tests, delete old unneeded tests or TODOs <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9646>06:55
mborzeckimorning06:59
zyga-x240good morning guy07:23
zyga-x240*guys07:23
zyga-x240my s key is still broken here ;D07:23
mborzeckizyga-x240: heya07:26
mupPR snapd#9649 closed: seed: make a shared seed system label validation helper <Simple 😃> <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9649>07:45
pstolowskimorning08:01
mborzeckipstolowski: hey08:08
mborzeckiweird, our 18.04 images have systemd-resolved running, resolv.conf points to 127.0.0.1:53 (so resolved), but there's no resolvectl in $PATH08:08
mborzeckiwth there's no resolvectl in 18.04?08:12
mborzeckiheh in systemd 239 they did s/systemd-resolve/resolvectl/08:15
mborzeckimvo: hey08:17
mvohey mborzecki and pstolowski08:17
mborzeckimvo: squash merged https://github.com/snapcore/snapd/pull/9649 can you cherry pick?08:24
mupPR #9649: seed: make a shared seed system label validation helper <Simple 😃> <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9649>08:24
mvomborzecki: correct08:25
mvomborzecki: is that an issue?08:27
mborzeckimvo: hm not a big one, but one of the tweaks was to allow only lowercase letters in system label so that we don't end up in a silly state when seed is on FAT08:28
mvomborzecki: oh and you would like to have cherry picked this tweak elesewhere too?08:31
mvomborzecki: oh, sorry, I think I misunderstood, I want to cherry pick this, yes :)08:32
mvomborzecki: and done08:33
zyga-x240hey mvo :)08:35
mborzeckimvo: thanks!08:35
mvogood morning zyga-x240 !08:35
mborzeckimvo: idk if i mentioned this, but it looks like the fonts issue may have been fixed in snapcraft https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/79 i found a PR https://github.com/snapcore/snapcraft/pull/3299 but it's 4.4+08:36
mupPR snapcraft#3299: extensions: configure hook for fonts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3299>08:36
mvomborzecki: oh, that is amazing08:40
mvomborzecki: I had hoped this would happen, really cool that it actually did08:40
mborzeckimvo: mhm, one nitpick, one needs to rebuild the snap using snapcraft 4.408:41
mvomborzecki: meh, right08:53
mvodid you guys also see "fsck-on-boot" failing on ubuntu-core-20 ?08:54
mvoit seems like a new thing08:54
mborzeckimvo:  did you build the image today?08:54
mborzeckimvo: and is the system encrypted?08:55
mupPR snapd#9651 closed: tests: fix basic20 test on arm devices <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9651>08:56
pedronismvo: Ian mentioned it in the SU notes09:03
mvopedronis: thank you!09:04
mvopedronis: in 9659 you suggest to move KenrelCommandLineSplit, what pkg do you have in mind? boot?09:05
mvopedronis: or soemthing like boot/{k,}cmdline?09:05
pedronismvo: osutil seems also fine09:06
mvopedronis: cool, I have a look09:06
mvopedronis: updated 965909:14
mborzeckimvo: are you looking into fsck-on-boot test?09:14
mvomborzecki: I was just booting a qemu to poke around09:14
mvomborzecki: not sure how far I get, I let you know if I need to give up09:15
pedronismvo: I put it back into my queue09:16
mvota09:18
mborzeckiduh, wth? `Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 16829 (unattended-upgr)`09:41
mvomborzecki: where do you see that?09:41
mvomborzecki: fwiw, we should probably disable u-u09:41
mvomborzecki: fwiw^2 - modern apt will retry locking but iirc only when used interactively :/09:42
mborzeckimvo: 20.0409:48
mborzeckimvo: yeah, unattended-upgrades service is running in a 20.04 image we use09:48
pedroniszyga-x240: I did a pass now on #9546, I can likely take care of some of my own comments when I have a moment  but one is a question09:55
mupPR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>09:55
zyga-x240pedronis: woot, thank you09:55
zyga-x240I will look at the comment shortly09:55
pedronisthx09:55
mborzeckimvo: huh, unattended-upgrades is running in 18.04 images too09:57
mupPR snapd#9653 closed: strutil/shlex,osutil/udev/netlink: minimally import go-check <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9653>10:11
mupPR snapd#9664 opened: spread: disable unattended-upgrades on ubuntu <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9664>10:11
niemeyerMorning all10:16
niemeyerWould anyone recall if we have any task/change in snapd that is transient, in the sense it's supposed to run only during the lifetime of the current snapd execution?10:16
niemeyerI'm guessing the answer is no, since tasks precisely overcome the fact that we want the task to be accomplished no matter how many times we restart, but checking just in case10:17
zyga-x240niemeyer: I don't think we have that10:19
pedronisniemeyer: no, indeed not so far, the closest would be some of the hot plug tasks, but they are stil persistent and it's useful but we need to be a bit careful with them10:20
niemeyerAh, interesting.. careful in what sense?10:20
pedroniswe need to make sure that we run them in order, even if they are in different changes. that is very unusual, for most other tasks the conflict logic avoid that kind of issue at all10:21
niemeyerInteresting indeed10:21
pedronisotherwise you might end up trying to add and remove a slot at the same time10:22
niemeyerI see, thanks for the details10:22
mvomborzecki: fwiw, no progress on "fsck-on-boot" not running but core20 was stuck in manual recore10:34
mvomborzecki: manual review, I unblocked it and will run again once the store has published it10:34
mvomborzecki: it looks legit though, there is really no fsck happening now10:35
mvomborzecki: but the fsck.vfat binary is still there10:35
mborzeckimvo: maybe there is but not clearing the dirty bit?10:35
pedroniszyga-x240: I commented on my comment, not sure what I'm saying there makes sense though10:40
mborzeckipstolowski: can you take a look at https://github.com/snapcore/snapd/pull/9556 ?10:53
mupPR #9556: tests: testing new fedora 33 image <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>10:53
pstolowskisure10:53
pedronismvo: mborzecki: I commeted again on #965911:00
mupPR #9659: strutil/cmdline.go: add GetKernelCommandLineKeyValue <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9659>11:00
pedronis*commented11:00
mvopedronis: looking11:01
pstolowskimborzecki: shouldn't we drop fedora-31-64 from spread.yaml per my existing comment?11:08
niemeyerAnother trivial: in hookstate, this comment is bogus:11:09
niemeyer // check if we're a hook task, probably not needed but let's take extra care11:09
niemeyerIt necessarily must check if it's a run-hook task, otherwise it'd be evaluating an unknown task11:10
niemeyer(the predicate runs for all tasks)11:10
mborzeckipstolowski: it's not EOL yet11:12
mborzeckihm let me double check actually11:13
mborzeckipstolowski: mhm, it'll eol in a couple of feeks11:13
pstolowskimborzecki: i misread Sergio's PR desc, it says 'Also fedora 31 is not executed anymore, it remains manual' i11:14
pstolowskimborzecki:  makes sense to keep it for a while then11:14
mborzeckiyup11:14
pstolowskimborzecki: but.. i confused about all the dropping for -fedora-31-* in this PR11:16
pstolowski*i'm*11:16
mvomborzecki: so we got a new kernel yesterday with new initrd, I wonder if that could have broken the fsck, I see no systemd-fsck message for ubuntu-seed in journalctl11:17
mvomborzecki: ohhh, I think it might be PR#8 from core-initrd ... we now bind mount /run/mnt/ubuntu-seed so *maybe* this triggers it11:19
* mvo looks a bit deeper11:20
mborzeckipstolowski: otoh, f31 is eol on 24.11, so maybe we should just drop it now11:29
pstolowskimborzecki: +1,11:31
mupPR snapd#9665 opened: tests: unmount /boot/efi in fsck-on-boot test <âš  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9665>11:51
pstolowskimborzecki: are you updating that PR?11:55
mborzeckipstolowski: yeah, i pushed an update11:56
pedronisniemeyer: thx, I took note of that12:05
mborzeckimvo: hm i see that the bit is set in a vm too12:08
mborzeckimvo: so the question is, are we even looking at the right bit?12:08
mvomborzecki: maybe not, not sure, but my PR above fixes the issue12:08
mvomborzecki: how did you test it in the vm? spread with qemu cannot run core20 currently :/ ?12:09
mborzeckimvo: i built the image myself and booted it12:09
mvook12:13
mupPR snapd#9642 closed: boot: add scaffolding for "fde-setup" hook support for sealing <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9642>12:16
niemeyerpedronis: Thanks! No big deal obviously..12:46
niemeyerIt just got my attention because I went looking into the predicates to see if something else might be filtering them up12:47
pstolowskimvo: #9627 has +1 from Alex; i can prepare followup for other interfaces that need access to tty12:51
mupPR #9627: interfaces/raw_usb: allow read access to /proc/tty/drivers (LP: #1890365) <Needs security review> <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/9627>12:51
cachiombeierl, hey13:05
cachiomborzecki, hey13:05
mborzeckicachio: hey, what's up?13:06
cachioI see this error in open suse13:06
cachio+ su -c 'SNAPPY_USE_STAGING_STORE=0 snap prepare-image --channel edge --snap test-snapd-tools /home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/developer1-pc.model /tmp/root' test13:06
cachioerror: cannot fetch and check prerequisites for the model assertion: circular assertions are not expected: account (testrootorg)13:06
cachiopreparing image13:06
cachiodid you notice that?13:06
* mbeierl thinks I need a new nick :) Sorry mborzecki for being a second "mb<tab>"!13:06
cachioit just fails in opensuse13:06
mborzeckicachio: no clue, but does not look like anything opensuse related13:10
pedronismborzecki: cachio: something broke in the build and we don't include the test key anymore ?13:13
pedronisthat would be something that provokes that13:14
mborzeckipedronis: hm maybe some option is being ignored and testkeys tags does not get set during build13:14
cachiosystems: [-ubuntu-core-*, -fedora-*, -opensuse-*, -arch-*, -amazon-*, -centos-*]13:14
mborzeckilooks like i should investigate13:14
cachiothe test should not be executed on opensuse13:15
ijohnsonmorning folks13:15
cachiogood morning13:15
ijohnsonhey cachio13:15
cachiomborzecki, foud the problem13:17
ijohnsonanybody look into the core/fsck-on-boot spread test yet ?13:17
ijohnsonah I see mvo found the issue in 966513:17
cachioijohnson, you mean #9655 right?13:19
mupPR #9655: tests: fix fsck on boot on arm devices <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9655>13:19
ijohnsoncachio: no core/fsck-on-boot started failing all the time yesterday13:20
ijohnsonmvo fixed the issue in #9665 it seems13:20
mupPR #9665: tests: unmount /boot/efi in fsck-on-boot test <âš  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9665>13:20
cachioijohnson, ahh, It was not me :)13:20
ijohnsoncachio: but also please take a look at that PR, as I think you will want to handle that change in your PR13:20
mupPR snapd#9665 closed: tests: unmount /boot/efi in fsck-on-boot test <âš  Critical> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9665>13:22
cachioijohnson, yes13:22
cachiodone13:22
ijohnsonthanks cachio13:24
cachioijohnson, I think I need to update that for arm because /boot/efi does not exist13:25
ijohnsoncachio: precisely13:25
niemeyerpedronis: Another nit for an eventual lazy afternoon: the hookstate manager is currently breaking through the overlord abstraction and being manipulated directly by the daemon. Instead, we should extend the StateManager API with something like a Halt early signal, which would replace GracefullyWaitForHooks in a general way13:31
ijohnsonpedronis: I responded to #9662, hopefully it makes sense, if not we should chat today ideally because this will block further prs on supporting lk13:33
mupPR #9662: bootloader/many: return error from ConfigFile and new* functions <UC20> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9662>13:33
pedronisijohnson: it sounds like we need to chat, because you explained the problem, but is still unclear that the content of the PR is the right path13:43
ijohnsonpedronis: ok sorry I just left another comment13:43
ijohnsonpedronis: when are you free today?13:43
ijohnsonI guess I could chat now before SU13:44
pedronisijohnson: let's chat now13:45
ijohnsonk, joining now13:45
mvopstolowski: sounds great, thank you13:51
mupPR snapd#9627 closed: interfaces/raw_usb: allow read access to /proc/tty/drivers (LP: #1890365) <Needs security review> <Created by oSoMoN> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9627>13:57
zyga-x240pedronis: I eod at 16:00 today, I can send some follow ups then14:07
pedroniszyga-x240: ok, thx, I pushed a merge fixing conflicts btw14:31
zyga-x240pedronis: thank you14:33
mupPR snapd#9666 opened: tests: updated the systems to run prepare-image-grub test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9666>14:37
pedroniscachio: mborzecki: ^ but we don't support explicitly building images on those other distros, that was the reason of the skipping14:41
pedronisijohnson: ^14:42
cachiopedronis, ok, so I'll disable them and add a tag14:42
ijohnsonpedronis: yeah I was wondering the same14:42
mupPR snapd#9667 opened: devicestate: implement boot.HasFDESetupHook <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>14:42
ijohnsonpedronis: IMHO if it works let's just run it there anyways14:42
ijohnsonif or when it breaks we can decide whether it's worth it to fix that or not I think14:42
ijohnsonbut that's just me14:43
pedronisijohnson: well, the issue is that is not an interesting test from tht pov14:43
pedronisbecaused it's only prepare-image14:43
pedronisnot ubuntu-image14:43
ijohnsonI guess I'm just of the opinion if it passes on that system why not let it run there14:43
pedronisso it passing doesn't mean much full-picture-wise14:43
pedronisijohnson: because tests take time14:43
pedronisand those time adds up14:43
pedronisand also see othe remark14:44
pedronisas is it doesn't prove or disproves anything14:44
ijohnsonsure then just disable it for those other systems14:44
ijohnsonI don't feel strongly enough about it to argue otherwise14:44
* ijohnson perhaps has just gotten too used to the fact that tests take ages and are never green anyways to not be worried about additional time for tests to execute14:45
mupPR snapd#9668 opened: bootloader: use ForGadget when installing boot config (2.48) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9668>14:52
mborzeckifwiw, i'm using ubuntu-image which runs snap prepare-image on arch, so we get at least some testing on other distros here14:52
=== King_InuYasha is now known as Conan_Kudo
=== Conan_Kudo is now known as King_InuYasha
cachioijohnson, I updated the change15:15
cachioincluded 2 other tests15:15
* cachio lunch15:25
ijohnsoncachio: approved15:26
pedronismvo: some comments/questions in #966715:30
mupPR #9667: devicestate: implement boot.HasFDESetupHook <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>15:30
mupPR snapd#9669 opened: [RFC] interfaces: allow read access to /proc/tty/drivers to modem-manager and ppp <Needs security review> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9669>15:32
mvopedronis: thanks! I will look in a wee bit15:45
zygapedronis I'm grabbing coffee and looking at that branch in a moment15:49
pedroniszyga: ok, about to be in a meeting16:01
zygaok16:01
=== Ringtailed_Fox is now known as RingtailedFox
ijohnsonpedronis: is it a strong property that we want to error if snapd_recovery_mode is specified multiple times on the kernel command line we error in the initramfs ? that is the way it currently works with the code originally written by mborzecki in boot/cmdline.go, but if we don't have such strong checking we can simplify the code somewhat with the (imho) reasonable assumption that later values override earlier ones17:10
ijohnson(and same for snapd_recovery_label)17:11
pedronisijohnson: you need to double check but I think that's the kernel behavior as well https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html ?17:35
ijohnsonpedronis: which behavior is the same as the kernel ?17:36
pedronisijohnson: last wins17:36
ijohnsonpedronis: ah ok good17:36
pedronisotoh when we measure it, it won't matter much anyway17:36
pedronisor matter a lot in the sense that it won't both ;)17:36
ijohnsonI mean it's kinda a nice property that if you define it multiple times uc20 freaks out at you for board enablement folks17:37
ijohnsonbut it's also cumbersome to code17:37
ijohnsonright yes in the measurement case it doesn't really matter17:37
pedronisijohnson: though in my proposal it might be not too hard to code for either behavior, it would need to be a flag though17:40
ijohnsonpedronis: well it seems the kernel is a little different, for known parameters it will invoke callbacks for each parameter, so in the case of duplicated parameters it will call the callback twice, first with the first value and then again with the second value17:40
ijohnsonbut for things like snapd_recovery_mode that the kernel doesn't care about, then it essentially doesn't matter17:40
ijohnsonpedronis: yeah I thought maybe to handle it we could return a `map[string][]string` but it makes some other usages more complicated17:41
ijohnsonI think for our purposes since we are not the kernel, it's ok to just let the last one win17:41
mupPR snapd#9668 closed: bootloader: use ForGadget when installing boot config (2.48) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9668>18:08
=== ijohnson is now known as ijohnson|lunch
cachioijohnson|lunch, is it ok #9650 ?19:54
mupPR #9650: tests: skip boot state test on arm devices <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9650>19:54
cachioit is ready for merge19:55
mupPR snapd#9666 closed: tests: updated the systems to run prepare-image-grub test <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9666>20:04
ijohnson|lunchcachio approved thanks20:04
cachioijohnson|lunch, yaw20:04
mupPR snapd#9650 closed: tests: skip boot state test on arm devices <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9650>20:09
pedronisijohnson|lunch: do you need input on anything right now?20:09
=== ijohnson|lunch is now known as ijohnson
ijohnsonpedronis: no, not really but just to be clear it's okay to not fatally error if there is a duplicated kernel command line parameter for snapd_recovery_{mode,system} ?20:13
pedronisijohnson: it's ok (we can always change it again), I think the most affected case would be playing with it and then turning on encryption later, but we don't really support playing with the command line that much for relevant systems atm20:14
ijohnsonright20:14
ijohnsonok, sounds good that's what I implemented and was about to push up changes for20:15
=== diddledan_ is now known as diddledan
mupPR snapcraft#3380 opened: snap packaging: fix broken path check when copying local icon <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3380>22:34
mupPR snapd#9655 closed: tests: fix fsck on boot on arm devices <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9655>22:39

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