If I did not update for a long time, we get update related issues

I’ve experienced the opposite with debian-based distros in the past. After six months or so, an EOL was reached of an installed version, and no way found to upgrade without the new software sources, which I couldn’t find on the net (or didn’t have the time to search for). So a hop to another distro appeared to be just more attractive, back then, before I had ever learned to install Arch the Wiki way.

:wink:

1 Like

Well, I have a (Debian stable based) SoldXK install that is almost 9 years old, which has been updated-in-place with each new version of Debian. The only issue I ever had was with a couple of icons on the Plasma panel.

But whatever.

1 Like

How far in the past are we talking about? It definitely was a lot harder than it is today if you back far enough. I remember that if you go back 15-16 years, upgrades were possible but discouraged. Especially on anything that was Ubuntu-based.

It might have been 5-8 years back. Then I simply didn’t know enough to get it solved. Today I’d probably be able to.

1 Like

The point of a rolling release model is that there aren’t any major updates. Ever. No major versions. He was suggesting Debian as a way to avoid updates because you seemed to want to do so rarely.

Its not that I want to do it rarely but it is more of a fact that I have some computers that I don’t often use. That is all.

Yeah best to run ubuntu or debian on them.

Yeah, if something is going to sit that long then a rolling release probably isn’t the right choice. Neither is a rapid release like Fedora. You want something “shelf stable” so to speak, so probably Debian or an LTS Ubuntu. In that case, I wouldn’t worry about major upgrades, if they’re used that infrequently then just wipe and reload them if you have to.

You could also look at something like Fedora Silverblue or Kinoite. Those are pretty shelf stable because they’re just a read-only desktop and a a bunch of Flatpaks for the most part. Major updates are just a replacement of your root partition.

1 Like

Recently there was a post from someone trying to update an iso that was downloaded in Dec 2021. The user had to do manual intervention, about 3-4 packages, the same that a user would have to do if they would simply have a system to update since then. This includes jack2, the wireplumber and couple of others.

1 Like

Tried to update a live arch image from 2012, suffice to say it did not go well. Tend to update weekly as things change very quickly in archland.

If you have to salvage an old install far better to save any important data and reinstall.

You mean, recently? Yeah, 10 years would be tough.

Although, I sort of want to try that as a challenge now. :rofl:

Someone shared an old version with me sometime ago and as always I have forgotten where I put it! If I find it you are welcome to have a look at it…

I wouldn’t expect that to go well but i an morbidly curious about what parts of it broke :grin:

So many things would be problematic. Many of the replacement packages would have long ago lost any trail back to where they belong. There were multiple major pacman changes. The packages are now compressed with zst. It would be interesting to see if pacman static would even run on an install that old.

For fun and profit I upgraded an 8 months old VM, and it was relatively painless besides the keyring and pipewire-jack vs jack2, and wireplumber vs pipewire-media-session. Then I found celt and libkipi in the AUR and removed them.

For some reason the bootloader says “Arch” instead of Endeavor, now. :confused:

edit: The italicised paragraph was due to BIOS vs EFI, and had nothing to do with old vs new; ignore it:
Also, I did not do grub-install and I had no trouble, whereas a more recent VM I upgraded a couple days ago did not boot (cf recent grub kerfuffle) and I had to chroot it.

Overall, at eight month old, definitely faster to update than to reinstall.

Is it virtualbox?

Interesting experiment. Still, with a clean install for me makes more sense.

Both are VirtualBox, both are EOS.

My host’s VB was upgraded yesterday, between the time I upgraded the recent-ish VM and the time I upgraded the old one, so that may be a factor. [assuming the reason you ask is regarding the grub 322 thing]

Sure, for your pride and joy main system. If you have a gaggle of fairly specialised laptops and VMs, the squeaky clean appeal of the fresh install does not adequately compensate the time investment :wink:

Three things:

  • Are they both UEFI?(The issue only impacts UEFI)
  • Virtualbox seems to have some UEFI issues in spots which actually helps in this issue
  • If that one that worked is UEFI, you should run grub-install in it as you are otherwise just waiting for a failure
1 Like

I assumed they were both UEFI (because 1° I do not recall changing those parameters in any machine, so I assumed all of them had the same config and 2° otherwise none would have failed to boot) but it turns the old one was BIOS and the new one UEFI. So nothing to see here.

Now that I think about it, the default in VB is BIOS, I’m pretty sure. So that means I have switched one VM to UEFI, for some reason. I probably had a good reason at the time, though I can’t think of any right now.

Anyway, that means my initial remark wrt grub was irrelevant to the topic, and I shall strike it out of my post. Thank you for pointing it out.

2 Likes