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.
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?
β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.
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 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.
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.
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?
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.
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.
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.
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.
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!
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.
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.
shutdown
βshut downβ, here. βShutdownβ is a noun missing a hyphen.
