Closed antifob closed 2 years ago
For one thing, you probably meant to push to /etc/hosts
and not /hosts
:)
The error showed here would make sense if the agent in the VM was outdated which shouldn't be possible if the VM got restarted since the host was moved to 5.0. That's unless the VM agent binary was somehow manually installed and is running an old version?
stgraber@dakara:~$ lxc launch images:centos/9-Stream centos9 --vm
Creating centos9
Starting centos9
stgraber@dakara:~$ lxc file push /etc/hosts centos9/
stgraber@dakara:~$ lxc exec centos9 bash
[root@centos9 ~]# cat /hosts
127.0.0.1 localhost
127.0.1.1 dakara
172.17.250.151 ceph01
172.17.250.103 ceph02
172.17.250.162 ceph03
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
[root@centos9 ~]#
I had to triple (I already had) check what I wrote, my command and its output. Unless I'm missing the point, lxc file push /etc/hosts centos9/
does, indeed, produce /1.0/instances/centos9/files?path=%2Fhosts
. I didn't check the API, but I would assume the %2fhosts
is the target. :)
Anyway, I had discarded the possibility of an outdated lxd-agent already. The image dates from March 1st from images:
and the agent has not been tampered with in any way. In fact, its hash were/is the same.
# lxc info centos9
Name: centos9
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 8404
Created: 2022/03/01 06:24 UTC
Last Used: 2022/04/28 05:17 UTC
[...]
# lxc exec centos9 -- sha1sum /run/lxd_agent/lxd-agent
acadfe9ee6ab461c5bd39ef29182ea60d89bb240 /run/lxd_agent/lxd-agent
# lxc exec bullseye -- sha1sum /run/lxd_agent/lxd-agent
acadfe9ee6ab461c5bd39ef29182ea60d89bb240 /run/lxd_agent/lxd-agent
I also ruled out the following:
# lxc exec centos9 -- sestatus
SELinux status: disabled
@antifob what happens if you run the same commands I did?
# lxc launch --vm images:centos/9-Stream c9
Creating c9
Starting c9
# lxc file push /etc/hosts c9/
# lxc exec c9 -- cat /hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
# lxc exec c9 -- sha1sum /run/lxd_agent/lxd-agent
acadfe9ee6ab461c5bd39ef29182ea60d89bb240 /run/lxd_agent/lxd-agent
And on the broken VM, you've confirmed that sha256sum /proc/$(pgrep lxd-agent)/exe
shows the same hash too?
Good catch @stgraber
lxd-agent.service
was running /usr/local/bin/lxd-agent
. If I may, could you tell me if it was ever stored there? I'm undecisively tracing this back to a potential issue with SELinux at the time and wondering if I should investigate more than destroying the VM.
[root@localhost ~]# stat /usr/local/bin/lxd-agent
File: /usr/local/bin/lxd-agent
Size: 15764335 Blocks: 30792 IO Block: 4096 regular file
Device: 802h/2050d Inode: 20522 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-04-29 14:23:25.333000000 +0000
Modify: 2022-03-01 06:31:50.717000000 +0000
Change: 2022-03-01 06:31:50.721000000 +0000
Birth: 2022-03-01 06:31:50.701000000 +0000
[root@localhost ~]# sha256sum /usr/local/bin/lxd-agent
89bbe4e5607e99df52eaf36d9fea75010d546d47c6e981a8bed204d53f1a7e9f /usr/local/bin/lxd-agent
We never put the agent at that location. Our scripts have always loaded it from the 9p or virtiofs share specifically to avoid such issues :)
Required information
Issue description
Using
lxc file push
to copy a file over to a local VM fails. The exact same operation works to another, Ubuntu-based, VM.Steps to reproduce
Information to attach
dmesg
)lxc info NAME --show-log
)lxc config show NAME --expanded
)lxc monitor
while reproducing the issue)