6 ms·

I've been using arch for a few years as daily driver, and I mostly like it, but I would be lying if I said it doesn't break at random intervals during system up

I've been using arch for a few years as daily driver, and I mostly like it, but I would be lying if I said it doesn't break at random intervals during system updates. Nothing unrecoverable, but it's definitely a thing that comes with frequent upgrades.

nemetroid 5y ago
What part of it breaks for you? It's not that I don't believe you, and I've seen this sentiment before, but I've used Arch as my daily driver for about five years, and can't recall a single time where it broke from a system update.
- Lex-2008 5y ago
  not OP, and not Arch, but Manjaro (so you can take it with a grain of salt), reporting from memory so details might be incorrect. * after "BootHole" GRUB vulnerability, I've read that upgrade requires re-installation of the bootloader. And just in case, did run `sudo grub-install …`. After reboot, system didn't boot. Had to use installation USB to restore. * More recently, during routine upgrade pamac (Manjaro's pacman alternative) GUI showed me some "transaction can't be completed" error message. Shuddered it away - few days later pamac wasn't starting at all. Starting it from terminal showed error message about some missing *.so file. Googling showed that this is a required file for pacman (Arch package manager) to function. Typing `pacman` in terminal showed "command not found" error message. Restored the missing *.so file from snapper snapshot (thanks btrfs!), after that pamac started fine and happily upgraded my system. I'm not sure what happened in second case and why pamac left system in broken state (looks like it wanted to upgrade pacman by first removing old files and then putting new files in place, but aborted in the middle), but first one might be quite distro-independent. Also, reading through recent Arch news, I believe this could bite someone: https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh-82p1/ https://archlinux.org/news/sshd-needs-restarting-after-upgra... > After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon right after running pacman -Syu. If you are upgrading to openssh-8.2p1-3 or higher, this restart will happen automatically.
  - majewsky 5y ago
    > I'm not sure what happened in second case and why pamac left system in broken state FWIW, as a vanilla Arch user, I have not encountered this issue. I remember a time when pacman updates were kind of iffy (and in fact, pacman itself asked you to update it first before proceeding with the rest of the updates), but since 5.0, all subsequent updates have been completely unremarkable in the best way.
- paulfurtado 5y ago
  I use arch on all my machines and there are really a lot of ways it has broken. - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. - I've had gedit start crashing in new minor versions of gnome due to a setting being incompatible, needing to track that down and unset - If you have python virtualenvs for development and system python is upgraded to a new major version, all your virtualenvs break - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) - If you do a full system upgrade and have AUR stuff installed, you need to be sure to upgrade the AUR stuff otherwise it could break due to being incompatible with any library that was upgraded. - In general (not specific to arch linux), new versions of software break stuff all the time. You tend to hit way more of this on arch if you keep your system up to date.
  - formerly_proven 5y ago
    > - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) Okay I just wanna point something out here, partial upgrades in Arch are broken by design because they simply can't work. Don't do it. That being said... > - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. ... kernel ABI is stable and even ancillary interfaces are usually stable, so usually it's quite A-OK to not immediately upgrade the kernel.
    - Liskni_si 5y ago
      Can you elaborate why has Arch chosen to not support partial upgrades by design? They do work in Debian and it's saved my day a number of times. They let me roll back a broken upgrade without holding back upgrades of the rest of the system, and my computer then continues to be usable until the package in question is fixed.
- maddyboo 5y ago
  I was an XMonad user during the time that Arch switched from statically linked Haskell packages to dynamically linked and oh my god was that a nightmare. Other than that I’ve had far, far fewer issues with Arch than any other distro I’ve used.
ohazi 5y ago
I use Debian testing as my daily driver at home and at work, and have found it to be plenty stable over the decade or so that I've been using it. I've also been using Arch on a "for messing around; I don't care if it breaks" laptop for about two years, and haven't had any major breakages. For me, the most noticable difference has been that Debian will install new kernels as new packages, will suggest removing old kernel packages, but won't suggest removing the currently booted kernel. I like this behavior. By default, Arch will swap your currently booted kernel and modules out from under you. You don't necessarily need to reboot right away, but if you don't, you can run into issues loading modules or recovering from hibernation. You can work around this once you realize what's happening, but it seems like a needlessly dangerous default.
- nemetroid 5y ago
  See https://bugs.archlinux.org/task/16702 https://bugs.archlinux.org/task/16702 for a discussion about versioned kernel installs in Arch.
