I have LTS and zen kernels installed in addition to the default Arch one, that should prevent this yes?
I'm not sure - I had zen and the default kernel and both were inaccessible
The power is out and my laptop has less than 10% battery left?
It's pacman -Syu time.
Exactly my thoughts as well.
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.
Wait if the power is out, how do they have Internet to load new packages? Something doesn't make sense here
My router has a 5G backup connection and a battery. Light could be out and I'd still have internet. So, yeah, it's possible :P
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.
Cellular data
What about a desktop PC?
shutdown a computer when you shouldn’t computer breaks
how could a computer do this
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.
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?
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.
renameat2has 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.
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.
Out of curiosity: Which operating system(s) can you shutdown while the kernel is being overwritten? I wouldn't imagine that as a limitation of Arch Linux specifically.
I think fedora would survive this abuse. It doesn't replace when you install kernels, but instead adds it.
Mint definitely keeps a couple of previous kernels around, so that might be a Debian and Ubuntu thing too.
That said, there's always going to be a critical point of failure that a power loss could cause things to break, no matter your OS or distro.
Writing the bootloader or updating a partition table for example.
Arch Linux with 2 kernels ;)
Anything running on a copy-on-write filesystem can trivially rollback changes using a rescue partition.
I also expect most immutable distros would be able to be especially good at tanking this.
Windows
Goes back to a previous restore point
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.
https://www.linuxbabe.com/desktop-linux/boot-from-iso-files-using-grub2-boot-loader
I always have a separate huge kernel on hand that boots without an initrd.
Or you could just install NixOS for update rollbacks (or use zfs/btrfs and set an alias to take snapshots whenever you update)
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...
That's why UPS boxes exist .. Or Timeshift if you don't have the cash
Image says "laptop". op could have just charge the battery a but before running the update.
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.
If the laptop is upgrading the kernel so slowly it shuts down in the middle of a power outage it's probably old as hell and has barely any battery to charge.
