LXD VM problems - LXD-agent connect fail & shiftfs for lxd inside vm

Thats the key.
Sry I should have checked that first by myself, it looks like secure boot is the problem:

1111.914973] Lockdown: modprobe: unsigned module loading is restricted; see SecureBoot - Debian Wiki

Right, you can stop the VM, set security.secureboot=false and start it back up.

2 Likes

Right, you can stop the VM, set security.secureboot=false and start it back up.

Thank you very much :grinning:.

No, it is not running, and it seems it is not even in the list.

systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

The service is not even visible in the list of systemctl…

Can you run these commands inside the VM please:

mount -t 9p config /mnt
cd /mnt
./install.sh
reboot

In order to get in, you either need to attach the config drive and use cloud-init or modify the disk image to have the password set.

The problem is, I have no root in the console.
Its wants a password for root which is not set (or unknown to me).
I will try to set or change the root password after restart.

Ah.
That will probably take me some time.
But thanks so far.
What is the config drive? (sry for not knowing)

So I can’t get in as root through “lxc console”?

Can you show me how you created your VM, I would like to check the agent is starting OK here.

The config drive is a CDROM that is attached to the VM guest and allows cloud-init inside the VM to read the cloud init config from LXD, which can then be used to set a login password.

See the " Extra steps for official Ubuntu images" section in Running virtual machines with LXD 4.0 (although in principle its not limited to ubuntu images).

lxc launch images:debian/11 kerneltest2 --vm

Thanks, I’ve re-created the issue here too.

Ok.
And did your workaround with manual mounting work?

I’m seeing this:

Apr 24 15:29:49 kerneltest2 systemd[1]: Condition check resulted in LXD - agent 
- 9p mount being skipped.
Apr 24 15:29:49 kerneltest2 systemd[1]: Condition check resulted in LXD - agent 
being skipped.

Suggests that /dev/virtio-ports/org.linuxcontainers.lxd doesn’t exist, although it does from what I can see, so perhaps its not present at the time lxd-agent tries to start.

Interesting,
I know nothing about this, but it is then just a problem in the “boot order” in systemd?

Question for continuation of my experiment:
I guess it is not a problem in the ubuntu VMs?
In that case I could use them(?)

The Ubuntu VMs should work fine, if you use the images:ubuntu/focal then it includes the agent by default.

1 Like

Thank you very much so far.
You and stgraber helped me a lot today :grinning: .

@stgraber If I remove ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd from the /lib/systemd/system/lxd-agent-9p.service then the agent starts OK on boot.

So something is delaying that file from being present and the lxd-agent-9p service unit is starting early enough to miss it. But apparently this doesn’t affect Ubuntu VMs.

@stgraber perhaps a udev delay?

Possibly, that’s a bit weird and hasn’t really showed up in our automated tests, but yeah, could be racy somehow.

Unfortunately I don’t think an After= would help since it wouldn’t even be considered.