Why update on that little battery life left... the power will return sooner or later, going without updates even for a week or two is no real problem. Hell, I update like once every 3 weeks to a month, it's not that big of a deal.
It first downloads all packages from net, then it proceed totally offline starting by verifying downloaded files, signatures, extracting new packages and finally rebuilding initramfs.
Because arch is replacing the kernel and inittamfs in-place there is a chance that it will not boot if interrupted.
This issue was long resolved on other distro.
One way to mitigate it is by having multiple kernels (like LTS or hardened) that you can always pick in grub if the main one fail.
Cable internet tends to stay online even if your power is out. You'd need a battery backup for your modem/router, but it is possible to stay online. Houses can be clever like that, almost all of your utilities will partially work, even when service is interrupted.
I don't think I've had a pacman update take longer than 10 minutes before. Sounds like OP was updating all their AUR packages too.
Still absolutely a terrible thing to do on 10% battery life. I bet there's an AUR package for "check battery level before update" out there somewhere though.
OPs meme is "use distro whose model is 'give users enough rope to hang themselves' " and complaining he's at the gallows
Pacman is very fast. The tradeoff is that it isn't as "thoughtful" when it runs. It doesn't have the same protections as apt or dnf. I especially like dnf as you can undo any operation.
Power outages do happen, and I'm pretty sure 90% of the people on this community are not using an UPS.
Given enough users and enough time, it's inevitable that a power outage will happen to some people at an inopportune moment, like while updating an important package like the kernel.
Blaming the user for this is not fair, it's just dumb bad luck.
That said, OP could have done a bit more to fix the issue instead of being an angry man yelling at the cloud. When you're using Arch, the expectation is that you are able to fix relatively simple problems like this, or that you're at least willing to learn it. If you find yourself getting angry when Arch doesn't hold your hand, you probably shouldn't have chosen Arch.
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.
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.
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)
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 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.
For a while, I had to do this after every kernel update
Turns out, i accidentally had two /boot folders. One was is own partition, and the other was on the rootfs partition. When Arch booted, the separate partition was mounted over the rootfs /boot dir, "shadowing" it
Except, UEFI / GRUB was still pointing to the rootfs partition. So when pacman installed a kernel update, it wasn't able to update the kernel that UEFI was booting, but it was able to update the kernel modules
Kernel no likey when kernel modules are newer than the kernel itself
So I'm trying to understand if you think that shutting down an update during regenerating the initramfs indicates that Arch isn't stable? Because that's a FAFO move and would crater any non-atomic update distro.
When talking about Linux, "stable" usually means "doesn't have major changes often", or in other words, "doesn't have lots of updates that break stuff". That's why "Debian stable" is called that. Arch is not that.
If you're planning for this type of failure, what you probably want instead is Aurora from the Universal Blue project. Since it's fedora silverblue underneath, your OS either updates all at once or doesn't.
When I used Arch I updated once and it removed the running kernel and its modules. So when I plugged in a webcam it didn't work, since the module was gone.
Not a catastrophe, but it was an off-putting user experience coming from Debian. Arch felt more like a desktop OS, Debian feels more like a server OS to me (updates generally warn/confirm when you need to restart services or the machine).
To each their own! Having more up to date stuff was a nice perk of running Arch, certainly.
Oh I love Debian on the desktop! More a comment on the feeling of the OS being very concerned about downtime and stability, with minimal "surprises." Not a bad thing at all!
This got me looking to see if there is any way to have a fallback as I have had something similar happen to me.
The general advice is to have a liveboot USB around. I even saw that you can have GRUB simply boot from an .iso file on the internal drives, which eliminates the need to keep a USB stick around.
I haven't followed the steps yet but I'll give this a shot because it intrigues me.
I was installing Nobara 40 and discovered that the live session is allowed to suspend the PC during the install process. The system ended up having problems with some basic functions...
In a comment he clarified that the laptop was plugged in and there was a power failure. Regardless, chrooting in should be a fairly straightforward fix.