Search results

No. To be clear about this: the whole point of cloud init is supposed to be that we do not need to care about the distribution or even the OS inside the machine. The point of cloud init is to take some kind of configuration input, run it through the matching frontend, to produce an internal...

You can, however, get rid of it by adding an /etc/systemd/network/XY-default.link (XY being a number < 99 and > your own (if you have any) with: [Link] NamePolicy=kernel database onboard slot path MACAddressPolicy=none

Please update the pve packages, make sure lxc-pve is >= 2.1.1-3

The machine is stopped to put it in a consistent state (OS shutdown, disks cleanly unmounted etc.), then started again, and the qemu process itself performs the backup while letting the guest run, backup up blocks the guest wants to write to early to not stall it for too long. Well that's not...

Do you get any output when you start the VMs from the command line via `qm start $vmid`?

It would probably be better that way, but given that it's using 0666 permissions it shouldn't be much of an issue for 99% of the cases. I'll ask upstream.

It'll get more confusing in the future - cgroup v2 separated memory and swap ;-) (then again the adoption of that is going about as fast as the adoption of ipv6...)

lxc-pve >= 3.0.0-3 should be available in the pvetest repository fixing this issue, please test.

Right. More info would be useful. (And eg. if you put an interface onto a bridge you shouldn't also give it the IP address. That should be only on the bridge (including the dns settings).) Actually, if you don't need to do anything more complex I recommend not putting files in...

Once thing I noticed: bridge_ports eth0 while your interface's actual name is enp0s25 Other than that, you'll have to be more specific as to what's not working ;-)

There was a change to support mounting without gid=5 for unprivileged containers which have gid 5 not mapped. Upstream has already fixed this in the git-master branch, and we'll probably build a fixed package soon.

Next time this happens, can you please post the output of `systemctl status $vmid.scope` before doing a systemctl kill to see which processes are running in the scope.

We'll update lxcfs on pve4 to 2.0.8 soon which should include the fix for this.

There's a long term plan to try to test rules better when applying them to find a way to somehow mark them on the UI or at least show specifically which rule doesn't work in the logs, but the low level tools make this quite difficult/inconvenient so for now this isn't happening - we're trying to...

Some more error output / logs would be useful. Do you see anything in the syslog when doing this (host & guest)?

A quick glance over the compile.txt shows a rather long multiport line (in the 'cpanel' group's input). pve-firewall >= 3.0-6 should actually complain about this when entering it, see if it works when you remove it, if that helps, split it into multiple rules.

lxc.aa_profile was renamed to lxc.apparmor.profile

Gibt es - und funktioniert - /lib/systemd/systemd im container? Der Fehler-ausgabe von lxc nach müsste entweder das file nicht existieren - oder IIRC wenn der linker ein library nicht findet gibt es den fehler auch: # chroot --userspec=nobody /var/lib/lxc/101/rootfs /lib/systemd/systemd --help...

You could check if a vlan-aware linux bridge with `/sys/class/net/vmbr0/bridge/vlan_protocol` set to 0x88a8 would work. We do currently only expose the vlan filtering flag in the network settings, adding the vlan protocol might be useful for some. Currently this has to be added manually with...

Sinnvollerweise hab ich beim `ls` den `/` for `sbin/init` dazugeschrieben was natürlich falsch ist und den symlink vom host statt dem container zeigt. (also eigtl hätte es nach dem `cd` dann `ls -ld sbin sbin/init` (ohne den vorangestellten slashes) heißen müssen).