I think I didn’t make it clear enough: My laptop was on the power during the update process, when the power randomly cut out - for the first time in about 6 years, it doesn’t happen often. Of course you can interpret it as user error - but I think it’s reasonable to update my system when plugged into, normally reliable power. The laptop battery is pretty much dead, so it would’ve shut itself down automatically anyway.
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.
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.
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.
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 :)
I still don’t get the problem. Are you complaining you have to chroot into your system and finish the update because your power got interrupted? Is a 5 min detour into a live system making you unconfortable? This is how you would fix it in any distro except the image based ones and the arch wiki will guide you excellently how to do it. Good luck!
I mean any which way you try to frame this, saying that you won’t use Arch anymore because you didn’t take the precautions necessary based on your situation is gonna take some heat here.
What precaution would you expect OP to would’ve done though?
A fallback kernel would be my guess - that’s something many casual oriented distro do out of the box basically.
. I read your post as “you’re right, don’t use arch” - something btw which I tend to agree with although I wouldn’t say that’s because of the precautions.
I use arch because there’s no black box magic. For an end user who expects or wants that… Yes, arch might not be the right choice.
Oh agreed! That’s why I’m with OP actually that arch might not be the right distro to go for.
The person I replied to basically said “that’s what you deserve for not doing it properly” if I understood it correctly - that’s what I’m confused about as well.
If you know your battery is shot and you don’t have a way to save your install if the power goes out, then you just don’t update. There are plenty of ways to protect against this that have already been mentioned (battery backup, backup kernel, etc). OP was just playing with fire.
That’s kind of overzealous. I would expect most desktop users to run kernel updates without being plugged into a UPS, this is functionally identical. It’s not like it’s an unrecoverable error, but yeah if you’re updating a critical system you should have redundancies in place.
Disclaimer: this only works when something with image creation goes wrong with an update. Which didn’t happen to me ever - unless I did a mistake or tested some kernel stuff.
I only had bootloader errors when I screwed up pacman though.
The fallback kernel in that case is on a USB stick…
I don’t really get why you couldn’t pick one of your other installed kernels and boot that, but you seem pretty intent on blaming arch and I don’t feel like trying to troubleshoot it, so that’s that I guess.
I think I didn’t make it clear enough: My laptop was on the power during the update process, when the power randomly cut out - for the first time in about 6 years, it doesn’t happen often. Of course you can interpret it as user error - but I think it’s reasonable to update my system when plugged into, normally reliable power. The laptop battery is pretty much dead, so it would’ve shut itself down automatically anyway.
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.
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.
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.
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.
Ohh, I’m dumb
deleted by creator
Any immutable distro and Debian and Ubuntu and all their derivatives
good answer to a bad and uninformed question, thanks.
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 :)
I still don’t get the problem. Are you complaining you have to chroot into your system and finish the update because your power got interrupted? Is a 5 min detour into a live system making you unconfortable? This is how you would fix it in any distro except the image based ones and the arch wiki will guide you excellently how to do it. Good luck!
I mean any which way you try to frame this, saying that you won’t use Arch anymore because you didn’t take the precautions necessary based on your situation is gonna take some heat here.
What precaution would you expect OP to would’ve done though? A fallback kernel would be my guess - that’s something many casual oriented distro do out of the box basically. . I read your post as “you’re right, don’t use arch” - something btw which I tend to agree with although I wouldn’t say that’s because of the precautions.
I use arch because there’s no black box magic. For an end user who expects or wants that… Yes, arch might not be the right choice.
I don’t think lack of precaution was the issue here given that it was an unexpected power failure, but it is a fairly easy fix with a chroot.
Oh agreed! That’s why I’m with OP actually that arch might not be the right distro to go for.
The person I replied to basically said “that’s what you deserve for not doing it properly” if I understood it correctly - that’s what I’m confused about as well.
Yeah it seems half the commenters missed OP’s clarifying comment and just think he started a kernel update with 2% battery life.
Hehe true. And even that happened to me after a couple of tired “Syu enter”. But then again I learned something new with nearly every repair!
If you know your battery is shot and you don’t have a way to save your install if the power goes out, then you just don’t update. There are plenty of ways to protect against this that have already been mentioned (battery backup, backup kernel, etc). OP was just playing with fire.
That’s kind of overzealous. I would expect most desktop users to run kernel updates without being plugged into a UPS, this is functionally identical. It’s not like it’s an unrecoverable error, but yeah if you’re updating a critical system you should have redundancies in place.
How would you set up a fallback kernel in Arch?
I have set up an lts kernel in addition to the zen I use by default. See:
https://wiki.archlinux.org/title/Kernel
Disclaimer: this only works when something with image creation goes wrong with an update. Which didn’t happen to me ever - unless I did a mistake or tested some kernel stuff. I only had bootloader errors when I screwed up pacman though. The fallback kernel in that case is on a USB stick…
I don’t really get why you couldn’t pick one of your other installed kernels and boot that, but you seem pretty intent on blaming arch and I don’t feel like trying to troubleshoot it, so that’s that I guess.
How dead are we talking here? Even on an older laptop a kernel update doesn’t take that long. Should have just kept it going, hoping for the best.
I am using an old laptop that gives me 3 minutes to run from one power plug to the other before just going out.