You must log in or # to comment.
- 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.
I’d gladly take an Arch wiki article
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
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.
“Arch is stable”
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.
It is! My Desktop hardly ever topples over!
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.
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?
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 :)
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.
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 mean ask the self hosted dolphin finetuned mistral 8x22b but chatgpt is easyer to say.
