Fed up with non-rolling releases...

[dolphin_oracle]

I’m no expert but from your description I’m thinking preserving your home folder would have gone a long way.

I feel your pain. It’s not easy. And the very things that we do to make mx as flexible as it is make upgrading more complicated.

Maybe we could do better but there just aren’t enough hours in the day to do better than we do.

The only way to maintain any kind of rolling release without going absolutely crazy would be to either stick even closer to debian than we already do or to stop piggybacking the Debian repos.

Even flowing Debian testing would eventually break something on mx.

But I understand.

[uncle mark]

My MX-19 KDE ain't broke and don't need fixin'. Everything works just fine, thankyouverymuch. I'll update to MX-29 or whatever it is when my current OS no longer works for me.

[thinkpadx]

by then you will be grandpa mark - eh? :-)))

[DukeComposed]

My MX-19 KDE ain't broke and don't need fixin'. Everything works just fine, thankyouverymuch. I'll update to MX-29 or whatever it is when my current OS no longer works for me.

I second this sentiment. I maintained a machine on Linux Mint 18.3 long after it had fallen out of support, and I only really noticed it had been end-of-lifed after yet another routine "apt-get update" returned no new packages for a couple of months. Depending on how you look at it, sometimes, and from a certain point of view, Linux can be a little too stable, and a little too reliable.

MX Linux updates mx-* packages nearly every day, so I'd notice a similar unsupported MX install much faster.

That being said, I tend to be very judicious about performing an upgrade. Purchasing a new hard drive in advance of the re-install is pretty typical for me if I can afford it, just so I can retain the old install and fetch an old file if I find I need it a few days or weeks later. Before an old drive gets repurposed or relegated to a closet, I put a sticky note on it with the OS, the machine name if applicable, and the start and end date of its life of service.

Every time I start wondering about if I should move to a rolling release (like Arch/Artix/EndeavorOS, Void, Rolling Rhino, etc.) I remember that one time in 2022 that DistroTube lost a day of his life fixing an Arch-based snafu in one of his production machines. DistroTube is a Linux YouTuber, so he draws his primary source of income by filming, editing, and uploading Linux-based content to YouTube. And as an Arch user, his income-deriving workflow uses Arch, a rolling release. And one day, as happens sometimes, Arch broke his workflow. If he'd been running something release-based, he would have been just fine and he could have uploaded his video and monetized it on time. There's a reason major companies don't run Arch on their servers. They'll run Red Hat or Debian or SuSE or a derivative. And only part of the answer why lies in the ability to pay for a corporate support contract. A big reason why companies avoid rolling releases is because testing new patches before users can get them is a major factor in improving the reliability of the platform.

If you're tired of upgrading once every two or three years? I get you. So am I.

But the alternative is unthinkable.

EDIT: typo

[m_pav]

@deanr72 We might be able to alleviate your pain here by encouraging you to make full use of the features packed into our Live-USB when a fully featured Live USB is made with our own Live-USB-Maker tool, which makes persistence possible.

The key to making this work for you is a fast, really, really fast flash drive, like the phenomenally cheap but damn good Netac US2 types I use (external SSD in a USB Pendrive encolosure), and they're dirt-cheap, almost to the point of being embarrassingly cheap for what they offer. The other assist that may work for you is our packaging team who love to help, though I can not speak for them in regards to your particular situation.

Most people do not know they can run our fully featured Live USB and write back changes to it that you made while running it live? Persistence I hear some respond, yes, but even without persistence it's possible, just not as refined in therms of levels of testing and control. That in itself may be worth considering because it could be your lifesaver with such a customised work, but please do read on....

Setting up a fully featured Live USB to run with persistence is very easy and when using persistence, it is possible to either save them to persistence files as desired, lose them by rebooting, or to write the changes back to the drive when you're happy with the progress to lock them in. Using persistence in this way is very much like pre-staging what's coming up next, and piece-by-piece, locking them in and working on the next level till you get it right. The beauty of persistence is, after you've written back the changes, you can choose to boot without persistence and test them, as it were, on a regular Live-USB, with the exception, you'll be running your own personally remastered Live-USB.

