Greetings, Koehler! > I am unclear how this answers my current questions. System containers are > marketed as being very close to a faster VM, as such, since I do have > control over the OS I am trying to run on top, I would need more details as > to why and which areas would cause the technical issues to achieve such > thing.
System container != kernel virtualization. > The fact that the System container shares the kernel here is totally > what I am looking for, there is also no other application running on the > host except that container and snapd itself which should not be a problem > as it removes any race where one app may changes kernel-related > configuration from under the OS within the container. They aren't "sharing kernel", they are layer on top of it. > I do understand that this is unconventional and doesn't appear to fall > under the supported scenarios. Yet, so far the issue I am facing does not > appear related to my final goal. It's not "unconventional", it's not intended and contradictory. > Can't execute any command within container -> permission denied (files are > all uid/gid 0) this is a busybox type of OS on same CPU architecture (both > armhf where host is arm64, yet metadata provided indicate that container > should be armhf)Still seeing issue trying to write /proc and even though I > say mount rw I get read-only errorsFail to load the kernel module even > though I have clear the cap.drop as to keep cap_sys_modules. See above. If you want kernel virtualization, use a VM. QEMU/KVM is there for you. -- With best regards, Andrey Repin Tuesday, June 16, 2020 2:07:03 Sorry for my terrible english... _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users