Any immutable distro, Debian, Ubuntu, all their derivatives, Fedora, all its derivatives, OpenSUSE, Slackware, …
Basically, 95+% of installed Linux systems would retain the old or a backup kernel during an upgrade.
Any immutable distro, Debian, Ubuntu, all their derivatives
Debian and Ubuntu are not immutable distributions by default, unless I am mistaken.
They weren’t saying Debian and Ubuntu are immutable - they were saying “any immutable distro”, “Debian”, and “Ubuntu” as three separate items in a list.
Windows doesn’t in my experience, it’s surprisingly robust.
But also I thought Linux distros normally keep the old Kernel around after an update so stuff like this doesn’t cause a boot failure?
Windows updates (and Windows Installer) are transactional. If the update or installation fails, it knows exactly how to revert back to the previous state.
Windows Installer supports this across multiple packages too - for example, a game might need some version of DirectX libraries which needs some version of the Visual C++ runtime (probably showing my age because I doubt games come bundled with DirectX any more). If one of the packages fails to install, it can handle rolling everything back. Linux can sometimes leave your system in a broken state when this happens, requiring you to manually resolve the issue - for example, on a Debian-based system if the postinst script for a package fails.
But also I thought Linux distros normally keep the old Kernel around after an update so stuff like this doesn’t cause a boot failure?
Arch has no concept of “previous package”, so it doesn’t do this.
You could install linux-lts (or one of the other alternative kernels) side by side with the linux package, so you always have a bootable fallback, but like most things on Arch it’s not enforced.
Just about any Linux I’ve ever used keeps the previous kernel version and initrd around. And nowadays snapper makes a new snapshot before and after every package installation or update.
So, I’d think there are a lot.
If it was on something like BTRFS it’d probably be fine, though I imagine there’s still a small window where the FS could flush while the file is being written. renameat2 has the EXCHANGE flag to atomically switch 2 files, so if arch maintainers want to fix it they could do
- Write to temporary file
- Fsync temporary file
- Renameat2 EXCHANGE temporary and target
- Fsync directory (optional, since a background flush would still be atomic, just might take some time)
Just having btrfs is not enough, you need to have automatic snapshots (or do them manually) before doing updates and configured grub to allow you to rollback.
Personally, I’m to lazy to configure stuff like that, I rather just pick my Vetroy USB from backpack, boot into live image and just fix it (while learning something/new interesting) than spend time preventing something that might never happen to me :)
Plus in Linux you can actually fix this with a live USB, while on Windows you can run startup repair and hope for the best.