- DyslexicAtheist 5y ago
  I'm using Sid as a daily driver on all my dev machines[1]. I run apt dist-upgrade twice a week too and I back up to external drive once a week. I've never once been in a situation (since ca. mid 2000) where I needed to restore from backup or boot into single user mode. My favorite documentation is the arch wiki and there has never been an issue due to it not being compatible to the "Debian way" When upstream devs package for a distribution they usually put some effort into it. Just because a package gets published to Sid/unstable doesn't mean the package is unstable. There are some devs that mostly work on higher layer GUI and user-lamd applications who are perhaps inexperienced or reckless who do sometimes introduce breaking changes. It's rare though since most people understand that packaging for a distro means a potential huge number of issues if they're not careful My 70+ year old aunt also runs sid since a couple of years with unattended upgrades since I installed it for her (and she has KDE). She never had issues with stability or things not working and she uses her computer daily for writing (libreoffice), printing and research (probably reddit idk, I didn't ask :)). [1] my install is fairly minimal: not much gui, server systems etc are started with docker so hardly anything actually runs on bare-metal which can cause issues during upgrade jeopardizing the things I work on (e.g. due to config file changes). And I don't have a huge DE like gnome/KDE. My sway/wlroots and i3, and tooling like x-terminal/wofi/Waybar/etc are always compiled from git/source. All my dev tooling is the latest and I can still install older versions of clang/gcc or other environments with my package manager if I have to.
bachmeier 5y ago
I used Arch many years ago as my main OS. I eventually had to give up on it because (i) several packages I needed were badly out of date, combined with (ii) a rule against AUR having packages that were only updates of something in the repos. I was left handling the compilation process all by myself. When several of us raised the issue in the forum...I'll just say we didn't get a warm reception. That was more than a decade ago, so things may be completely different now, but it left a bad taste in my mouth.
matheusmoreira 5y ago
Could you post more details about what broke, why and how you fixed it? I'm curious. I've been using Arch for years and I never experienced any breakage. I update it every month or so and it's still stable even after these huge updates. There's nothing for me to do other than merge .pacnew files.
SJetKaran 5y ago
You can try one of the Arch derivatives like Manjaro. That might help with this issue a bit.
- chaorace 5y ago
  Seconded. Manjaro's stable channel is the best of both worlds -- a meticulously manicured package ecosystem with just enough time lag behind the bleeding edge that it's very rare for a bad patch to sneak in. I think it's happened to me once in just over four years now?

nemetroid 5y ago

What part of it breaks for you? It's not that I don't believe you, and I've seen this sentiment before, but I've used Arch as my daily driver for about five years, and can't recall a single time where it broke from a system update.

Lex-2008 5y ago
not OP, and not Arch, but Manjaro (so you can take it with a grain of salt), reporting from memory so details might be incorrect. * after "BootHole" GRUB vulnerability, I've read that upgrade requires re-installation of the bootloader. And just in case, did run `sudo grub-install …`. After reboot, system didn't boot. Had to use installation USB to restore. * More recently, during routine upgrade pamac (Manjaro's pacman alternative) GUI showed me some "transaction can't be completed" error message. Shuddered it away - few days later pamac wasn't starting at all. Starting it from terminal showed error message about some missing *.so file. Googling showed that this is a required file for pacman (Arch package manager) to function. Typing `pacman` in terminal showed "command not found" error message. Restored the missing *.so file from snapper snapshot (thanks btrfs!), after that pamac started fine and happily upgraded my system. I'm not sure what happened in second case and why pamac left system in broken state (looks like it wanted to upgrade pacman by first removing old files and then putting new files in place, but aborted in the middle), but first one might be quite distro-independent. Also, reading through recent Arch news, I believe this could bite someone: https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh-82p1/ https://archlinux.org/news/sshd-needs-restarting-after-upgra... > After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon right after running pacman -Syu. If you are upgrading to openssh-8.2p1-3 or higher, this restart will happen automatically.
- majewsky 5y ago
  > I'm not sure what happened in second case and why pamac left system in broken state FWIW, as a vanilla Arch user, I have not encountered this issue. I remember a time when pacman updates were kind of iffy (and in fact, pacman itself asked you to update it first before proceeding with the rest of the updates), but since 5.0, all subsequent updates have been completely unremarkable in the best way.
paulfurtado 5y ago
I use arch on all my machines and there are really a lot of ways it has broken. - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. - I've had gedit start crashing in new minor versions of gnome due to a setting being incompatible, needing to track that down and unset - If you have python virtualenvs for development and system python is upgraded to a new major version, all your virtualenvs break - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) - If you do a full system upgrade and have AUR stuff installed, you need to be sure to upgrade the AUR stuff otherwise it could break due to being incompatible with any library that was upgraded. - In general (not specific to arch linux), new versions of software break stuff all the time. You tend to hit way more of this on arch if you keep your system up to date.
- formerly_proven 5y ago
  > - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) Okay I just wanna point something out here, partial upgrades in Arch are broken by design because they simply can't work. Don't do it. That being said... > - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. ... kernel ABI is stable and even ancillary interfaces are usually stable, so usually it's quite A-OK to not immediately upgrade the kernel.
  - Liskni_si 5y ago
    Can you elaborate why has Arch chosen to not support partial upgrades by design? They do work in Debian and it's saved my day a number of times. They let me roll back a broken upgrade without holding back upgrades of the rest of the system, and my computer then continues to be usable until the package in question is fixed.
