[00:45] <mwhudson> why would i be getting messages like
[00:45] <mwhudson> qemu-system-x86_64: failed to initialize KVM: Cannot allocate memory
[00:46] <mwhudson> more often in cosmic?
[00:46] <mwhudson> i have a lot of ram free now
[00:46] <tsimonq2> mwhudson: What really grinds my gears about that is that when I go back and adjust the RAM but don't touch anything else, it won't let me install because of the storage being incorrect...
[00:46] <tsimonq2> ^_^
[00:47] <mwhudson> tsimonq2: hmm?
[00:48] <tsimonq2> mwhudson: I've encountered that before, but for me it's always been faulty.
=== sergiusens_ is now known as sergiusens
[04:03] <cpaelzer> mwhudson: I'd not know of a particular reason why you'd fail more often to allocate memory
[04:04] <cpaelzer> mwhudson: for me - personally - I had to realize that new chrome and KDE seems to hog a bit more ram than in the past
[08:28] <Laney> looks like mariadb-server-10.1 is hanging somewhere in postinst on the arm64 autopkgtests
[08:32] <Laney> LocutusOfBorg: that's your upload - bug #1785767
[08:32] <ubottu> bug 1785767 in mariadb-10.1 (Ubuntu) "1:10.1.34-1 hanging in postinst of mariadb-server-10.1 on arm64" [Undecided,New] https://launchpad.net/bugs/1785767
[08:33] <Laney> I'm going to try to do something to make it fail instead of going around forever
=== mwsb1 is now known as mwsb
[12:08] <scientes> kvm doesn't bring up a display anymore
[12:08] <scientes> sudo kvm -m 4096M -drive format=raw,file=/dev/sdd -boot menu=on -cdrom /home/shawn/Downloads/debian-testing-amd64-DVD-1.iso
[12:08] <scientes> [sudo] password for shawn:
[12:08] <scientes> No protocol specified
[12:08] <scientes> Unable to init server: Could not connect: Connection refused
[12:08] <scientes> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
[12:08] <scientes> gtk initialization failed
=== sergiusens_ is now known as sergiusens
[12:09] <TJ-> scientes: check the host's /proc/cpuinfo flags: field for vmx
[12:10] <TJ-> scientes: has it got flipped off in the PC firmware setup?
[12:10] <scientes> TJ-, no it works, it worked before i upgraded
[12:10] <scientes> and i'm running amd
[12:10] <TJ-> scientes: what does "kvm-ok" report?
[12:11] <scientes> $ kvm-ok
[12:11] <scientes> INFO: /dev/kvm exists
[12:11] <scientes> KVM acceleration can be used
[12:11] <TJ-> which kernel is this with?
[12:11] <scientes> 4.17.0-6-generic
[12:11] <scientes> amd64
[12:11] <scientes> i think kvm works
[12:12] <scientes> the problem is bringing up the graphics
[12:12] <scientes> like qemu-system-x86_64 changed its defaults
[12:12] <TJ-> scientes: ahh, OK, the vmx might be just a warning since it's not an Intel CPU... weird though, you'd think it's know the difference between Intel and AMD
[12:13] <TJ-> scientes: "connection refused" - check /var/log/auth.log
[12:13] <TJ-> scientes: I wonder if it's an apparmor profile issue, dmesg/kern.log/syslog might give a clue
[12:14] <scientes> nothing in dmesg
[12:14] <scientes> journalctl -f => nothing
[12:15] <TJ-> scientes: the mention of "protocol" makes me think it may simply not know how to connect to the hypervisor.
[12:17] <TJ-> scientes: I get a different warning but the GUI console starts "qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]"
[12:18] <TJ-> scientes: try runinng it under strace, as in sudo strace -fe trace=file qemu-system-x86_64 ... |& tee /tmp/kvm.log
[12:18] <scientes> virt-manager seems to work
[12:18] <scientes> so again I think its a graphics issue
[12:22] <TJ-> scientes: try "-display sdl" (I think the default is "-display gtk"
[12:22] <scientes> qemu-system-x86_64: Display 'sdl' is not available.
[12:22] <scientes> yeah i tried that earlier
[12:22] <scientes> i managed to work around the problem with virt-manager
[12:25] <TJ-> scientes: does "-display gtk" cause the same issue?
[12:25] <scientes> yes
[12:26] <TJ-> scientes: ahhh, apparently this is because you're running as root (sudo) and the root user doesn't have access to the display any more. Is this a wayland session by any chance?
[12:26] <scientes> yes
[12:26] <scientes> but it worked in wayland before
[12:26] <scientes> maybe cause it was dsl
[12:26] <scientes> *sdl
[12:27] <scientes> it worked in Bionic
[12:28] <TJ-> scientes: possibly it needs the xhost workaround
[12:29] <scientes> hmm guess i need that the virt-manager workaround didn't work cause i had to forward the usb stick
[12:29] <scientes> which must be buggy
[12:30] <scientes> instead of just the raw /dev/sdd
[12:30] <scientes> or maybe Ill just install normally
[12:36] <cpaelzer> TJ as you found vmx/svm warnings are just not-the-cpu
[12:36] <cpaelzer> yes it could detect a lot, but then users would need to set one or the other
[12:36] <cpaelzer> the current form has the annoying warning but works without touching the cpu definitions
[12:37] <cpaelzer> and yes sdl->gtk is a cosmic and later thing
[12:37] <scientes> cpaelzer, how do i install sdl for qemu?
[12:37] <scientes> do i need to build from source?
[12:38] <cpaelzer> it was a switch from sdl to gtk backend
[12:38] <cpaelzer> so sdl isn't configured anymore atm
[12:38] <cpaelzer> sdl1 is supposed to fade out
[12:38] <scientes> but it worked!
[12:38] <cpaelzer> and sdl2 had too much issues
[12:39] <TJ-> cpaelzer: is there a workaround for this running-as-root issue? or should the user be member of an additional group like "disks" to ensure kvm can operate unprivileged?
[12:39] <cpaelzer> I need to read the backlog what your problem is, juts a sec ...
[12:40] <TJ-> I recall in the dim distant past for kvm unprivileged adding groups disk plugdev cdrom dialout
[12:40] <cpaelzer> that depends on what you are expecteing to have qemu do for you
[12:40] <cpaelzer> at the very least kvm to use HW virt
[12:41] <cpaelzer> cdrom obviously if you want to install from CD and so on ...
[12:41] <TJ-> cpaelzer: of course, in this case scientes is accessing raw /dev/sdd so the process would need r/w access to that
[12:41] <cpaelzer> yep
[12:42] <cpaelzer> but in general if sudo is wanted, it is not stripping the DISPLAY
[12:43] <cpaelzer> "sudo xeyes" (major Prod workload :-) ) - works fine
[12:43] <scientes> I'm just installing =nographic like a caveman
[12:43] <scientes> nah that doesn't seem to work
[12:43] <scientes> with the debian testing cd
[12:45] <scientes> virt-manager won't load /dev/sdd either
[12:45] <cpaelzer> grml - no graphical Cosmic around to try
[12:45] <cpaelzer> :-/
[12:46] <cpaelzer> still maybe just needs xhost tweaks or such
[12:46] <cpaelzer> but without retry I can't say for sure
[12:48] <TJ-> scientes: is the user a member of the libvirtd group?
[12:48] <scientes> i don't have that group
[12:49] <scientes> libvirt:x:130:shawn
[12:49] <scientes> libvirt-qemu:x:64055:libvirt-qemu
[12:49] <cpaelzer> in new installs the group is only libvirt I think
[12:50] <cpaelzer> and on upgrades it is libvirtd and libvirt on the same GID
=== schout-it_ is now known as schout-it
=== jamespage is now known as JamesPage
=== JamesPage is now known as jamespage
[15:16] <kyrofa> Hey slangasek, continuing our discussion from yesterday (snaps in armhf autopkgtest), adding fuse got us further, but now we have apparmor issues: https://pastebin.ubuntu.com/p/pVtNGPnfpq/ . Do you know what the host OS is for these tests?
[15:20] <kyrofa> slangasek, also, https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development/tree/tools/autopkgtest-build-lxd doesn't look like it, but any chance this is a privileged container?
[15:23] <kyrofa> Or confined in some other way?
[15:26] <slangasek> kyrofa: host OS is an LTS, it's probably still xenial rather than bionic; I don't know how privileged the containers are, that's something I would have to look at - I don't think we're doing any handling of lxd profiles the way launchpad does
[15:43] <kyrofa> slangasek, huh, xenial should be fine. If they're unprivileged that should also be fine, but sounds like their being privileged would be an issue
[15:43] <slangasek> oh interesting
[16:02] <kyrofa> slangasek, I'll try to see if I can duplicate on my rpi
[16:05] <jamespage> slangasek: hullo - do you think it might be possible to get the python 3.7 in bionic universe to a more maintained status?  there is a bit of a thread going on upstream in openstack about python 3.7 gating for changes, but the  gates always stick on our LTS'es - which currently means python 3.6
[16:06] <jamespage> that would also help our interim release work up until 20.04 which I guess we would like to not include python 3.6 :-0
[16:07] <slangasek> jamespage: er, I think that's square peg, round hole; we should figure out how to get openstack to where it's able to CI against latest python3 without having to SRU newer pythons into an LTS
[16:08] <slangasek> I expect python3.8 will happen in 20.04 kind of timeframe, and we don't want to be SRUing that back to 18.04 either
[20:20] <ahasenack> any idea what is going on here? https://pastebin.ubuntu.com/p/CBvNgDmp9d/
[20:20] <ahasenack> the python3-sss.install file specifies certain directories and files
[20:21] <ahasenack> but what ends up in the package is something else, mangled
[20:21] <ahasenack> usr/lib/python3*/site-packages/pysss.so becomse usr/lib/python3/dist-packages/pysss.cpython-36m-x86_64-linux-gnu.so
[20:21] <ahasenack> and the build doesn't fail, not even due to the different directory (site-packages vs dist-packages)
[20:22] <ahasenack> we have a delta with debian (this is the sssd package) that changes {site,dist}-packages/ in *.install files to *-packages/
[20:22] <ahasenack> but without that delta, the build still works, and both packages (with and without the delta) end up with the mangled .so file
[20:24] <TJ-> ahasenack: "36m" looks like a shell ANSI colour code, and the rest is an arch triplet
[20:24] <TJ-> ahasenack: someone typed a [ or ] instead of { or }
[20:25] <ahasenack> it's the same in bionic
[20:29] <ahasenack> import pysss and pysss_murmur works, so that mangling is expected
[20:29] <ahasenack> or rather, coped with
[20:41] <TJ-> ahasenack: interestingly: ./build/ltmain.sh:498:        tc_blue='';  tc_cyan='36m'
[20:41] <ahasenack> odd
[20:42] <TJ-> might be a red-herring but I suspect there's a shell script/Makefile with a typo
[20:43] <TJ-> because Makefiles use @TRIPLET@ as a replacable for the postinst scripts, as well
[20:44] <ahasenack> run this and you will likely find tons of such files: find /usr/lib/python3/ -name '*.so'
[20:46] <TJ-> ahasenack: none... on Bionic
[20:46] <ahasenack> I have a ton
[20:46] <ahasenack> like
[20:46] <ahasenack> python3-systemd: /usr/lib/python3/dist-packages/systemd/_journal.cpython-36m-x86_64-linux-gnu.so
[20:46] <TJ-> ahaha,I mistyped as .do not .so, yes I see some now :)
[20:46] <ahasenack> ok :)
[20:47] <TJ-> is there a bug in the python build tooling? that really looks strange
[20:47] <ahasenack> don't know
[20:48] <ahasenack> I've heard the term "colouring" related to architectures before
[20:48] <ahasenack> hardware details, that kind of thing
[20:48] <ahasenack> I have to run, will check back later
[20:49] <TJ-> ahhh, makes sense, but can't find the 36m part documented
[20:56] <TJ-> ahasenack: solved! read the README.rst for the dh-python package, the output of pybuild apparently when set to site-packages is translated to dist-packages
[20:56] <TJ-> ahasenack: also it sets the cpython-36m-$TRIPLET into the name
[21:01] <kyrofa> slangasek, at long last, I found my rpi, got ubuntu core on there, installed lxd, created an instance... and snaps work fine on it
[21:01] <kyrofa> I can't seem to duplicate what we see in autopkgtests
[21:19] <kyrofa> slangasek, if I create a privileged container, snaps don't install but with different errors: https://pastebin.ubuntu.com/p/3QZkty2chS/
[21:20] <kyrofa> slangasek, I'm out of ideas regarding what's wrong without shell access. Something is odd with apparmor in the armhf autopkgtest runners
[21:22] <slangasek> kyrofa: do you want a dump of the container config, to try to replicate?
[21:22] <kyrofa> slangasek, wouldn't hurt
[21:25] <kyrofa> slangasek, while we continue digging into this, I'd like to land that test suite. It runs everywhere except armhf, and I'd obviously like to get it running there. Is that worth setting up an ignore, you think? Or should I disable those tests for armhf?
[21:27] <slangasek> kyrofa: short-term, I think the best approach that doesn't require us to use a huge hammer on the Ubuntu side and cause you to lose all CI gating for armhf, nor require you to hard-code an architecture exclusion list, is to mark that particular test as isolation-machine
[21:28] <slangasek> kyrofa: and then either it'll start to work at some future point when armhf stops using containers for autopkgtests, or we figure out what's incompatible and fix it, then drop that constraint from the control
[21:28] <kyrofa> slangasek, oh wait, that would run this in a VM?
[21:28] <slangasek> kyrofa: no, it would cause the test to be skipped because there is no VM available
[21:29] <kyrofa> Ah, gotcha
[21:29] <kyrofa> slangasek, but the other architectures would continue working, as they're VMs anyway?
[21:32] <slangasek> kyrofa: https://paste.ubuntu.com/p/W7VX2SB5Fr/
[21:32] <slangasek> kyrofa: correct
[21:38] <kyrofa> slangasek, that must be lxd 2.something?
[21:38] <slangasek> kyrofa: appears to be 2.21 on xenial
[21:39] <kyrofa> slangasek, the raw.lxc looks interesting, but I've got 3.3 from the snap, changing tracks now
[22:00] <kyrofa> slangasek, heeey exact same error message, that's it! https://pastebin.ubuntu.com/p/mVBKB7ZSHn/
[22:00] <kyrofa> slangasek, do we know the reasoning behind that raw.lxc snippet?
[22:01] <kyrofa> slangasek, snaps work without it, and are broken with it
[22:01] <slangasek> kyrofa: not offhand.  I'll check vcs history
[22:01] <kyrofa> Thank you
[22:02] <slangasek> kyrofa: nope, it's part of the original VCS import by pitti in 2016
[22:02] <slangasek> ohwait, that's a file rename
[22:02] <kyrofa> Oh. Darn, less helpful
[22:02]  * slangasek looks further
[22:02] <kyrofa> Ah
[22:03] <slangasek> kyrofa: 94e64ec7287b5e8597037666f1e31223b02a0b4d "- "lxc.aa_profile=unconfined" to allow tests like pbuilder to mount /proc and other virtual file systems. Unprivileged containers can't do seriously bad things anyway, so AppArmor is just a backup line of defence. But that's too strict for several tests."
[22:04] <slangasek> so it's been that way since 2015 and it appears we're now in the state that either direction we flip it, some tests will be unhappy
[22:05] <kyrofa> slangasek, huh, interesting. Do you see any path toward changing that, or allowing tests to somehow request normal unprivileged containers?
[22:06] <slangasek> I would rather we figure out what privileges are missing to let snapd be happy having privileges
[22:07] <kyrofa> mvo is long EOD, zyga any chance you're around?
[22:10] <kyrofa> jdstrand could probably help us understand what's happening here, as well
[22:13] <kyrofa> Assuming they're all EOD, we can reconvene in the morning slangasek :) . Good progress hunting this down today, thank you!
=== blahdeblah_ is now known as blahdeblah