this post was submitted on 21 Aug 2026
406 points (93.4% liked)

memes

22472 readers
3554 users here now

Community rules

1. Be civilNo trolling, bigotry or other insulting / annoying behaviour

2. No politicsThis is non-politics community. For political memes please go to !politicalmemes@lemmy.world

3. No recent repostsCheck for reposts when posting a meme, you can only repost after 1 month

4. No botsNo bots without the express approval of the mods or the admins

5. No Spam/Ads/AI SlopNo advertisements or spam. This is an instance rule and the only way to live. We also consider AI slop to be spam in this community and is subject to removal.

A collection of some classic Lemmy memes for your enjoyment

Sister communities

founded 3 years ago
MODERATORS
 

Arch is different...

you are viewing a single comment's thread
view the rest of the comments
[–] TeamAssimilation@infosec.pub 8 points 6 days ago (13 children)

I think no rolling releases has gotten their act right. All eventually break with an update, and if you skipped several, the likelihood of reinstalling is high.

At least they teach you good backup practices.

[–] black0ut@pawb.social 6 points 6 days ago (6 children)

My record with Arch is longer than 6 months without updates, and it completed the updates fine.

My oldest install is 4 years old, and it's true, it became unbootable once. But it was my fault, for generating an initramfs without free space in /tmp, which caused it to fail. It was a quick fix once I figured it out.

All of this isn't to say rolling is as stable as Debian, of course. Rolling is inherently gonna be more unstable, and that's by design.

But if you take some care, you can actually make these rolling distros pretty stable. Hell, my servers run Arch (I'm working on migrating them to Gentoo to get rid of systemd, but I haven't yet commited to it). And I haven't had any serious breakages, even on Arch Linux ARM.

[–] lemmyvore@feddit.nl 6 points 6 days ago (2 children)

But it was my fault, for generating an initramfs without free space in /tmp, which caused it to fail.

I really don't think that was your fault. A critical build process that's not checking for resources and not failing gracefully and leaving the machine unbootable is not the user's fault.

A build+install can fail for many reasons. It's actually annoying how many critical system updates on Linux don't use a staging process and a sudden power-off at the wrong time can leave the machine completely crippled.

Some distros have taken to doing a BTRFS snapshot before they start the upgrade but (a) they're far and few in between and (b) that still doesn't fix the upgrade process, it's just sweeping the problem under the carpet.

[–] black0ut@pawb.social 3 points 5 days ago

I manually triggered it, and didn't read the logs when it said it failed. That was my fault. If it fails, it will tell you. You still have the machine working until you reboot, so if you read the logs, you can clear /tmp and retry again, and the machine should be bootable again.

Linux lets you do anything, including stupid things. I'd say doing stupid things is the fastest way to learn about it, though.

The same issue would have happened even on Ubuntu, as it uses the same tools as Arch for generating the initramfs. I don't consider it an Arch or Linux issue, just a user mistake. It won't happen normally, unless you manually trigger it.

load more comments (1 replies)
load more comments (4 replies)
load more comments (10 replies)