[Bug 1156336] New: Virtualization:containers/lxd: Bug
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Bug ID: 1156336 Summary: Virtualization:containers/lxd: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: asarai@suse.com Reporter: appspotio@gmail.com QA Contact: bnc-team-screening@forge.provo.novell.com CC: containers-bugowner@suse.de, fcastelli@suse.com Found By: --- Blocker: --- systemctl start lxd, dose not start. Reference this this thread. https://forums.opensuse.org/showthread.php/538138-LXD-dose-not-start/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |appspotio@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|appspotio@gmail.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |appspotio@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Virtualization:containers/l |lxd segfault on Leap 15.1 |xd: Bug | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c1 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(appspotio@gmail.c | |om) --- Comment #1 from Aleksa Sarai <asarai@suse.com> --- It would be greatly appreciated if you could summarise the issue -- there are 5 pages of forum posts with advice to restart a bunch of services that are completely unrelated to LXD (and enable VT-x in the BIOS?!). As far as I can tell the problem is that LXD is segfaulting -- right? I run LXD on Leap 15.1 and this doesn't happen -- I'll spin up a VM to see what's going on. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c2 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asarai@suse.com Flags| |needinfo?(asarai@suse.com) --- Comment #2 from seve skeis <appspotio@gmail.com> --- @ALEKSA Hi, yes we were debugging it, if you had time just go throughout it fast. Long story short, it just wont start and keep hanging ,so systemctl start lxd ....and hangs, leap 15.1 fresh install. All commands as root not sudo user. Is it working for you on leap 15.1? Can you share what packages did you install please? We wish to use lxd from opensuse packages not snapd. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c3 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(asarai@suse.com) | --- Comment #3 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #2)
Is it working for you on leap 15.1? Can you share what packages did you install please?
I use the ones in Virtualization:containers, but the ones in main Leap repos should work just as well (whenever I update LXD in Virtualization:containers, I immediately forward the request to Factory and to the Leaps).
We wish to use lxd from opensuse packages not snapd.
Yup, that's why I packaged it for openSUSE in the first place. :D -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|3rd party software |Containers Version|unspecified |Leap 15.1 Product|openSUSE.org |openSUSE Distribution QA Contact|bnc-team-screening@forge.pr |qa-bugs@suse.de |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fcastelli@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Flavio Castelli <fcastelli@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|containers-bugowner@suse.de |fcastelli@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c4 --- Comment #4 from seve skeis <appspotio@gmail.com> --- @ALEKSA apology, do not wanna sound rushing it, but is there a timeline for a fix or workaround please? I can delay my project cou0le of days, but really do not 2ish to install snapd. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c5 --- Comment #5 from Aleksa Sarai <asarai@suse.com> --- I can't reproduce this at all -- I've set up several openSUSE Leap 15.1 VMs and installed the LXD package in the default repos and it works without any issues. You should be aware that you need to run the lxc commands as root (or add yourself to the lxd group) otherwise you'll get permission errors, but that's not the error you were getting -- your LXD process was actually segfaulting. Are you running this on a strange architecture or something? Did you change any configuration options when you were testing this in a VM? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c6 --- Comment #6 from seve skeis <appspotio@gmail.com> --- Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c7 --- Comment #7 from seve skeis <appspotio@gmail.com> --- (In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
zypper in lxd Loading repository data... Reading installed packages... Resolving package dependencies... The following 11 NEW packages are going to be installed: criu liblxc1 libnet9 libuv1 lxcfs lxcfs-hooks-lxc lxd lxd-bash-completion python2-ipaddr python2-protobuf squashfs 11 new packages to install. Overall download size: 45.2 MiB. Already cached: 0 B. After the operation, additional 144.8 MiB will be used. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c8 --- Comment #8 from seve skeis <appspotio@gmail.com> --- (In reply to seve skeis from comment #7)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
zypper in lxd Loading repository data... Reading installed packages... Resolving package dependencies...
The following 11 NEW packages are going to be installed: criu liblxc1 libnet9 libuv1 lxcfs lxcfs-hooks-lxc lxd lxd-bash-completion python2-ipaddr python2-protobuf squashfs
11 new packages to install. Overall download size: 45.2 MiB. Already cached: 0 B. After the operation, additional 144.8 MiB will be used.
Overall download size: 45.2 MiB. Already cached: 0 B. After the operation, additional 144.8 MiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package libnet9-1.2~rc3-lp151.2.2.x86_64 (1/11), 44.7 KiB (100.2 KiB unpacked) Retrieving: libnet9-1.2~rc3-lp151.2.2.x86_64.rpm ............................................................................................................................................................[done] Retrieving package libuv1-1.18.0-lp151.2.3.x86_64 (2/11), 83.8 KiB (164.7 KiB unpacked) Retrieving: libuv1-1.18.0-lp151.2.3.x86_64.rpm ..............................................................................................................................................................[done] Retrieving package python2-ipaddr-2.1.11-lp151.2.2.noarch (3/11), 37.6 KiB (193.7 KiB unpacked) Retrieving: python2-ipaddr-2.1.11-lp151.2.2.noarch.rpm ......................................................................................................................................................[done] Retrieving package python2-protobuf-3.5.0-lp151.4.7.x86_64 (4/11), 493.0 KiB ( 4.0 MiB unpacked) Retrieving: python2-protobuf-3.5.0-lp151.4.7.x86_64.rpm .....................................................................................................................................................[done] Retrieving package squashfs-4.3-lp151.2.3.x86_64 (5/11), 134.6 KiB (351.1 KiB unpacked) Retrieving: squashfs-4.3-lp151.2.3.x86_64.rpm ...............................................................................................................................................................[done] Retrieving package criu-3.8.1-lp151.2.3.x86_64 (6/11), 596.4 KiB ( 2.3 MiB unpacked) Retrieving: criu-3.8.1-lp151.2.3.x86_64.rpm .................................................................................................................................................................[done] Retrieving package liblxc1-3.2.1-lp151.4.5.1.x86_64 (7/11), 355.1 KiB ( 1.0 MiB unpacked) Retrieving: liblxc1-3.2.1-lp151.4.5.1.x86_64.rpm ..............................................................................................................................................[done (220.3 KiB/s)] Retrieving package lxcfs-3.1.2-lp151.2.3.1.x86_64 (8/11), 70.3 KiB (128.8 KiB unpacked) Retrieving: lxcfs-3.1.2-lp151.2.3.1.x86_64.rpm ..............................................................................................................................................................[done] Retrieving package lxcfs-hooks-lxc-3.1.2-lp151.2.3.1.noarch (9/11), 17.3 KiB ( 103 B unpacked) Retrieving: lxcfs-hooks-lxc-3.1.2-lp151.2.3.1.noarch.rpm .......................................................................................................................................[done (64.4 KiB/s)] Retrieving package lxd-3.18-lp151.11.1.x86_64 (10/11), 43.4 MiB (136.6 MiB unpacked) Retrieving: lxd-3.18-lp151.11.1.x86_64.rpm ......................................................................................................................................................[done (1.9 MiB/s)] Retrieving package lxd-bash-completion-3.18-lp151.11.1.noarch (11/11), 14.8 KiB ( 12.2 KiB unpacked) Retrieving: lxd-bash-completion-3.18-lp151.11.1.noarch.rpm ..................................................................................................................................................[done] Checking for file conflicts: ................................................................................................................................................................................[done] ( 1/11) Installing: libnet9-1.2~rc3-lp151.2.2.x86_64 ........................................................................................................................................................[done] ( 2/11) Installing: libuv1-1.18.0-lp151.2.3.x86_64 ..........................................................................................................................................................[done] ( 3/11) Installing: python2-ipaddr-2.1.11-lp151.2.2.noarch ..................................................................................................................................................[done] ( 4/11) Installing: python2-protobuf-3.5.0-lp151.4.7.x86_64 .................................................................................................................................................[done] ( 5/11) Installing: squashfs-4.3-lp151.2.3.x86_64 ...........................................................................................................................................................[done] ( 6/11) Installing: criu-3.8.1-lp151.2.3.x86_64 .............................................................................................................................................................[done] ( 7/11) Installing: liblxc1-3.2.1-lp151.4.5.1.x86_64 ........................................................................................................................................................[done] Additional rpm output: setting /usr/lib/lxc/lxc-user-nic to root:kvm 4750. (wrong permissions 0750) ( 8/11) Installing: lxcfs-3.1.2-lp151.2.3.1.x86_64 ..........................................................................................................................................................[done] ( 9/11) Installing: lxcfs-hooks-lxc-3.1.2-lp151.2.3.1.noarch ................................................................................................................................................[done] (10/11) Installing: lxd-3.18-lp151.11.1.x86_64 ..............................................................................................................................................................[done] (11/11) Installing: lxd-bash-completion-3.18-lp151.11.1.noarch ..............................................................................................................................................[done] seven:~ # systemctl status lxd ● lxd.service - LXD Container Hypervisor Loaded: loaded (/usr/lib/systemd/system/lxd.service; disabled; vendor preset: disabled) Active: inactive (dead) Docs: man:lxd(1) seven:~ # systemctl start lxd ...hangs -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c9 --- Comment #9 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2). Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c10 --- Comment #10 from seve skeis <appspotio@gmail.com> --- (In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work, can you check the thread mentioned please, all this commands and dmsegs and logs are there. and my pc hardware details too. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c11 --- Comment #11 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #10)
(In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work
My question was whether this only happens on this particular machine -- do you have another PC or laptop on which you can run this test? The reason I'm asking is to figure out whether it's specific to your hardware.
can you check the thread mentioned please
I read it after you posted comment 2.
all this commands and dmesgs and logs are there.
Ah I missed that you ran 'sudo lxd -d' (I thought you modified the .service file the last time I skimmed through it). But there isn't a dmesg log -- the logs posted were from journalctl or from the output of LXD. dmesg will give you It would also be helpful to get the coredump (which gives useful debugging information to understand in which function the crash occured) -- you can get it using coredumpctl. It might be too large to upload here, but you can always upload it on a temporary sharing site and I'll download it.
and my pc hardware details too.
(For future reference.)
CPU I7 6700K RAM 32GB DDR4 MB: ASUS MAXIMUS EXTREME G: NVIDIA GTX 970 TURBO P.S: do not know if its worth mentioning, i had to boot with kernel param: acpi_enforce_resources=lax.
I notice you're using the NVIDIA drivers:
Fri Nov 8 06:55:09 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 440.31 Driver Version: 440.31 CUDA Version: 10.2 | |-------------------------------+----------------------+----------------------+
Do you have the same problem if you run with the Nouveau drivers? I ask because LXD supports GPU virutalisation (which uses a bunch of features from the GPU, GPU kernel module, and the userspace libraries). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c12 --- Comment #12 from seve skeis <appspotio@gmail.com> --- (In reply to Aleksa Sarai from comment #11)
(In reply to seve skeis from comment #10)
(In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work
My question was whether this only happens on this particular machine -- do you have another PC or laptop on which you can run this test? The reason I'm asking is to figure out whether it's specific to your hardware.
can you check the thread mentioned please
I read it after you posted comment 2.
all this commands and dmesgs and logs are there.
Ah I missed that you ran 'sudo lxd -d' (I thought you modified the .service file the last time I skimmed through it). But there isn't a dmesg log -- the logs posted were from journalctl or from the output of LXD. dmesg will give you
It would also be helpful to get the coredump (which gives useful debugging information to understand in which function the crash occured) -- you can get it using coredumpctl. It might be too large to upload here, but you can always upload it on a temporary sharing site and I'll download it.
and my pc hardware details too.
(For future reference.)
CPU I7 6700K RAM 32GB DDR4 MB: ASUS MAXIMUS EXTREME G: NVIDIA GTX 970 TURBO P.S: do not know if its worth mentioning, i had to boot with kernel param: acpi_enforce_resources=lax.
I notice you're using the NVIDIA drivers:
Fri Nov 8 06:55:09 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 440.31 Driver Version: 440.31 CUDA Version: 10.2 | |-------------------------------+----------------------+----------------------+
Do you have the same problem if you run with the Nouveau drivers? I ask because LXD supports GPU virutalisation (which uses a bunch of features from the GPU, GPU kernel module, and the userspace libraries).
Hi, i will run dumps, later and share it, i have not other machines, have not tried with nouvuew, but it works with snapd with nvidia. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c13 --- Comment #13 from seve skeis <appspotio@gmail.com> --- (In reply to seve skeis from comment #12)
(In reply to Aleksa Sarai from comment #11)
(In reply to seve skeis from comment #10)
(In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work
My question was whether this only happens on this particular machine -- do you have another PC or laptop on which you can run this test? The reason I'm asking is to figure out whether it's specific to your hardware.
can you check the thread mentioned please
I read it after you posted comment 2.
all this commands and dmesgs and logs are there.
Ah I missed that you ran 'sudo lxd -d' (I thought you modified the .service file the last time I skimmed through it). But there isn't a dmesg log -- the logs posted were from journalctl or from the output of LXD. dmesg will give you
It would also be helpful to get the coredump (which gives useful debugging information to understand in which function the crash occured) -- you can get it using coredumpctl. It might be too large to upload here, but you can always upload it on a temporary sharing site and I'll download it.
and my pc hardware details too.
(For future reference.)
CPU I7 6700K RAM 32GB DDR4 MB: ASUS MAXIMUS EXTREME G: NVIDIA GTX 970 TURBO P.S: do not know if its worth mentioning, i had to boot with kernel param: acpi_enforce_resources=lax.
I notice you're using the NVIDIA drivers:
Fri Nov 8 06:55:09 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 440.31 Driver Version: 440.31 CUDA Version: 10.2 | |-------------------------------+----------------------+----------------------+
Do you have the same problem if you run with the Nouveau drivers? I ask because LXD supports GPU virutalisation (which uses a bunch of features from the GPU, GPU kernel module, and the userspace libraries).
Hi, i will run dumps, later and share it, i have not other machines, have not tried with nouvuew, but it works with snapd with nvidia.
My system dose not have coredumpctl , or systemd-coredumpctl. and do not know how to use it. This is going way harder than i expected. i will be using snapd, till you guys fix it. i suggest you use real hardware with fresh leap 15.1, then the issue will be clear whether its my hardware or a bug. Sorry for any inconvenience, Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c14 --- Comment #14 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #13)
(In reply to seve skeis from comment #12)
(In reply to Aleksa Sarai from comment #11)
(In reply to seve skeis from comment #10)
(In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6)
Hi, actually, all using root, no wired structure, and on real hardware, never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work
My question was whether this only happens on this particular machine -- do you have another PC or laptop on which you can run this test? The reason I'm asking is to figure out whether it's specific to your hardware.
can you check the thread mentioned please
I read it after you posted comment 2.
all this commands and dmesgs and logs are there.
Ah I missed that you ran 'sudo lxd -d' (I thought you modified the .service file the last time I skimmed through it). But there isn't a dmesg log -- the logs posted were from journalctl or from the output of LXD. dmesg will give you
It would also be helpful to get the coredump (which gives useful debugging information to understand in which function the crash occured) -- you can get it using coredumpctl. It might be too large to upload here, but you can always upload it on a temporary sharing site and I'll download it.
and my pc hardware details too.
(For future reference.)
CPU I7 6700K RAM 32GB DDR4 MB: ASUS MAXIMUS EXTREME G: NVIDIA GTX 970 TURBO P.S: do not know if its worth mentioning, i had to boot with kernel param: acpi_enforce_resources=lax.
I notice you're using the NVIDIA drivers:
Fri Nov 8 06:55:09 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 440.31 Driver Version: 440.31 CUDA Version: 10.2 | |-------------------------------+----------------------+----------------------+
Do you have the same problem if you run with the Nouveau drivers? I ask because LXD supports GPU virutalisation (which uses a bunch of features from the GPU, GPU kernel module, and the userspace libraries).
Hi, i will run dumps, later and share it, i have not other machines, have not tried with nouvuew, but it works with snapd with nvidia.
My system dose not have coredumpctl , or systemd-coredumpctl. and do not know how to use it.
First, trigger the coredump (run `lxd`) then do % sudo coredumpctl info lxd which should give you the latest backtrace and a few other bits of information from LXD. This should give us plenty of information by itself, but to get the actual coredump you need to do: % sudo coredumpctl dump lxd > lxd.core If the above give you errors about missing corefiles, then you might have to modify your coredump.conf configuration -- but for me it just works out of the box. You can also disable systemd-coredump and just make a regular corefile if you modify the kernel.core_pattern sysctl to be a simple file: % sudo sysctl -w kernel.core_pattern=%e.%p_%u.%g_%t.core And then if you trigger the coredump, there will be a corefile in your current directory with a name that looks like "lxd.$PID_$UID.$GID_$TIME.core".
i will be using snapd, till you guys fix it.
I'm not sure how it's reasonable to think we can fix it, if we can't even reproduce it. But sure, feel free to use whatever works for you.
i suggest you use real hardware with fresh leap 15.1, then the issue will be clear whether its my hardware or a bug.
Unless I'm missing something, several other people in the original thread said they tried on real hardware (just as I'm running things on my real hardware) and didn't have issues. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c15 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(appspotio@gmail.c |needinfo?(asarai@suse.com) |om) | --- Comment #15 from seve skeis <appspotio@gmail.com> --- (In reply to Aleksa Sarai from comment #14)
(In reply to seve skeis from comment #13)
(In reply to seve skeis from comment #12)
(In reply to Aleksa Sarai from comment #11)
(In reply to seve skeis from comment #10)
(In reply to Aleksa Sarai from comment #9)
(In reply to seve skeis from comment #6) > Hi, actually, all using root, no wired structure, and on real hardware, > never tried on a vm. Can i ask what are the packages you installed?
I installed the same ones you did -- the ones that are in the Leap 15.1 repos. I am running LXD on my server (on bare metal) and it also works fine, but the reason I tested it in a VM is to check whether there was an issue if you did a fresh install (I've upgraded my server incrementally from Leap 42.2).
Do you only have this problem on one machine, or can you replicate the problem on any other machines? What is the output of dmesg after LXD crashes (please don't paste it as a comment -- add it as an attachment)? If you run just 'sudo lxd` in a terminal (to start the server in your shell), what happens?
i have no issues with pc, its fresh install, no repos, no apps, just trying to get LXD work
My question was whether this only happens on this particular machine -- do you have another PC or laptop on which you can run this test? The reason I'm asking is to figure out whether it's specific to your hardware.
can you check the thread mentioned please
I read it after you posted comment 2.
all this commands and dmesgs and logs are there.
Ah I missed that you ran 'sudo lxd -d' (I thought you modified the .service file the last time I skimmed through it). But there isn't a dmesg log -- the logs posted were from journalctl or from the output of LXD. dmesg will give you
It would also be helpful to get the coredump (which gives useful debugging information to understand in which function the crash occured) -- you can get it using coredumpctl. It might be too large to upload here, but you can always upload it on a temporary sharing site and I'll download it.
and my pc hardware details too.
(For future reference.)
CPU I7 6700K RAM 32GB DDR4 MB: ASUS MAXIMUS EXTREME G: NVIDIA GTX 970 TURBO P.S: do not know if its worth mentioning, i had to boot with kernel param: acpi_enforce_resources=lax.
I notice you're using the NVIDIA drivers:
Fri Nov 8 06:55:09 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 440.31 Driver Version: 440.31 CUDA Version: 10.2 | |-------------------------------+----------------------+----------------------+
Do you have the same problem if you run with the Nouveau drivers? I ask because LXD supports GPU virutalisation (which uses a bunch of features from the GPU, GPU kernel module, and the userspace libraries).
Hi, i will run dumps, later and share it, i have not other machines, have not tried with nouvuew, but it works with snapd with nvidia.
My system dose not have coredumpctl , or systemd-coredumpctl. and do not know how to use it.
First, trigger the coredump (run `lxd`) then do
% sudo coredumpctl info lxd
which should give you the latest backtrace and a few other bits of information from LXD. This should give us plenty of information by itself, but to get the actual coredump you need to do:
% sudo coredumpctl dump lxd > lxd.core
If the above give you errors about missing corefiles, then you might have to modify your coredump.conf configuration -- but for me it just works out of the box.
You can also disable systemd-coredump and just make a regular corefile if you modify the kernel.core_pattern sysctl to be a simple file:
% sudo sysctl -w kernel.core_pattern=%e.%p_%u.%g_%t.core
And then if you trigger the coredump, there will be a corefile in your current directory with a name that looks like "lxd.$PID_$UID.$GID_$TIME.core".
i will be using snapd, till you guys fix it.
I'm not sure how it's reasonable to think we can fix it, if we can't even reproduce it. But sure, feel free to use whatever works for you.
i suggest you use real hardware with fresh leap 15.1, then the issue will be clear whether its my hardware or a bug.
Unless I'm missing something, several other people in the original thread said they tried on real hardware (just as I'm running things on my real hardware) and didn't have issues. This link to core.dump https://gofile.io/?c=1dPPkj kindly check, and get back if possible fix ASAP, as i just started my other project.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c16 Matei Albu <malbu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |malbu@suse.com --- Comment #16 from Matei Albu <malbu@suse.com> --- Created attachment 828018 --> http://bugzilla.opensuse.org/attachment.cgi?id=828018&action=edit lxd coredump On an OpenSuse Leap 15.1 machine with lxd-3.18-lp151.11.1.x86_64 I get a segfault. # /usr/bin/lxd -d --group=lxd --logfile=/var/log/lxd/lxd.log DBUG[01-22|12:18:48] Connecting to a local LXD over a Unix socket DBUG[01-22|12:18:48] Sending request to LXD method=GET url=http://unix.socket/1.0 etag= INFO[01-22|12:18:48] LXD 3.18 is starting in normal mode path=/var/lib/lxd INFO[01-22|12:18:48] Kernel uid/gid map: INFO[01-22|12:18:48] - u 0 0 4294967295 INFO[01-22|12:18:48] - g 0 0 4294967295 INFO[01-22|12:18:48] Configured LXD uid/gid map: INFO[01-22|12:18:48] - u 0 400000000 500000001 INFO[01-22|12:18:48] - g 0 400000000 500000001 WARN[01-22|12:18:48] CGroup memory swap accounting is disabled, swap limits will be ignored. INFO[01-22|12:18:48] Kernel features: INFO[01-22|12:18:48] - netnsid-based network retrieval: no INFO[01-22|12:18:48] - uevent injection: no INFO[01-22|12:18:48] - seccomp listener: no INFO[01-22|12:18:48] - unprivileged file capabilities: no INFO[01-22|12:18:48] - shiftfs support: no INFO[01-22|12:18:48] Initializing local database DBUG[01-22|12:18:48] Initializing database gateway DBUG[01-22|12:18:48] Start database node id=1 address= DBUG[01-22|12:18:48] Connecting to a local LXD over a Unix socket DBUG[01-22|12:18:48] Sending request to LXD method=GET url=http://unix.socket/1.0 etag= DBUG[01-22|12:18:48] Detected stale unix socket, deleting DBUG[01-22|12:18:48] Detected stale unix socket, deleting INFO[01-22|12:18:48] Starting /dev/lxd handler: INFO[01-22|12:18:48] - binding devlxd socket socket=/var/lib/lxd/devlxd/sock INFO[01-22|12:18:48] REST API daemon: INFO[01-22|12:18:48] - binding Unix socket socket=/var/lib/lxd/unix.socket INFO[01-22|12:18:48] Initializing global database DBUG[01-22|12:18:48] Dqlite: connected address=1 attempt=0 Segmentation fault (core dumped) The machines is a physical machine. # hwinfo --cpu 01: None 00.0: 10103 CPU [Created at cpu.462] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.61.4 "Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,a$ ch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,sdbg,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x$ apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,3dnowprefetch,cpuid_fault,epb,invpcid_single,pti,ssbd,ibrs,ibpb,stibp,tpr_shadow,vnmi,flexpriority,e$ t,vpid,fsgsbase,tsc_adjust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,rdseed,adx,smap,intel_pt,xsaveopt,dtherm,ida,arat,pln,pts,md_clear,flush_l1d Clock: 2594 MHz BogoMips: 5188.28 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=no, avail=yes, need=no, active=unknown 02: None 01.0: 10103 CPU [Created at cpu.462] Unique ID: wkFv.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.61.4 "Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,a$ ch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,sdbg,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x$ apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,3dnowprefetch,cpuid_fault,epb,invpcid_single,pti,ssbd,ibrs,ibpb,stibp,tpr_shadow,vnmi,flexpriority,e$ t,vpid,fsgsbase,tsc_adjust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,rdseed,adx,smap,intel_pt,xsaveopt,dtherm,ida,arat,pln,pts,md_clear,flush_l1d Clock: 2594 MHz BogoMips: 5188.28 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=no, avail=yes, need=no, active=unknown 03: None 02.0: 10103 CPU [Created at cpu.462] Unique ID: +rIN.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.61.4 "Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,ar ch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,sdbg,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2 apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,3dnowprefetch,cpuid_fault,epb,invpcid_single,pti,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,tsc_a djust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,rdseed,adx,smap,intel_pt,xsaveopt,dtherm,ida,arat,pln,pts Clock: 2594 MHz BogoMips: 5188.28 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=no, avail=yes, need=no, active=unknown 04: None 03.0: 10103 CPU [Created at cpu.462] Unique ID: 4zLr.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.61.4 "Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,ar ch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,sdbg,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2 apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,3dnowprefetch,cpuid_fault,epb,invpcid_single,pti,ssbd,ibrs,ibpb,stibp,tpr_shadow,vnmi,flexpriority,ep t,vpid,fsgsbase,tsc_adjust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,rdseed,adx,smap,intel_pt,xsaveopt,dtherm,ida,arat,pln,pts,md_clear,flush_l1d Clock: 2594 MHz BogoMips: 5188.28 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=no, avail=yes, need=no, active=unknown Let me know if you need more details. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c17 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(asarai@suse.com) | --- Comment #17 from seve skeis <appspotio@gmail.com> --- Ok, 2 dump cores better than 1, i hope you are able to reproduce it now. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c18 --- Comment #18 from Aleksa Sarai <asarai@suse.com> --- I've been staring at the coredumps for a few hours, and it's not making sense. It looks like Go is just aborting the process in both of them: % dlv core /usr/bin/lxd lxd.core (dlv) grs Goroutine 1 - User: /usr/lib64/go/1.11/src/runtime/netpoll.go:173 internal/poll.runtime_pollWait (0x55bb0c670c78) Goroutine 2 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) * Goroutine 17 - User: /usr/lib64/go/1.11/src/runtime/sys_linux_amd64.s:146 runtime.raise (0x55bb0c6a64b4) (thread 29109) Goroutine 18 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 19 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 22 - User: /usr/lib64/go/1.11/src/runtime/sigqueue.go:139 os/signal.signal_recv (0x55bb0c68b2ce) (thread 29096) Goroutine 26 - User: /usr/lib64/go/1.11/src/database/sql/sql.go:1001 database/sql.(*DB).connectionOpener (0x55bb0ca6bf4a) Goroutine 27 - User: /usr/lib64/go/1.11/src/database/sql/sql.go:1014 database/sql.(*DB).connectionResetter (0x55bb0ca6c07d) Goroutine 31 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 32 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 34 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 35 - User: /usr/lib64/go/1.11/src/runtime/proc.go:303 runtime.gopark (0x55bb0c676371) Goroutine 58 - User: /usr/lib64/go/1.11/src/runtime/netpoll.go:173 internal/poll.runtime_pollWait (0x55bb0c670c78) Goroutine 59 - User: /usr/lib64/go/1.11/src/runtime/netpoll.go:173 internal/poll.runtime_pollWait (0x55bb0c670c78) Goroutine 62 - User: /usr/lib64/go/1.11/src/database/sql/sql.go:1001 database/sql.(*DB).connectionOpener (0x55bb0ca6bf4a) Goroutine 63 - User: /usr/lib64/go/1.11/src/database/sql/sql.go:1014 database/sql.(*DB).connectionResetter (0x55bb0ca6c07d) Goroutine 64 - User: /usr/lib64/go/1.11/src/runtime/sys_linux_amd64.s:532 runtime.futex (0x55bb0c6a6a03) (thread 29108) Goroutine 66 - User: /usr/lib64/go/1.11/src/runtime/sys_linux_amd64.s:532 runtime.futex (0x55bb0c6a6a03) (thread 29093) (dlv) bt 0 0x000055bb0c6a64b4 in runtime.raise at /usr/lib64/go/1.11/src/runtime/sys_linux_amd64.s:146 1 0x000055bb0c6a4b81 in runtime.goexit at /usr/lib64/go/1.11/src/runtime/asm_amd64.s:1333 The main takeaway is that the segfault isn't happening in the C library (though I'm not sure if delve understands how to load symbols from shared libraries when debugging coredumps). But it's incredibly strange to get a segfault from within Go code without an associated panic() stacktrace. I'm going to install Leap on an older laptop and see if I can reproduce the issue there... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c19 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(appspotio@gmail.c | |om) --- Comment #19 from Aleksa Sarai <asarai@suse.com> --- I just did a fresh install of Leap 15.1 on an old ThinkPad I have lying around and I couldn't reproduce the issue at all -- lxd-3.18-lp151.11.1.x86_64 works fine. Unless one of you is willing to give me SSH access to your machine (or be able to reproduce it in a VM), I don't really know how else I can help. Can you provide the output of "ldd /usr/bin/lxd" as well as "ldd /usr/lib64/lxd/*"? Maybe they don't have the right DT_NEEDED paths. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c20 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(appspotio@gmail.c |needinfo?(asarai@suse.com) |om) | --- Comment #20 from seve skeis <appspotio@gmail.com> --- ``` ldd /usr/bin/lxd linux-vdso.so.1 (0x00007ffe561ad000) liblxc.so.1 => /usr/lib64/liblxc.so.1 (0x00007fbfe67c8000) libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fbfe65c3000) libutil.so.1 => /lib64/libutil.so.1 (0x00007fbfe63c0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbfe61a2000) libacl.so.1 => /lib64/libacl.so.1 (0x00007fbfe5f99000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007fbfe5cd7000) /usr/lib64/lxd/libdqlite.so.0 (0x00007fbfe5ab2000) libc.so.6 => /lib64/libc.so.6 (0x00007fbfe56f8000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fbfe54cf000) libseccomp.so.2 => /usr/lib64/libseccomp.so.2 (0x00007fbfe5288000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbfe5070000) /lib64/ld-linux-x86-64.so.2 (0x00007fbfe94a9000) libattr.so.1 => /lib64/libattr.so.1 (0x00007fbfe4e6b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbfe4c67000) /usr/lib64/lxd/libco.so.0 (0x00007fbfe4a63000) /usr/lib64/lxd/libraft.so.0 (0x00007fbfe4842000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007fbfe4618000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fbfe438b000) librt.so.1 => /lib64/librt.so.1 (0x00007fbfe4183000) ``` ``` ldd /usr/lib64/lxd/* /usr/lib64/lxd/libco.so.0: linux-vdso.so.1 (0x00007ffec85ed000) libc.so.6 => /lib64/libc.so.6 (0x00007fd564158000) /lib64/ld-linux-x86-64.so.2 (0x00007fd564716000) /usr/lib64/lxd/libco.so.0.1.0: linux-vdso.so.1 (0x00007ffea39ed000) libc.so.6 => /lib64/libc.so.6 (0x00007ff5dbc75000) /lib64/ld-linux-x86-64.so.2 (0x00007ff5dc233000) /usr/lib64/lxd/libdqlite.so.0: linux-vdso.so.1 (0x00007ffe4e1e3000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007f1adacc6000) /usr/lib64/lxd/libco.so.0 (0x00007f1adaac2000) /usr/lib64/lxd/libraft.so.0 (0x00007f1ada8a1000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007f1ada677000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1ada459000) libc.so.6 => /lib64/libc.so.6 (0x00007f1ada09f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f1ad9e9b000) /lib64/ld-linux-x86-64.so.2 (0x00007f1adb1ad000) librt.so.1 => /lib64/librt.so.1 (0x00007f1ad9c93000) /usr/lib64/lxd/libdqlite.so.0.0.1: linux-vdso.so.1 (0x00007ffe46fd5000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007fa60ec4e000) /usr/lib64/lxd/libco.so.0 (0x00007fa60ea4a000) /usr/lib64/lxd/libraft.so.0 (0x00007fa60e829000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007fa60e5ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa60e3e1000) libc.so.6 => /lib64/libc.so.6 (0x00007fa60e027000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa60de23000) /lib64/ld-linux-x86-64.so.2 (0x00007fa60f135000) librt.so.1 => /lib64/librt.so.1 (0x00007fa60dc1b000) /usr/lib64/lxd/libraft.so.0: linux-vdso.so.1 (0x00007ffef367e000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007f4cf1911000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4cf16f3000) libc.so.6 => /lib64/libc.so.6 (0x00007f4cf1339000) librt.so.1 => /lib64/librt.so.1 (0x00007f4cf1131000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f4cf0f2d000) /lib64/ld-linux-x86-64.so.2 (0x00007f4cf1d5c000) /usr/lib64/lxd/libraft.so.0.0.7: linux-vdso.so.1 (0x00007ffc7add4000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007f4b3737b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4b3715d000) libc.so.6 => /lib64/libc.so.6 (0x00007f4b36da3000) librt.so.1 => /lib64/librt.so.1 (0x00007f4b36b9b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f4b36997000) /lib64/ld-linux-x86-64.so.2 (0x00007f4b377c6000) /usr/lib64/lxd/libsqlite3.so.0: linux-vdso.so.1 (0x00007ffd1e3fe000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f02589f4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f02587d6000) libc.so.6 => /lib64/libc.so.6 (0x00007f025841c000) /lib64/ld-linux-x86-64.so.2 (0x00007f0258eba000) /usr/lib64/lxd/libsqlite3.so.0.8.6: linux-vdso.so.1 (0x00007ffc38738000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f608e785000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f608e567000) libc.so.6 => /lib64/libc.so.6 (0x00007f608e1ad000) /lib64/ld-linux-x86-64.so.2 (0x00007f608ec4b000) ``` -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c21 --- Comment #21 from Matei Albu <malbu@suse.com> --- $ ldd /usr/bin/lxd linux-vdso.so.1 (0x00007ffd85de2000) liblxc.so.1 => /usr/lib64/liblxc.so.1 (0x00007fc963f8a000) libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fc963d85000) libutil.so.1 => /lib64/libutil.so.1 (0x00007fc963b82000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc963964000) libacl.so.1 => /lib64/libacl.so.1 (0x00007fc96375b000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007fc963499000) /usr/lib64/lxd/libdqlite.so.0 (0x00007fc963274000) libc.so.6 => /lib64/libc.so.6 (0x00007fc962eba000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc962c91000) libseccomp.so.2 => /usr/lib64/libseccomp.so.2 (0x00007fc962a4a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc962832000) /lib64/ld-linux-x86-64.so.2 (0x00007fc966c6b000) libattr.so.1 => /lib64/libattr.so.1 (0x00007fc96262d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc962429000) /usr/lib64/lxd/libco.so.0 (0x00007fc962225000) /usr/lib64/lxd/libraft.so.0 (0x00007fc962004000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007fc961dda000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc961b4d000) librt.so.1 => /lib64/librt.so.1 (0x00007fc961945000) $ ldd /usr/lib64/lxd/* /usr/lib64/lxd/libco.so.0: linux-vdso.so.1 (0x00007ffef27fc000) libc.so.6 => /lib64/libc.so.6 (0x00007f4902356000) /lib64/ld-linux-x86-64.so.2 (0x00007f4902914000) /usr/lib64/lxd/libco.so.0.1.0: linux-vdso.so.1 (0x00007ffd663b7000) libc.so.6 => /lib64/libc.so.6 (0x00007f47f279e000) /lib64/ld-linux-x86-64.so.2 (0x00007f47f2d5c000) /usr/lib64/lxd/libdqlite.so.0: linux-vdso.so.1 (0x00007ffe1874d000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007ff89cb9f000) /usr/lib64/lxd/libco.so.0 (0x00007ff89c99b000) /usr/lib64/lxd/libraft.so.0 (0x00007ff89c77a000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007ff89c550000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff89c332000) libc.so.6 => /lib64/libc.so.6 (0x00007ff89bf78000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff89bd74000) /lib64/ld-linux-x86-64.so.2 (0x00007ff89d086000) librt.so.1 => /lib64/librt.so.1 (0x00007ff89bb6c000) /usr/lib64/lxd/libdqlite.so.0.0.1: linux-vdso.so.1 (0x00007ffda77fa000) /usr/lib64/lxd/libsqlite3.so.0 (0x00007fd421e79000) /usr/lib64/lxd/libco.so.0 (0x00007fd421c75000) /usr/lib64/lxd/libraft.so.0 (0x00007fd421a54000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007fd42182a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd42160c000) libc.so.6 => /lib64/libc.so.6 (0x00007fd421252000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd42104e000) /lib64/ld-linux-x86-64.so.2 (0x00007fd422360000) librt.so.1 => /lib64/librt.so.1 (0x00007fd420e46000) /usr/lib64/lxd/libraft.so.0: linux-vdso.so.1 (0x00007ffcaa3e2000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007f0ea7ff8000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0ea7dda000) libc.so.6 => /lib64/libc.so.6 (0x00007f0ea7a20000) librt.so.1 => /lib64/librt.so.1 (0x00007f0ea7818000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0ea7614000) /lib64/ld-linux-x86-64.so.2 (0x00007f0ea8443000) /usr/lib64/lxd/libraft.so.0.0.7: linux-vdso.so.1 (0x00007ffefef0b000) libuv.so.1 => /usr/lib64/libuv.so.1 (0x00007f224a1c4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2249fa6000) libc.so.6 => /lib64/libc.so.6 (0x00007f2249bec000) librt.so.1 => /lib64/librt.so.1 (0x00007f22499e4000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f22497e0000) /lib64/ld-linux-x86-64.so.2 (0x00007f224a60f000) /usr/lib64/lxd/libsqlite3.so.0: linux-vdso.so.1 (0x00007ffca8eef000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c8caf6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c8c8d8000) libc.so.6 => /lib64/libc.so.6 (0x00007f2c8c51e000) /lib64/ld-linux-x86-64.so.2 (0x00007f2c8cfbc000) /usr/lib64/lxd/libsqlite3.so.0.8.6: linux-vdso.so.1 (0x00007ffd4dbb4000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c0415f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7c03f41000) libc.so.6 => /lib64/libc.so.6 (0x00007f7c03b87000) /lib64/ld-linux-x86-64.so.2 (0x00007f7c04625000) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c22 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(asarai@suse.com) | --- Comment #22 from Aleksa Sarai <asarai@suse.com> --- Yeah, those all look reasonable. To be honest, at this point I'm really not too sure what could be causing it -- and because I can't reproduce it I can't play around with a box to see what might be related. Can you try running `strace -f -o lxd.strace /usr/bin/lxd` and posting the full syscall trace? Maybe LXD is doing something specific to trigger the segfault. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c23 --- Comment #23 from Aleksa Sarai <asarai@suse.com> --- The other option would be to run LXD under delve[1] and then post the backtrace you get once the crash is triggered. I think the coredumps are missing some information (they don't make any sense to me at least). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(appspotio@gmail.c | |om) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c24 --- Comment #24 from Matei Albu <malbu@suse.com> --- Created attachment 828578 --> http://bugzilla.opensuse.org/attachment.cgi?id=828578&action=edit lxd strace Here's the strace output. I'm gonna provide delve output soon. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c25 --- Comment #25 from Aleksa Sarai <asarai@suse.com> --- (In reply to Matei Albu from comment #24)
Created attachment 828578 [details] lxd strace
Here's the strace output. I'm gonna provide delve output soon.
Okay, so a quick look (I'll take a better look tomorrow morning) indicates that the segfault we see in the coredump happens here -- the go runtime is killing itself: 22299 rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0 22299 rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=~[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f42572fd300}, NULL, 8) = 0 22299 gettid() = 22299 22299 tkill(22299, SIGSEGV) = 0 22299 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=22286, si_uid=0} --- But there is an earlier segfault: 22299 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...> 22286 epoll_pwait(4, <unfinished ...> 22299 <... mmap resumed> ) = 0x7f424ac9c000 22299 mprotect(0x7f4224021000, 24576, PROT_READ|PROT_WRITE) = 0 22299 mprotect(0x7f4224027000, 86016, PROT_READ|PROT_WRITE) = 0 22299 getpid() = 22286 22299 openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 17 22299 read(17, "lD\332\352\365\277C\304\36\16u!\306\241O\331@\335\17\314\340\302\352$\373\226\257\23\261\331\335!"..., 256) = 256 22299 close(17) = 0 22299 mprotect(0x7f422403c000, 4096, PROT_READ|PROT_WRITE) = 0 22299 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} --- Now, I don't think you can get a segfault from mprotect() -- but fact that si_code=SI_KERNEL indicates that the kernel initiated the segfault (if the issue was access within an mprotect() region you should get SI_USER along with a meaningful si_addr). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c26 --- Comment #26 from Aleksa Sarai <asarai@suse.com> --- Oh actually, if you have bpftrace it might be helpful to get a trace when the signal is sent (you'll have to mess with this script a little bit to get useful output): % sudo bpftrace -e 'kprobe:__send_signal /arg0 == 11/ { printf("signal sent (in \"%s\"): %s %s", comm, kstack(), ustack()); }' Hopefully there aren't too many segfaults happening on your system, so you should be able to just get the information about this particular segfault signal being sent. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c27 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(appspotio@gmail.c |needinfo? |om) | --- Comment #27 from seve skeis <appspotio@gmail.com> --- Thank you Aleksa. right now am really busy with exams, @Matei Albu can you help Aleksa with the information's he asks please. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c28 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(asarai@suse.com) --- Comment #28 from seve skeis <appspotio@gmail.com> --- i just installed ``lxd-3.19-lp151.14.1.x86_64`` still same issue. i tried on a digital ocean vm, same issue. i tried on my old laptop, same issue. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c29 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?, | |needinfo?(asarai@suse.com) | --- Comment #29 from Aleksa Sarai <asarai@suse.com> --- Some more information was gleaned after I got SSH access to Matei's system. First of all, the bpftrace output from my script in comment 26 indicated that the first segfault was triggered by a general protection fault: % bpftrace -e 'kprobe:__send_signal /arg0 == 11/ { printf("signal sent (in \"%s\"): %s %s", comm, kstack(), ustack()); }' Attaching 1 probe... signal sent (in "lxd"): __send_signal+1 force_sig_info+168 general_protection+69 0x7fb37d73f960 signal sent (in "lxd"): __send_signal+1 do_send_sig_info+60 do_send_specific+95 do_tkill+135 sys_tkill+21 do_syscall_64+123 entry_SYSCALL_64_after_hwframe+61 0x55c8dc32a4b4 0x55c8dc30e9e4 0x55c8dc30e166 0x55c8dc32a7a3 0x7fb37d73e300 Which is a little bit odd. If you run lxd under GDB you can actually get a backtrace when the first segfault occurs (not the one the Go runtime triggers afterwards), and then you get a much better picture of what's going on: % gdb lxd [... snip ...] Thread 7 "lxd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff08b2700 (LWP 14409)] 0x00007ffff74fe960 in __lll_unlock_elision () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007ffff74fe960 in __lll_unlock_elision () from /lib64/libpthread.so.0 #1 0x00007ffff6e0fd16 in vfs__delete (vfs=<optimized out>, filename=0x7fffd4005ce0 "db.bin-journal", dir_sync=<optimized out>) at src/vfs.c:1629 #2 0x00007ffff7047080 in sqlite3OsDelete (dirSync=<optimized out>, zPath=<optimized out>, pVfs=<optimized out>) at sqlite3.c:22811 #3 pager_end_transaction (pPager=pPager@entry=0x7fffd4005a70, hasMaster=<optimized out>, bCommit=bCommit@entry=1) at sqlite3.c:53099 #4 0x00007ffff7073440 in sqlite3PagerCommitPhaseTwo (pPager=0x7fffd4005a70) at sqlite3.c:57746 #5 sqlite3BtreeCommitPhaseTwo (p=0x7fffd4005580, bCleanup=bCleanup@entry=0) at sqlite3.c:2531 #6 0x00007ffff7080d67 in sqlite3BtreeCommitPhaseTwo (bCleanup=0, p=<optimized out>) at sqlite3.c:79676 #7 vdbeCommit (p=0x7fffd4025c80, db=<optimized out>) at sqlite3.c:14208 #8 sqlite3VdbeHalt (p=p@entry=0x7fffd4025c80) at sqlite3.c:14597 #9 0x00007ffff709dd6f in sqlite3VdbeExec (p=p@entry=0x7fffd4025c80) at sqlite3.c:85638 #10 0x00007ffff709eb31 in sqlite3Step (p=0x7fffd4025c80) at sqlite3.c:82914 #11 sqlite3_step (pStmt=0x7fffd4025c80) at sqlite3.c:17443 #12 0x00007ffff709f8fd in sqlite3_exec (db=0x7fffd4005150, zSql=<optimized out>, zSql@entry=0x7ffff6e112bc "PRAGMA journal_mode=WAL", xCallback=xCallback@entry=0x0, pArg=pArg@entry=0x0, pzErrMsg=pzErrMsg@entry=0x7ffff08ae588) at sqlite3.c:120241 --Type <RET> for more, q to quit, c to continue without paging-- #13 0x00007ffff6e09087 in openConnection (filename=<optimized out>, vfs=<optimized out>, replication=0x7fffe0000b78 "dqlite-1", replication_arg=replication_arg@entry=0x7fffd40050d0, page_size=<optimized out>, conn=conn@entry=0x7fffd40050e8) at src/leader.c:152 #14 0x00007ffff6e0938a in leader__init (l=0x7fffd40050d0, db=0x7fffd4005080, raft=<optimized out>) at src/leader.c:229 #15 0x00007ffff6e08a95 in handle_open (cursor=<optimized out>, req=0x7fffd4003010) at src/gateway.c:160 #16 gateway__handle (g=g@entry=0x7fffd4002ea0, req=req@entry=0x7fffd4003010, type=3, cursor=cursor@entry=0x7ffff08ae790, buffer=buffer@entry=0x7fffd4002fe0, cb=cb@entry=0x7ffff6e05bf0 <gateway_handle_cb>) at src/gateway.c:771 #17 0x00007ffff6e05e80 in read_request_cb (transport=<optimized out>, status=<optimized out>) at src/conn.c:137 #18 0x00007ffff597df9f in ?? () from /usr/lib64/libuv.so.1 #19 0x00007ffff597ed0c in ?? () from /usr/lib64/libuv.so.1 #20 0x00007ffff5983d10 in uv.io_poll () from /usr/lib64/libuv.so.1 #21 0x00007ffff5974688 in uv_run () from /usr/lib64/libuv.so.1 #22 0x00007ffff6e0bff5 in taskRun (d=0x7fffe0000b40) at src/server.c:536 #23 taskStart (arg=0x7fffe0000b40) at src/server.c:550 #24 0x00007ffff74f2569 in start_thread () from /lib64/libpthread.so.0 #25 0x00007ffff6b399ef in clone () from /lib64/libc.so.6 A very quick Google says that a GP fault in __lll_unlock_elision might mean that someone is trying to unlock a mutex which is already locked, but I'll have to look into it more deeply. Nonetheless, this does look like a legit bug in libdqlite. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c30 --- Comment #30 from Aleksa Sarai <asarai@suse.com> --- I found the bug -- it was a bug in dqlite where they would accidentally double-unlock a mutex. I've sent a patch[1], and I'll backport it for testing on Matei's machine. [1]: https://github.com/canonical/dqlite/pull/207 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c31 --- Comment #31 from seve skeis <appspotio@gmail.com> --- Good job, how can i test it? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c32 --- Comment #32 from Aleksa Sarai <asarai@suse.com> --- (In reply to Aleksa Sarai from comment #30)
I found the bug -- it was a bug in dqlite where they would accidentally double-unlock a mutex. I've sent a patch[1], and I'll backport it for testing on Matei's machine.
I've now confirmed that this patch fixes the issue. Sending SRs to Factory and Leap... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c33 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #33 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it: zypper ar -f obs://Virtualization:containers obs-vc And then you do zypper in -r obs-vc lxd And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c35 --- Comment #35 from seve skeis <appspotio@gmail.com> --- (In reply to Aleksa Sarai from comment #33)
(In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it:
zypper ar -f obs://Virtualization:containers obs-vc
And then you do
zypper in -r obs-vc lxd
And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos).
Hi, i do not want to sound weird, but i just tried it from this repo, it is not working, same old problem. ``` systemctl status lxd ● lxd.service - LXD Container Hypervisor Loaded: loaded (/usr/lib/systemd/system/lxd.service; disabled; vendor preset: disabled) Active: activating (start-post) (Result: signal) since Fri 2020-01-31 16:03:19 +03; 1min 14s ago Docs: man:lxd(1) Process: 3324 ExecStart=/usr/bin/lxd --group=lxd --logfile=/var/log/lxd/lxd.log (code=killed, signal=SEGV) Main PID: 3324 (code=killed, signal=SEGV); Control PID: 3325 (lxd) Tasks: 8 Memory: 64.4M CPU: 320ms CGroup: /system.slice/lxd.service └─control └─3325 /usr/bin/lxd waitready --timeout=600 Jan 31 16:03:19 l-beast systemd[1]: Starting LXD Container Hypervisor... Jan 31 16:03:19 l-beast lxd[3324]: t=2020-01-31T16:03:19+0300 lvl=warn msg=" - Couldn't find the CGroup memory swap accounting, swap limits will be ignored" Jan 31 16:03:20 l-beast systemd[1]: lxd.service: Main process exited, code=killed, status=11/SEGV `` -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c36 --- Comment #36 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #35)
(In reply to Aleksa Sarai from comment #33)
(In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it:
zypper ar -f obs://Virtualization:containers obs-vc
And then you do
zypper in -r obs-vc lxd
And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos).
Hi, i do not want to sound weird, but i just tried it from this repo, it is not working, same old problem.
The updated packages haven't been published yet -- see that in [1] the package is listed as "finished" not "succeeded" with a published icon. For some reason, OBS has finished the build (more than 2 hours ago) but hasn't yet published the actual package. We've been having problems with this for the past few weeks, I've got no idea what's going on. You can download the RPMs from here[2] -- but note that this is even more unsafe-to-rely-on than using the development repos. The other option would be to build the package locally using osc. [1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd [2]: https://build.opensuse.org/package/binaries/Virtualization:containers/lxd/op... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c38 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(asarai@suse.com) --- Comment #38 from seve skeis <appspotio@gmail.com> --- (In reply to Aleksa Sarai from comment #36)
(In reply to seve skeis from comment #35)
(In reply to Aleksa Sarai from comment #33)
(In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it:
zypper ar -f obs://Virtualization:containers obs-vc
And then you do
zypper in -r obs-vc lxd
And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos).
Hi, i do not want to sound weird, but i just tried it from this repo, it is not working, same old problem.
The updated packages haven't been published yet -- see that in [1] the package is listed as "finished" not "succeeded" with a published icon. For some reason, OBS has finished the build (more than 2 hours ago) but hasn't yet published the actual package. We've been having problems with this for the past few weeks, I've got no idea what's going on.
You can download the RPMs from here[2] -- but note that this is even more unsafe-to-rely-on than using the development repos. The other option would be to build the package locally using osc.
[1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd [2]: https://build.opensuse.org/package/binaries/Virtualization:containers/lxd/ openSUSE_Leap_15.1 i just installed it from the repo, you mentioned, it complained that libuv1 nothing provides it, i continued then installed from the normal repo, among other packages like dns and cirus ..etc. now bash-completion is not working. and first time launch on a container it freezes the whole system, so i do hard reboot. did you guys face sth similar ?
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c39 seve skeis <appspotio@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(asarai@suse.com) | --- Comment #39 from seve skeis <appspotio@gmail.com> --- (In reply to seve skeis from comment #38)
(In reply to Aleksa Sarai from comment #36)
(In reply to seve skeis from comment #35)
(In reply to Aleksa Sarai from comment #33)
(In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it:
zypper ar -f obs://Virtualization:containers obs-vc
And then you do
zypper in -r obs-vc lxd
And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos).
Hi, i do not want to sound weird, but i just tried it from this repo, it is not working, same old problem.
The updated packages haven't been published yet -- see that in [1] the package is listed as "finished" not "succeeded" with a published icon. For some reason, OBS has finished the build (more than 2 hours ago) but hasn't yet published the actual package. We've been having problems with this for the past few weeks, I've got no idea what's going on.
You can download the RPMs from here[2] -- but note that this is even more unsafe-to-rely-on than using the development repos. The other option would be to build the package locally using osc.
[1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd [2]: https://build.opensuse.org/package/binaries/Virtualization:containers/lxd/ openSUSE_Leap_15.1 i just installed it from the repo, you mentioned, it complained that libuv1 nothing provides it, i continued then installed from the normal repo, among other packages like dns and cirus ..etc. now bash-completion is not working. and first time launch on a container it freezes the whole system, so i do hard reboot. did you guys face sth similar ?
1. i confirm the hangout after container creation was a cause of bridge mis-configuration. am stuck with bash-complation now. 2. i do not know if this is a bug or it is the way it should be. after creating a container using an lxd user, then the created container should use that user subgid and subuid in its conf file no? but i notice it only uses the root subuid subgid. i made sure /etc/subuid /etc/subgid has an entry for the user creating the containers and its a member of lxd group too. please correct me here. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c40 --- Comment #40 from Aleksa Sarai <asarai@suse.com> --- (In reply to seve skeis from comment #39)
(In reply to seve skeis from comment #38)
(In reply to Aleksa Sarai from comment #36)
(In reply to seve skeis from comment #35)
(In reply to Aleksa Sarai from comment #33)
(In reply to seve skeis from comment #31)
Good job, how can i test it?
I'm about to send an SR (so you'll need to wait a bit for the build to finish), but you can add the development repo for lxd to test it:
zypper ar -f obs://Virtualization:containers obs-vc
And then you do
zypper in -r obs-vc lxd
And you'll get the development version of LXD. Note that you should undo this afterwards since the development versions of LXD could break (you should stick with the Leap repos).
Hi, i do not want to sound weird, but i just tried it from this repo, it is not working, same old problem.
The updated packages haven't been published yet -- see that in [1] the package is listed as "finished" not "succeeded" with a published icon. For some reason, OBS has finished the build (more than 2 hours ago) but hasn't yet published the actual package. We've been having problems with this for the past few weeks, I've got no idea what's going on.
You can download the RPMs from here[2] -- but note that this is even more unsafe-to-rely-on than using the development repos. The other option would be to build the package locally using osc.
[1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd [2]: https://build.opensuse.org/package/binaries/Virtualization:containers/lxd/ openSUSE_Leap_15.1 i just installed it from the repo, you mentioned, it complained that libuv1 nothing provides it, i continued then installed from the normal repo, among other packages like dns and cirus ..etc. now bash-completion is not working. and first time launch on a container it freezes the whole system, so i do hard reboot. did you guys face sth similar ?
1. i confirm the hangout after container creation was a cause of bridge mis-configuration. am stuck with bash-complation now.
If bash-completion isn't working, please open a new bug with a description of the problem (I don't personally use bash -- so it's entirely possible I screwed up the bash-completion installation).
2. i do not know if this is a bug or it is the way it should be. after creating a container using an lxd user, then the created container should use that user subgid and subuid in its conf file no? but i notice it only uses the root subuid subgid. i made sure /etc/subuid /etc/subgid has an entry for the user creating the containers and its a member of lxd group too. please correct me here.
The way we set up /etc/sub[ug]id in the package is correct and will work out of the box. LXD always[*] uses root's subid configuration because it is running as the root user -- it is not running as the user running "lxc" commands. There are also a bunch of other annoying technical reasons why this is done this way ("lxd" is a server and the client could be on a different machine -- in that case, there is no way to associate the user running "lxc" with user on the LXD host). There's nothing wrong with setting up your own subid configuration (though it's not a good idea to overlap the LXD ones with your own users', because it allows your user to gain privileged access to the containers) but it's not necessary. [*}: Except if you're running under snap. In those cases, LXD has special handling but that really doesn't matter right now. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c41 --- Comment #41 from Aleksa Sarai <asarai@suse.com> --- (In reply to Aleksa Sarai from comment #40)
(In reply to seve skeis from comment #39)
1. i confirm the hangout after container creation was a cause of bridge mis-configuration. am stuck with bash-complation now.
If bash-completion isn't working, please open a new bug with a description of the problem (I don't personally use bash -- so it's entirely possible I screwed up the bash-completion installation).
Never mind, I just tried to use it with bash and you're right that it just doesn't work at all. I'll take a look at this next week. Opened boo#1162426 to track that. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156336 http://bugzilla.opensuse.org/show_bug.cgi?id=1156336#c48 Aleksa Sarai <asarai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #48 from Aleksa Sarai <asarai@suse.com> --- Fixed in Factory and currently in Leap staging. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com