3 ms·
But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later.
by asveikau 6y ago
But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later.
At least, I have heard this explanation in the context of OpenBSD, and assume it may also apply to FreeBSD.
- Mister_Snuggles 6y agoI believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens. To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works. [0] https://www.freebsd.org/cgi/man.cgi?beadm https://www.freebsd.org/cgi/man.cgi?beadm [1] https://news.opensuse.org/2018/05/15/transactional-updates-in-opensuse-leap-15/ https://news.opensuse.org/2018/05/15/transactional-updates-i...
- asveikau 6y agoThe situation on linux is actually different because the kernel and glibc are maintained separately and the syscall ABI is treated as a boundary between components. Any time a new syscall is wrapped the userland maintainers need to account for what happens when run on an old kernel and typically have some fallback logic.