You are viewing a single thread.
View all comments
45 points

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.

permalink
report
reply
46 points

sure, but what os wouldn’t break if you did this?

permalink
report
parent
reply
29 points

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.

permalink
report
parent
reply
7 points

So what I’m hearing is install Linux-LTS and pacsnap

permalink
report
parent
reply
15 points

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.

permalink
report
parent
reply
5 points
*

In Windows you can also fix this with a live Windows USB, manually.

permalink
report
parent
reply
12 points

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?

permalink
report
parent
reply
7 points

Yeah windows “cumulative update” upgrades for the past couple of years basically duplicate the whole system directory and apply the update to that leaving the existing one to roll back to if anything fails

permalink
report
parent
reply
2 points
*

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.

permalink
report
parent
reply
0 points

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.

permalink
report
parent
reply
10 points

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.

permalink
report
parent
reply
2 points

good answer to a bad and uninformed question, thanks.

permalink
report
parent
reply
2 points

Any immutable distro, Debian, Ubuntu, all their derivatives

Debian and Ubuntu are not immutable distributions by default, unless I am mistaken.

permalink
report
parent
reply
3 points

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

  1. Write to temporary file
  2. Fsync temporary file
  3. Renameat2 EXCHANGE temporary and target
  4. Fsync directory (optional, since a background flush would still be atomic, just might take some time)
permalink
report
parent
reply
1 point

renameat2

I read this as “rena meat 2” and was very confused

permalink
report
parent
reply
0 points

it was btrfs.

permalink
report
parent
reply
24 points

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!

permalink
report
parent
reply
19 points

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.

permalink
report
parent
reply
4 points

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.

permalink
report
parent
reply
6 points

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.

permalink
report
parent
reply
2 points

How would you set up a fallback kernel in Arch?

permalink
report
parent
reply
2 points

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.

permalink
report
parent
reply
1 point

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.

permalink
report
parent
reply
2 points

I am using an old laptop that gives me 3 minutes to run from one power plug to the other before just going out.

permalink
report
parent
reply

linuxmemes

!linuxmemes@lemmy.world

Create post

Hint: :q!


Sister communities:

Community rules (click to expand)

1. Follow the site-wide rules
2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of “peasantry” to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
4. No recent reposts
  • Everybody uses Arch btw, can’t quit Vim, and wants to interject for a moment. You can stop now.

Please report posts and comments that break these rules!

Community stats

  • 6.8K

    Monthly active users

  • 1K

    Posts

  • 20K

    Comments