[14:23] <Laney> ha;lp
[14:25] <Laney> I'm getting https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518
[14:25] <Laney> + grub-install --target=x86_64-efi --auto-nvram
[14:25] <Laney> Installing for x86_64-efi platform.
[14:25] <Laney> Could not delete variable: Invalid argument
[14:25] <Laney> grub-install: error: efibootmgr failed to register the boot entry: Block device required.
[14:25] <Laney> dpkg: error processing package grub-efi-amd64-signed (--configure):
[14:25] <Laney>  installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
[14:25] <Laney> etc
[14:27] <Laney> grub-install: info: executing efibootmgr </dev/null >/dev/null.
[14:27] <Laney> grub-install: info: executing efibootmgr -b 0000 -B.
[14:27] <Laney> Could not delete variable: Invalid argument
[14:27] <Laney> grub-install: error: efibootmgr failed to register the boot entry: Block device required.
[14:40] <apw> Laney, uff, cyphermox ^ 
[14:41] <apw> i asusme that is on upgrade of a grub2 ...
[14:41] <Laney> yeah grub-efi-amd64-signed
[14:41] <apw> cosmic ?
[14:41] <Laney> nope bionic
[14:41] <Laney>  *** 1.93.3+2.02-2ubuntu8.2 500
[14:41] <Laney>         500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
[14:43] <sforshee> LocutusOfBorg: we have a 4.17 kernel that's about ready for cosmic-release, except that it needs the virtualbox from -proposed to pass adt. Is that going to promote soon?
[14:43] <apw> Laney, what kernel are you runing
[14:43] <apw> when that fails
[14:44] <Laney> laney@nightingale> uname -a                                                                                     ~
[14:44] <Laney> Linux nightingale 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[14:44] <LocutusOfBorg> sforshee, I'm not the one blocking it
[14:44] <LocutusOfBorg> ask release team
[14:45] <apw> LocutusOfBorg, what is blocking it
[14:45] <LocutusOfBorg> when I requested to make xorg migrate, it was only blocked by qtbase
[14:45] <LocutusOfBorg> sorry, only blocked by xorg
[14:45] <LocutusOfBorg> now it is entangled with qtbase too
[14:46] <LocutusOfBorg> soooo, I don't care anymore
[20:02] <danieru98> jsalisbury, just finished testing your test kernel for bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783906 , i've posted an update there, long story short, you were right about reverting 2dc0b46b5ea3, that fixes that bug
[20:02] <danieru98> Should i mark that bug as fixed, or wait for any further updates?
[20:03] <jsalisbury> danieru98, wait for further updates.  I need to investigate that commit further to see if it can be simply reverted or needs to be fixed properly.
[20:04] <jsalisbury> danieru98, I'll probably need to ping the patch author, but I'll cc the bug report, so it gets all the email exchange.
[20:05] <danieru98> jsalisbury, okay, if you need me to test any other kernel feel free to just ask me. i'll keep my eyes on on that bug report for any updates
[20:10] <jsalisbury> danieru98, thanks!
[20:28] <tyhicks> sforshee: hey - for the /sys/class/net changes that I did for LXD, is it alright if I just "backport" them to ubuntu-unstable/master (currently 4.18 based) in order to land them in cosmic? I'd prefer to just ignore 4.15 for now
[20:29] <sforshee> tyhicks: yes however you may also want to backport to 4.17 (cosmic/master-next)
[20:30] <tyhicks> sforshee: oh, should I *only* do cosmic/master-next rather than unstable/master?
[20:31] <tyhicks> they cherry pick to unstable/master but I haven't tried cosmic/master-next yet
[20:33] <sforshee> should do both if it's easy, but if 4.17 is a big pain it's not that big of a deal
[20:38] <tyhicks> sforshee: I'll figure out how to do both but 4.17 is a pain because lxd still isn't working there due to the 55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
[20:39] <sforshee> tyhicks: that's odd, lxd adt tests pass on our 4.17 kernel
[20:40] <tyhicks> sforshee: sorry, I meant 4.18 is a pain
[20:40] <tyhicks> 4.17 doesn't have that commit
[20:41] <sforshee> tyhicks: that makes more sense
[20:41] <sforshee> oh yes the mknod thing ...
[20:42] <tyhicks> right
[20:42] <tyhicks> that never got reverted
[20:43] <sforshee> tyhicks: I'll check in with brauner about that tomorrow, we're gonna need a resolution on that soon
[20:43] <tyhicks> sforshee: I think there's a workaround in lxd now but it hasn't been released yet, IIRC
[20:44] <sforshee> yeah I had thought they had a fix for lxd
[20:44] <sforshee> but still problems because of systemd's everywhere without the fix
[20:44] <tyhicks> right
[20:44] <stgraber> 3.0.2 liblxc will have the workaround but yeah, won't necessarily help with the containers...
[20:45] <stgraber> I think the LXD snap should also already include all the needed bits for 4.18
[20:45] <stgraber> yeah, it does, so "snap install lxd" would get you a LXD with the needed liblxc bits
[20:45] <sforshee> stgraber: I do know that adt is failing for both lxc and lxd on 4.18, I haven't had ac hance to look into it yet
[20:48] <stgraber> yeah, that'll most likely fail until we push 3.0.2. We could cherry-pick just that one commit if that's the only thing that's blocking you with 4.18.
[20:48] <sforshee> oh no that's far from the only thing
[20:48] <stgraber> sforshee, tyhicks: btw, looks like the fix from jjohansen in bug 1780227 works fine, do you know if this is already in the relevant branches for the next round of SRUs?
[20:49] <jjohansen> stgraber: it is not, in yet
[20:50] <tyhicks> stgraber: not your problem but it looks like something in snappy is broke on 4.18 so I can't install the snap: https://paste.ubuntu.com/p/87rksWFPKk/ :)
[20:50] <tyhicks> I can work around this in my test kernel build so no worries
[20:51] <stgraber> tyhicks: sounds apparmor related, do you see a denial?
[20:51] <tyhicks> that's the first thing I looked for
[20:52] <tyhicks> hmm, there are some odd denials earlier in the logs
[20:52] <tyhicks> audit: type=1400 audit(1532983771.976:97): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=1422 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"
[20:52] <tyhicks> that sounds like a familiar issue
[20:54] <jdstrand> it is
[20:55] <jdstrand> jj fixed an issue that was a trace into a read
[20:55] <jdstrand> snapd isn't fixed yet
[20:56] <jdstrand> https://forum.snapcraft.io/t/custom-kernel-error-on-readlinkat-in-mount-namespace/6097/21
[20:56] <tyhicks> jdstrand: ack, thanks - don't escalate priorities for it on my behalf as I can work around it in order to get my testing done
[20:56] <jdstrand> tyhicks: you are on 4.18?
[20:56] <tyhicks> jdstrand: yes
[20:56] <jdstrand> yeah
[20:56] <jdstrand> that is that
[20:57] <tyhicks> alright, good to know
[20:58] <jdstrand> tyhicks: it is pretty high on the list, but not all the way up
[20:58] <jdstrand> tyhicks: if it comes time when you think it should be escalated, ping me
[20:59] <tyhicks> jdstrand: as sforshee mentioned above, there are several other things blocking 4.18 landing in cosmic but it is coming soon
[21:01] <tyhicks> dropping a bare ptrace rule into /etc/apparmor.d/usr.lib.snapd.snap-confine.real is going to let me do what I need to do
[21:04] <jdstrand> tyhicks: so will 'ptrace read peer=unconfined,' :)
[21:04] <jdstrand> I'll do a quick PR for that, and do the interrogating later