I've done this and used some hand-picked configs from my daily driver that I've pulled into the Live-USB with persistence session. Those I wish to keep, I copy them, ensuring all conventions are withheld to avoid stepping out of the boundaries into the appropriate location in the Live USB's /etc/skel and when I save the changes back to the Live-USB, they will be there when I next boot it as a regular Live-USB for testing or installation!, yes, they will be written into the home folder of every user created thereafter because when the users homedir is created the contents of /etc/skel are written into it.

I did this for the 6 machines I manage within my family and it saved me hours of repeating the same thing on every machine. Just insert the Live-USB, boot without persistence and install, though on my daily driver, I booted with persistence because the installer carried over all the personal configs and apps I wanted in my own installation. Dual-purpose, totally magnificent and even a beginner could use this system.

I hope you give this some consideration.

[asqwerth]

You've got to treat and appreciate rolling and fixed release distros for what they are - different, with their own pros and cons. Rolling distros - of course you get the latest version of packages so that is certainly one of its advantages.

But the OP overlooks a few tihings -
Sure, with rolling distros (eg Arch, Debian Testing and Sid), you only install once for the resting of the distro's life on the computer. However, that assumes you don't hit a big snafu or bad update you can't solve. If that happens, you still have to spend time either reinstalling (I assume you backed up your data and dotfile configs) or restoring to an earlier state (eg Timeshift) and THEN STILL HAVING TO SOLVE THE ISSUE OF WHAT WENT WRONG. That is still precious time spent.

MX/Debian Stable downloads - every 2 to 5 years you download an iso of 2-4 GB. Regular updates (say every 10-14 days) for Debian Stable are what? 200-300MB?

