I’m not familiar with Arch’s updating scheme, but I’d bet that it’s pretty similar to Red Hat’s and Debian’s. If you don’t complete an update, boot it up — even if it’s in a semi-broken state — and just start the update again. Even if the thing dies right in the middle of updating something boot-critical, so that it can’t boot, you can probably just use liveboot media, mount the drives in question, start a chrooted-to-your-regular-root-partition root shell, and restart the update.
Doing that and installing or reinstalling packages is a pretty potent tool to fix a system. It’s not absolutely impossible that you can manage to hork a system up badly enough to render it still unusable in that situation — I once wiped ld.so from a system, for example, and had to grab another copy and manually put it in place to get stuff dynamically-linked stuff like the package manager working again. But that’ll deal with the great majority of problems you could create.
I’ve done this countless times. My case was weird since I had a monitor that managed to regularly destroy my system but the gist is the same.
Got to a point where I put a text file on my live stick to copy-paste the commands to untangle the clusterfuck. Could probably format it to a bash script but I’m lazy ¯\(ツ)/¯
Yes, BTRFS combined with auto snapshots whenever you make system changes. So if you install a package, remove a package, or adjust anything like network settings or services, etc. you then have a snapshot to rollback to. Also, auto cleanup based on time or number of snapshots.
So out-of-the-box even as a new Linux user if you make a mess you just reboot to an earlier time, (which is read-only at first) if all is good and functions as you like you do a
sudo snapper rollback
And your current snapshot you are in becomes the bootable default.
I’m not familiar with Arch’s updating scheme, but I’d bet that it’s pretty similar to Red Hat’s and Debian’s. If you don’t complete an update, boot it up — even if it’s in a semi-broken state — and just start the update again. Even if the thing dies right in the middle of updating something boot-critical, so that it can’t boot, you can probably just use liveboot media, mount the drives in question, start a chrooted-to-your-regular-root-partition root shell, and restart the update.
Doing that and installing or reinstalling packages is a pretty potent tool to fix a system. It’s not absolutely impossible that you can manage to hork a system up badly enough to render it still unusable in that situation — I once wiped ld.so from a system, for example, and had to grab another copy and manually put it in place to get stuff dynamically-linked stuff like the package manager working again. But that’ll deal with the great majority of problems you could create.
I’ve done this countless times. My case was weird since I had a monitor that managed to regularly destroy my system but the gist is the same.
Got to a point where I put a text file on my live stick to copy-paste the commands to untangle the clusterfuck. Could probably format it to a bash script but I’m lazy ¯\(ツ)/¯
That’s why I like OpenSUSE. If anything went wrong and system couldn’t boot properly you just choose an older snapshot.
Isn’t that because of BTRFS? I also use Snapshots on my Arch system
Basically, yes. OpenSuse is nice because it comes with everything already set up, including bootable snapshots through the bootloader.
Yes, BTRFS combined with auto snapshots whenever you make system changes. So if you install a package, remove a package, or adjust anything like network settings or services, etc. you then have a snapshot to rollback to. Also, auto cleanup based on time or number of snapshots.
So out-of-the-box even as a new Linux user if you make a mess you just reboot to an earlier time, (which is read-only at first) if all is good and functions as you like you do a
sudo snapper rollback
And your current snapshot you are in becomes the bootable default.
I agree, I do the same in NixOS with Generations
Yeah, also an awesome distro. My wife’s laptop is running nixOS