maddyboo 5y ago
I was an XMonad user during the time that Arch switched from statically linked Haskell packages to dynamically linked and oh my god was that a nightmare. Other than that I’ve had far, far fewer issues with Arch than any other distro I’ve used.

ohazi 5y ago

I use Debian testing as my daily driver at home and at work, and have found it to be plenty stable over the decade or so that I've been using it. I've also been using Arch on a "for messing around; I don't care if it breaks" laptop for about two years, and haven't had any major breakages. For me, the most noticable difference has been that Debian will install new kernels as new packages, will suggest removing old kernel packages, but won't suggest removing the currently booted kernel. I like this behavior. By default, Arch will swap your currently booted kernel and modules out from under you. You don't necessarily need to reboot right away, but if you don't, you can run into issues loading modules or recovering from hibernation. You can work around this once you realize what's happening, but it seems like a needlessly dangerous default.

nemetroid 5y ago
See https://bugs.archlinux.org/task/16702 https://bugs.archlinux.org/task/16702 for a discussion about versioned kernel installs in Arch.
DyslexicAtheist 5y ago
I'm using Sid as a daily driver on all my dev machines[1]. I run apt dist-upgrade twice a week too and I back up to external drive once a week. I've never once been in a situation (since ca. mid 2000) where I needed to restore from backup or boot into single user mode. My favorite documentation is the arch wiki and there has never been an issue due to it not being compatible to the "Debian way" When upstream devs package for a distribution they usually put some effort into it. Just because a package gets published to Sid/unstable doesn't mean the package is unstable. There are some devs that mostly work on higher layer GUI and user-lamd applications who are perhaps inexperienced or reckless who do sometimes introduce breaking changes. It's rare though since most people understand that packaging for a distro means a potential huge number of issues if they're not careful My 70+ year old aunt also runs sid since a couple of years with unattended upgrades since I installed it for her (and she has KDE). She never had issues with stability or things not working and she uses her computer daily for writing (libreoffice), printing and research (probably reddit idk, I didn't ask :)). [1] my install is fairly minimal: not much gui, server systems etc are started with docker so hardly anything actually runs on bare-metal which can cause issues during upgrade jeopardizing the things I work on (e.g. due to config file changes). And I don't have a huge DE like gnome/KDE. My sway/wlroots and i3, and tooling like x-terminal/wofi/Waybar/etc are always compiled from git/source. All my dev tooling is the latest and I can still install older versions of clang/gcc or other environments with my package manager if I have to.

bachmeier 5y ago

I used Arch many years ago as my main OS. I eventually had to give up on it because (i) several packages I needed were badly out of date, combined with (ii) a rule against AUR having packages that were only updates of something in the repos. I was left handling the compilation process all by myself. When several of us raised the issue in the forum...I'll just say we didn't get a warm reception. That was more than a decade ago, so things may be completely different now, but it left a bad taste in my mouth.

matheusmoreira 5y ago

Could you post more details about what broke, why and how you fixed it? I'm curious. I've been using Arch for years and I never experienced any breakage. I update it every month or so and it's still stable even after these huge updates. There's nothing for me to do other than merge .pacnew files.

SJetKaran 5y ago

You can try one of the Arch derivatives like Manjaro. That might help with this issue a bit.

chaorace 5y ago
Seconded. Manjaro's stable channel is the best of both worlds -- a meticulously manicured package ecosystem with just enough time lag behind the bleeding edge that it's very rare for a bad patch to sneak in. I think it's happened to me once in just over four years now?