Arch-based distro downloads - only a single iso download for the rest of your life (if you don't completely mess up an upgrade). Regular updates every 10-14 days - 1-2GB's worth of downloads each time. Eadwine Rose checks here in the forum every second Sat (I think) of the month when Debian releases their accumulated stability updates for the month just to make sure there are no issues. That's just for 400-600MB's worth of updates. In that time you might have downloaded 3-4 GB of updates in Arch-based distros.

Time spent installing/troubleshooting a distro:
MX/Debian Stable - not much. Maybe 5 hours every 2 to 5 years for a fresh install and configuration? Day to day, most updates are fine because Debian stable updates stay within a fixed base/core. No massive changes in the base.

Arch-based - maybe 5 hours for that initial install and configuration.
Day to day running: to be safe, you check the Arch news page/distro forum before every upgrade in case there are manual intervention steps you have to take (eg the recent one if you use Budgie desktop), you are expected to maintain your system (sometimes an update informs you that certain root config files have to be assessed and maybe changed, or that file permissions for certain packages have to be changed). And of course some upgrades may not go that smoothly so you spend time reading up online and trying to resolve the issue.

Which actually takes more time overall?


Other rolling distros that may not require much user intervention and seem to have easier updates:

Solus - upgrades are certainly easy. However, limited repos, future murky. Currently the question hanging over its head is what happens when (if??) it is rebased on Ikey's Serpent OS.

Void - upgrades, wihle terminal based, are really easier and problem free. Repo of binary packages is not that big compared to Debian or Arch (I include AUR in this) though.

PCLinuxOS - it is more of a gentle rolling distro. Upgrades are fine (you can do it through Synaptic), but I do find their repo nowhere near Debian/MX's.



You have to decide what's best. There is always some compromise. For MX, some posters here have already given you tips on how you can freshly install MX and make the configuration go faster.

Note: Fedora is a separate case - their in-place upgrades work well for me every year (I upgrade 2 releases behind -- takes 3-4 hours each time though!) but even then, there are always some stray packages that don't take the migration well or have been deprecated so you have to spend time after the release upgrade sorting that out.

[AVLinux]

As others have touched upon...

MX does such a good job of providing kernels and firmware as well as updating, backporting so many upstream Packages that although the Rolling Release thing can't happen you can simply skip a new Debian release and get the double lifespan of using the same base system over 2 full Debian releases. As a current example stick with MX-21 until Debian Trixie comes out in 2 or 3 years, that would get you a 5 or 6 year run between reinstalls..

Like the folks still using MX-19, that's a pretty good run! Nobody likes the stigma of running 'oldstable' but the MX devs really shield you from a lot of that with the diligent Packaging across so many releases.

If I didn't have AVL Users depending on me I would not be moving to MX-23 Bookworm, MX-21 has been an apex experience IMHO.. I think the Linuxsphere is moving in several ill-considered directions currently but that is going way off topic for this thread..

[davidy]

I've wished for a unified physical hardware model for years now. Just the amount of technology already in existence being blocked to consumers is most of what truly holds back ALL devices of any kind. We are basically fed with the "carrot-on-a-stick" method. This entails making it complex and varied beyond belief, by intention. For no good reason at all except control and power/money. I firmly believe if the technology that exists was released to the public you wouldn't even know what you were looking at much less how to use it.

So you have endless amounts of technolgy that is not agreed upon and is constantly changing, hopefully for the better, but as has been proven many many times, not for the better.

This means that any agreed upon gui/os for any one of these devices will simply never happen because no one ever agreed on the hardware itself in the 1st place. The whole system is like a dog chasing it's tail making it impossible to create a truly 'rolling' release that anyone can simply install and never have to reinstall.

I have wished for a unified architecture since ubuntu was announced. But that's like wishing all the Korean & Japanese electronics were available in the US.
Take the dvd region code nonsense. That was on purpose, for no good reason other than the control thereof.
The Framework laptop is as close as your gonna get to a rolling release of anything. Till something new (carrot) is put out.

By the time you get all the way down to the OS/GUI, you have to consider all the physical hardware nonsense shenanigans it's supposed to go on.
MX devs are HEROS in this respect. You guys are real troopers. SystemD? nah, that's just an option. BTW, Siduction states they came out with systemd before debian. Woohoo, another complication no one asked for. Basically we need to agree on the hardware first before we start worrying about the GUI it uses. But since that's being hidden and rolled out in tidbits, intentionally, this makes that impossible. At least I know I can run mx21.3 with kernel 6.3 for years if I like. That's good news. I ran mx19 for only a few months and then clean installed 21. The dance between whatever current drivers you may need and the software that runs on it. The real trick is in buying and holding onto hardware YOU control and not the manufacturer at this point. I wish we had a framework cellphone option. The radios need to be seperate, not "fused" like it is now.

"roll over 'for' you", That's a good one.
Please excuse this long rant.

[CharlesV]

For me.. I think the "near perfect Install" is really in a vm. I have tried desperately to create perfect computers for years, with the goal of NOT having to reload a bunch of stuff every X ... but I have found that for me, there is a fine line between what I want to do - and how I want to do it.

A REALLY good lesson was to run windows and understand WHY my machines would get wonky weird and I found that a VM with my dev tools, or a vm with my graphics tools was good and didnt pollute the other.

But linux really gave me the best of both. I can have a nice, clean linux load, and then have VM's for development, or for specific need, and keep a clean, fast host - unencumbered with the schtuff I need / want to work with.

MX gives me the ability to run great software and a great OS with little issue. And if I want my heavy, dev environment, I have "a VM for that" and scripting up the install I want for either one can make a clean, fresh install as needed!

[deanr72]

Thanks for the responses. Quickly, to answer some of the questions posed:

- I haven't asked for support because I like to try and solve problems myself first. I created a snapshot of my system before upgrading and used this on a new SSD which I intend to use instead of the one I'm using now. I'll try again, of course, when I have time, and see if I can't get it working.
- I did read the upgrade or 'migration' notes carefully, yes. And followed them to the letter. Firstly, I was not able to 'sudo apt install mx23-archive-keyring' from terminal as it couldn't find the package. I was, however, able to install this from the package installer. The upgrade then stalled at 81% so I did 'sudo reboot' as per the instructions. Upon reboot I encountered problems with the kernel and the package installer would not start. That's where I'm at at the moment...
- I did think about (and may still do) the other option of installing mx23 with the option to keep the home folder in place. Many of the other changes I've made to my system, however, involved change in the etc/ folders and these would have to be done manually again presumably. Thus trying the upgrade first.

I'm also aware that running mx-21 for another year or two is an option and may indeed just decide to do this. Or install mx-23 on another drive and get it set up over time with a view to creating a snapshot once it's all set up. I was just disappointed that the upgrade didn't go as smoothly as I had hoped but, just to restate, I really do know and appreciate that mx is by far the best distro out there - so thanks again for all the effort and help for such a great product and wonderful community.