secureboot blocking custom modules would be my guess
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.
Right, you can stop the VM, set security.secureboot=false and start it back up.
Thank you very much .
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.
Thank you very much so far.
You and stgraber helped me a lot today .
@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?