That seems to be the one advantage separating kernel from user space has provided. At least in my experience, jails may break when the host OS gets updated and the jail isn’t upgraded in lock step. That means having 1+n upgrades for every minor version update.
Requiring a docker container to have a user space which matches the kernel kind of defeats the purpose.
This shouldn't normally happen, generally you can run a new kernel with an older userland (the documented upgrade process for the main root is upgrade kernel, reboot, upgrade userland, so at least part of userland needs to still work), and a chroot jail is mostly an independent userland. You may need to ensure the kernel is compiled with backwards compatability if your userland is very far off, and sometimes you see problems with syscall details: 13.0 released with a bug that some ifconfig arguments wouldn't work with a 12.x binary; and I've run into problems with the cpu pinning syscall when the bitmask size increased (this was recently fixed upstream, although I ran into it years ago), etc, so it's not unheard of, but it's fairly rare, in my experience.
Comments
That seems to be the one advantage separating kernel from user space has provided. At least in my experience, jails may break when the host OS gets updated and the jail isn’t upgraded in lock step. That means having 1+n upgrades for every minor version update.
Requiring a docker container to have a user space which matches the kernel kind of defeats the purpose.
This shouldn't normally happen, generally you can run a new kernel with an older userland (the documented upgrade process for the main root is upgrade kernel, reboot, upgrade userland, so at least part of userland needs to still work), and a chroot jail is mostly an independent userland. You may need to ensure the kernel is compiled with backwards compatability if your userland is very far off, and sometimes you see problems with syscall details: 13.0 released with a bug that some ifconfig arguments wouldn't work with a 12.x binary; and I've run into problems with the cpu pinning syscall when the bitmask size increased (this was recently fixed upstream, although I ran into it years ago), etc, so it's not unheard of, but it's fairly rare, in my experience.