lxd requires patched sqlite to be used, the package has the proper one bundled this ebuild fixes configure trying to use system sqlite instead of bundled one also includes missing libco soname fix and few minor fixes. Reproducible: Always
Created attachment 595846 [details] fixed 3.16 ebuild
Created attachment 595848 [details, diff] patch needed for 3.16 ebuild
Created attachment 595850 [details] 3.18 ebuild
Created attachment 595854 [details] fixed 3.16 ebuild
Created attachment 595856 [details] lxd-3.18.ebuild
Built and restarted into a working environment on x86_64. The config check ~NF_NAT_MASQUERADE fails on my system with kernel 4.19. Looking forward to this version bump for the storage features introduced with lxd 3.17.
(In reply to Jayson from comment #6) > The config check ~NF_NAT_MASQUERADE fails on my system with kernel 4.19. Symbols changed in 5.1+ afaik The ebuilds are ~amd64 and I matched the symbols with ~amd64 sources.
Hey just thought I'd report that I've been using variants of the 3.18 ebuild in this bug for some time with pretty good results. Unfortunately 3.18 doesn't really like it if you are using unified cgroups which I'm trying to use here... this is a rabbit-hole I'm still exploring and hopefully I may some day return with some kind of concrete result or contribution about this. I do have one constructive and easy thing to share already: newbashcomp scripts/bash/lxd-client lxc triggers the QA nag bots; newbashcomp scripts/bash/lxd-client lxd.lxc bashcomp_alias lxd.lxc lxc seems to work equivalently while generating less red ink during src_install. BTW lxd-3.19 is released and I found it wasn't terribly difficult to update the ebuild here to support it (sadly what I have locally has lots of layers of bubble-gum and duct tape and would require quite a bit of goo-gone before it'd make sense to post here; but based on my experiences a more straightforward revbump shouldn't be too hard).
tried lxd-3.18.ebuild however lxd doesn't start (empty /var/lib/lxd): # lxd -d --group lxd INFO[02-20|18:44:56] LXD 3.18 is starting in normal mode path=/var/lib/lxd INFO[02-20|18:44:56] Kernel uid/gid map: INFO[02-20|18:44:56] - u 0 100000 100000000 INFO[02-20|18:44:56] - g 0 100000 100000000 INFO[02-20|18:44:56] Configured LXD uid/gid map: INFO[02-20|18:44:56] - u 0 1000000 65536 INFO[02-20|18:44:56] - g 0 1000000 65536 WARN[02-20|18:44:56] AppArmor support has been disabled because of lack of kernel support WARN[02-20|18:44:56] Couldn't find the CGroup blkio.weight, I/O weight limits will be ignored. INFO[02-20|18:44:56] Kernel features: INFO[02-20|18:44:56] - netnsid-based network retrieval: yes INFO[02-20|18:44:56] - uevent injection: yes INFO[02-20|18:44:56] - seccomp listener: yes INFO[02-20|18:44:56] - unprivileged file capabilities: yes INFO[02-20|18:44:56] - shiftfs support: no INFO[02-20|18:44:56] Initializing local database DBUG[02-20|18:44:56] Initializing database gateway DBUG[02-20|18:44:56] Start database node id=1 address= 18:30:18.828 [DEBUG]: data dir: /var/lib/lxd/database/global 18:30:18.828 [DEBUG]: metadata1: version 1, term 0, voted for 0 18:30:18.828 [DEBUG]: metadata2: version 2, term 0, voted for 0 18:30:18.828 [DEBUG]: metadata: version 4, term 0, voted for 0 18:30:18.828 [ERROR]: probe I/O capabilities: io_setup: Function not implemented EROR[02-20|18:44:56] Failed to start the daemon: Failed to create dqlite server: failed to create task object INFO[02-20|18:44:56] Starting shutdown sequence DBUG[02-20|18:44:56] Not unmounting temporary filesystems (containers are still running) Error: Failed to create dqlite server: failed to create task object
I just tried the ebuild with lxd-3.23 with hybrid cgroups and it compiles and can start containers at the very least, I'll have to give it some more testing though. Since I have personally wrecked my home production system (read: the dev system) that way I'd like to leave that as a comment to aid in prioritization (no rush though): 3.16 (current ~amd64) and 3.14 (amd64) both have clustering if I saw correctly, however only later versions of lxd got some (much needed) disaster recovery functionality for clusters like `lxd cluster recover-from-quorum-loss` and friends. Only later versions got the new dqlite election/standby/whatever it's called settings beneficial for larger nodes with higher latency (georedundant setups) and probably also smaller setups (three nodes or less). Current state of affairs with 3.16 on a two node cluster is: one node goes down, whole cluster unusable (containers keep on working though) and if that one node is not coming back up, good luck deleting the cluster and re-importing all your containers, profiles, etc on that single node again without cluster functionality turned on, since the server won't even start since it cannot reach a single node in the cluster (and master election is bound to fail on that node even more since it can't even reach itself during that process :/). It was a very educational all-nighter.
LXD-3 seems discontinued, 4.0 is already in the tree.
