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.
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.
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.
Yeah windows “cumulative update” upgrades for the past couple of years basically duplicate the whole system directory and apply the update to that leaving the existing one to roll back to if anything fails
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.
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 :)
sure, but what os wouldn’t break if you did this?
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.
So what I’m hearing is install Linux-LTS and pacsnap
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.
In Windows you can also fix this with a live Windows USB, manually.
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.
good answer to a bad and uninformed question, thanks.
Debian and Ubuntu are not immutable distributions by default, unless I am mistaken.
Any immutable distro and Debian and Ubuntu and all their derivatives
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.
Ohh, I’m dumb
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?
Yeah windows “cumulative update” upgrades for the past couple of years basically duplicate the whole system directory and apply the update to that leaving the existing one to roll back to if anything fails
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
postinstscript for a package fails.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 thelinuxpackage, so you always have a bootable fallback, but like most things on Arch it’s not enforced.That’s pretty wild, I guess arch is not meant to hold your hand at all so it makes sense.
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.
renameat2has the EXCHANGE flag to atomically switch 2 files, so if arch maintainers want to fix it they could doI read this as “rena meat 2” and was very confused
it was btrfs.
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 :)