You must log in or register to comment.
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.
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.
sure, but what os wouldn’t break if you did this?
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.
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)
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 :)
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.
- Boot to usb
- Mount your root filesystem
arch-chrootyour mounted root filesystem- mount
/boot mkinitcpio -p linux
Steps 1,2 and 3 are the entry way to solve all “unbootable Arch” problems by the way, presuming you know what needs to be changed to fix it of course.
For a while, I had to do this after every kernel update
Turns out, i accidentally had two
/bootfolders. One was is own partition, and the other was on the rootfs partition. When Arch booted, the separate partition was mounted over the rootfs/bootdir, “shadowing” itExcept, 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
I’d gladly take an Arch wiki article
shutdown
‘shut down’, here. ‘Shutdown’ is a noun missing a hyphen.
MFW I say more than “L2S” and get downvoted by projectors.
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)
This is why you keep a backup kernel
Ive been here. U can use a bootable usb to boot. Then use switch root to change to ur actual filesystem (I’m glossing over a lot of complications here ask chatgpt) and update from here or just copy over the kernal.
ask chatgpt
You mean read the Arch wiki?
I’m not even an Arch user (I use Debian and Fedora) but the Arch wiki is amazing.
I mean ask the self hosted dolphin finetuned mistral 8x22b but chatgpt is easyer to say.
Why the fuck are you asking an LLM to help you fix your Linux install – especially a tiny one that gets facts wrong as often as Dolphin does – when archwiki is right there?
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.
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.
Debian and Fedora are solid on the desktop
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!
“Arch is stable”
It is! My Desktop hardly ever topples over!
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.
