New to Debian and Antix – Rolling Release help [SOLVED…. THANK YOU!!!]

[Member Herndon]

Hi! I am new to Antix and Debian, although I have been interested in it for several years now. I would be installing Antix 32 bit full edition (stable) on my computer. I have seen various articles on the internet that Antix is a cyclical rolling release. Does that mean I will never have to do a fresh install every 5 years, like with ubuntu based linux? Would I just upgrade the kernel, or something different?

• This topic was modified 2 years, 7 months ago by Herndon.
• This topic was modified 2 years, 7 months ago by Herndon.

[Member Xecure]

Helpful

Up

0

::

Please, point us to the page that states that antiX is a rolling release. Another user also claimed they had read this but couldn’t provide a link to back it up.

antiX is based on Debian, so it follows Debian’s release cycle.
antiX 17 is based on old-stable (support until 2022). No new packages will be backported to it.
antiX 19 is based on stable. It will keep receiving updates, but most packages would be considered old by arch standards. Some packages are backported from testing, so these will be new (libreoffice, for example). antiX 19 will receive new updates until 2022 and security updates until 2024.
If you want newer packages but a similar release cycle, move to testing. Upgrading from stable to testing shouldn’t be difficult (change repos and doing a dist-upgrade or full-upgrade).
If you want antiX as rolling release, you need to move to sid. The easiest is downloading antiX sid edition and installing it.

Debian releases are comparable to Ubuntu LTS editions.

The reality for old systems (and 32 bit systems enter this category). It is possible that new xorg (manages display and gui) packages stop supporting old hardware, so you may be forced to use an older debian version or upgrade the graphic card (if this is possible). So maybe you will be stuck with a certain version and rolling release is impossible. that will depend on your hardware.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Moderator caprea]

Helpful

Up

0

::

antix can only be called “rolling” if you set the sources (debian and antiX sources) to testing [or sid, of course, as Masinick correctly pointed out].
Then you indeed theoretically do not need to reinstall.
In practice, however, you will lose the status of a stable release.That’s a fact.
But to be honest, my main system is a testing install on my desktop and there have only been minor difficulties to keep it rolling for maybe 6 years now.
On the other hand, I also like to do a new installation when a new release comes out.
I have my important data on an extra hard disk or partition anyway.
So the whole thing is a matter of attitude.Besides hardware like Xecure mentioned.
With really modern hardware testing is maybe a must, or rather old hardware is might better served with an older release.

• This reply was modified 2 years, 7 months ago by caprea.

[Moderator Brian Masinick]

Helpful

Up

0

::

You can, at least in theory, make antiX into a rolling upgrade system by using either:

Xecure: “If you want antiX as rolling release, you need to move to sid. The easiest is downloading antiX sid edition and installing it.”

My response is that Sid may install easily and MOST of the time it behaves itself, but this approach requires attention to the packages are changing and a general awareness of when major infrastructure changes take place. In those cases, I recommend waiting to perform any dist-upgrades or major changes of any kind. This is best left to those who understand what all of this means already, or are willing to learn most of it on their own.

Caprea: “antix can only be called “rolling” if you set the sources (debian and antiX sources) to testing.”

Again, using “only” is incorrect. Actually you can perpetually upgrade antiX using Testing OR Sid, and occasionally even Experimental packages (IF you use great care and don’t destroy the primary system libraries for things like file system handling, network management, or file manager behavior).

I would suggest that using Testing as your primary repository for both antiX and Debian binary images is relatively straightforward; change the repo:

For example,

# Use with Debian Stable/buster repositories. Set as default for antiX-19.
deb http://mirrors.rit.edu/mxlinux/mx-packages/antix/buster buster main nonfree nosystemd
#deb-src http://mirrors.rit.edu/mxlinux/mx-packages/antix/buster buster main nonfree nosystemd

# Use with Debian Testing/’rolling’ repositories.
#deb http://mirrors.rit.edu/mxlinux/mx-packages/antix/testing testing main nonfree nosystemd
#deb-src http://mirrors.rit.edu/mxlinux/mx-packages/antix/testing testing main nonfree nosystemd

# Use with Debian Sid repositories.
#deb http://mirrors.rit.edu/mxlinux/mx-packages/antix/sid sid main nonfree nosystemd
#deb-src http://mirrors.rit.edu/mxlinux/mx-packages/antix/sid sid main nonfree nosystemd

Uncomment, that is, remove # in front of deb http://mirrors… for EITHER Testing OR Sid, but not BOTH.
Also, comment the site that you are changing from (and uncomment the site you are changing to).

Do the same for the Debian repo and any other additional repositories you are using.

As long as you understand this, it is pretty straightforward.

A note from Debian site: https://wiki.debian.org/DebianTesting

How to upgrade to Debian (next-stable) Testing

<!>

Please always upgrade to Debian Testing from current stable. Upgrading from oldstable is not supported and might encounter unexpected errors.

To upgrade to testing from current stable, if you have already installed the stable release:

Edit your apt sources, changing ‘stable’ (or buster, the current codename for stable) to ‘testing’ (or bullseye, the current code name for the next stable release).

Remove, disable or comment out your stable security updates apt sources (anything with security.debian.org in it).
Remove, disable or comment out any other stable-specific apt sources, like *-backports or *-updates.

Verify that your installation is not fixed to a specific release in /etc/apt/apt.conf.d/00default-release

The code name for the next stable release, e.g. “bullseye”, will track “bullseye” through its transition into “stable” and later oldstable, while “testing” will keep rolling on after a new stable release. If you would rather track the Bullseye release as it becomes stable, update your apt sources replacing “stable” or “testing” with “bullseye”.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

https://www.antixforum.com/forums/topic/upgrading-antix-17-to-antix-19/#post-28441
has comments from anti on migrating from antiX 17 to antiX 19 that are relevant to this conversation; they show some of the methods you would use.

Change buster to whatever release (Testing, Sid) you are considering…

--
Brian Masinick

[Member Herndon]

Helpful

Up

0

::

Thank ALL of you for responding to me so quickly. First, the old forum of Antix claims that it is a cyclical rolling release. Here is the cite: https://antixlinux.com/forum-archive/is-antix-a-rolling-release-t4560.html

“Linux Mint Debian Edition (LMDE) and antiX are cyclical rolling release Deb binary-based Linux distributions based on Debian testing. Debian testing is a cyclical development branch and is thus frozen before each release of Debian stable. During this time, Debian testing is no longer rolling, which affects rolling distributions based on it — like LMDE and antiX.”

This isn’t the only place I have seen the claim. I honestly think my confusion was semantic… When I researched what a “rolling release” truly is… a bleeding edge release where everything is being updated constantly… I realized that in theory, only an “unstable” debian release could be set up as a true “rolling release” since both testing and stable Debian releases become “frozen” at some point. Please forgive me for being inarticulate with the use of the word “frozen.”

I realized that what Masinick was talking about was what I was thinking about… migration. I found an old post, referring to migration from Antix 16 to 17 and when it is realistic/possible. Unfortunately, I rely on two Windows based programs that run through Wine. The post says if you use programs outside of the official repositories, then migration might not be the best option.

If this is right, please let me know. I am tired of doing clean installs… it would be nice just to upgrade to the newest version and not worry about it.

My current ubuntu based OS (WattOS) has been abandoned and its end of life is April of 2021. I may just wait until the next edition of Antix comes out and install it then. Thank you ALL. This is a very cool community.

[Moderator caprea]

Helpful

Up

0

::

Brian Masinick wrote:

Caprea: “antix can only be called “rolling” if you set the sources (debian and antiX sources) to testing.”

Again, using “only” is incorrect.

You’re right. The sentence is completely wrong and I hope it is ok I change it in my post.

Herndon wrote:

Here is the cite: https://antixlinux.com/forum-archive/is-antix-a-rolling-release-t4560.html

It was before my time here, but I will say something about it carefully.
The first releases of antiX were all testing and rolling.
Maybe antiX13 was the first stable release, but Masinick knows for sure.

[Member Herndon]

Helpful

Up

0

::

Ok. I understand now that Antix has evolved over the years.

I am wondering if what I think I read in the post on migrating from Antix 16 to 17 is still valid. Is migration worthwhile if you use programs outside of the regular repositories (such as windows programs through WINE)?

I am grateful for all of your help!

• This reply was modified 2 years, 7 months ago by Herndon.

[Member Herndon]

Helpful

Up

0

::

Here is the link for migration from 16 to 17:

https://www.antixforum.com/forums/topic/can-antix-16-be-upgrade-to-antix17/

Anticapitalista prefaces his comments with if you haven’t used non-official repos, a dist-upgrade should work. What if you have used other programs? Will it hurt the migration?

[Anonymous]

Helpful

Up

0

::

“What if you have used other programs installed programs from non-official repos? Will it hurt the migration?”
Indeed, it may, which is the reason why “Anticapitalista prefaces his comments with”

[Member Herndon]

Helpful

Up

0

::

Thank you, skidoo! I was hoping all it would mean is that I would have to reinstall those programs (my 2 windows based programs), but that it wouldn’t effect the migration. Guess I am better off with a fresh install. Better to know now than try to migrate and face a big problem.

[Forum Admin Dave]

Helpful

Up

0

::

Yes antiX moved from the testing to the stable debian base using codenames as well.
So currently the default install and leaving the repositories as default will keep you on the stable branch currently named “buster”. So even when the next stable version comes out (bullseye) your system will not try to upgrade to that stable version. The antiX repo’s are named the same way. If you changed the names in the sources from “buster” to “stable” your system would try and update (as well as likely fail to update) from stable to stable (buster -> bullseye).

In the past when antiX was testing based IIRC the repositories would read “testing” instead of the codename (which would be bullseye currently). So it would fit with the description for update cycles from the old forum archive. Changing your repositories to use “testing” instead of “buster” and updating would work pretty much the same as it did in the past. Of course sid/unstable is constantly changing / updating and would be more rolling; not having the cyclical updates like when using testing. If you used the codename for the current testing (bullseye) rather than “testing” you would automatically roll into stable when testing is released as stable and lose the cyclical rolling setup of the past.

Those migrations mentioned are when new antiX releases are made but are still using the same debian stable base. It is the same as continuing to update but the migrations list what new packages were added/removed and what new changes could be implemented in your user’s home directory (which is not modified during an update). This is seen for example with antiX 15 and antiX 16 both being jessie based and can be performed without worry. Then between antiX 17 and antiX 19 the base is different and comes with the nice warning.

If you try this and it breaks your install, don’t blame me!
………
9. Reboot – and cross your fingers! (You DID make a backup didn’t you?
………

Essentially it is extremely likely to break but it highlights the main changes and what *could* be done to migrate with the best chance of success. The best time to attempt this transition is likely right when debian switches stable to old stable and testing to new stable rather than making utilization of the debian lts teams efforts before upgrading. If you use the full extent of lts support you are likely to be trying to update 2 versions at once.
https://wiki.debian.org/DebianReleases
Using the above take note of buster’s release date and jessie’s lts end of life date. Also note that debian has a new release every 2 years but supports 3 per release. So the optimal time to attempt a migration (imho) would be earlier in the year time frame between the release date of the new stable and the end of life date (1 year later) of the old stable (or your current install). Changing the sources to read “stable” instead of “buster/codename” would do this automatically so you can forget about the 1 year time frame but back to point 1.

As far as the wine installs. I have not had any in a while but IRRC they should not be much of a problem. They are stored / installed in your home directory and the wine package gets installed / updated. They may get outdated by an updated version of wine not being 100% backward compatible in the same way a configuration file for app ABC in your home directory may get outdated with a new version of app ABC. That would require some research before / after updating. The other programs from outside of the repositories as mentioned is more for programs installed from source, or things like printer drivers, google chrome, etc. These programs would be meant for the old versions of packages, relying on those older versions of libraries. They would require updating manually and / or recompiling. Sometimes newer versions do not exist, or will not compile, etc. So the upgrade becomes exponentially more likely to break and more of a hassle than reinstalling, exporting your data and importing it into the fresh new install. If I understand things correctly though, this would also happen in a rolling setup, however just not all at once I suppose as the big update is broken into several small updates.

So in short you can make it as rolling as you like or as stagnant as you like. Breakage is almost always going to happen in some form, just what way is the most tolerable for you? Now most importantly! You can always take a snapshot and a backup (which is suggested) before updating.The backup keeps your data safe. The snapshot makes it easy to go back if needed.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member ModdIt]

Helpful

Up

0

::

A look at this from another angle, if you have backups you are pretty safe. If you use the remaster tool
to make a complete backup of your system and ensure it boots runs correctly from a live stick before making changes
you can mitigate most risk. Pls check that a full backup system really will boo5t if everything is included. Some older
BIOS might give a problem with a giant ISO. If so just copy /home in full to a separate stick and put back what you need.

What i like to stress is the remastering tool allows for example taking high risk changes without worry or data loss,
if some care is taken. A reinstall is simply a matter of minutes. Moving to other machines has to date never failed me
which is plain amazing. Only thing which has happened many times is user login failure. I pull the LAN plug, then login
as root which to date has not failed. Use passwd command to get user password or passwords set and boot in to my familiar
work environment. You can also do just that on another computer most anywhere. Be careful if your stick is not encrypted to
keep it safe.

Same live master system with all my changes worked on T series Laptops, Asus Netbook, Dual core Pentium, Quad core AMD box
and many other weird and wonderful combinations.

A stable base with backports has been a boon to me, latest packages, (through Package Installer Tool) LO 7, Gimp,GMIC, Darktable,
Browsers, VLC thanks to a great bunch of devs as well as a helpful and knowledgable forum.

The Moddits ( user Group) are very happy here.

On Full Rolling release, I ran arch based for some time, maybe 3 years or so, during that time I had more issues than enough.
Updates failing, as well as drivers being dropped. Not to mention system d dependancy hell.

[Member Herndon]

Helpful

Up

0

::

Thank you ALL so much. What a great forum… all of you are so patient with me. What is becoming very clear is there are a VAST array of options, including naming the release (bullseye, etc) and following it from testing through it being stable. This would solve the issue of installing Antix when there are only a couple of years left in the current stable release.

I have a lot to think about! Again, I am VERY grateful for all of you.

[Moderator Brian Masinick]

Helpful

Up

0

::

While true “unstable” rolling release distributions really are not for the beginner, they are not anywhere near as “unstable”, in terms of entire system failures as you may think, based on the name. They are “unstable” because there is nearly continual change.

In the early 2000s, right after I finished a graduate degree, I went into Linux system testing wholeheartedly, grabbed some Debian systems and really went at it.
By mid to late 2001 I had a solid implementation of Debian Sid. One of my earliest Sid implementations came from a Debian derivative featuring Sid – sidux, and another one I used, either in Testing or Sid mode was Libranet, plus I also had a pure Debian Sid instance. I took the time and effort to learn their packaging well and to update them on an almost daily basis. Chances are this is NOT what a “casual” user would do whether they have prior Linux experience or not.

When MEPIS came out in the 2003 timeframe I added it to my regular mix. In 2004 Simply MEPIS, a stable, easy to use KDE-based desktop system was introduced. I used that as my every day “stable” system. Within another 1-2 years antiX came out, and by 2006 it was a distribution with it’s own release cycle. As mentioned earlier, at first antiX used Testing repositories in order to get more frequent software updates.

I did NOT have ANY issues with any of these systems, even the “unstable” Sid-based versions. I ran several of them for years without reinstalling them.
Later, antiX came out with a Core version. I built mine from scratch and I chose Sid repos. Until I tore down and disposed of all of my 32-bit laptops, antiX ran on all of them. It was one of only a few distributions that continued to work because 32-bit support gradually eroded and by then I had my 64-bit Dell Inspiron 5558. If I didn’t clean house in order to move to a smaller home, I may still have those old boxes; they worked fine.

What I am getting at is this:
1. Running Testing or Sid is for those who want more current software.
2. The technique of changing to Testing or Sid is not particularly difficult; those who do not understand should either choose to learn or stick with something they can easily handle.
3. Testing and Sid don’t contain junk software. The software works. In the Debian way of doing things, packages in Debian Stable have undergone three cycles of testing – early testing in Sid, rigorous testing with metrics and defect resolution measures to determine readiness, and final release testing, where only minor, non-critical defects are allowed to remain. So the designations in Debian pertain to the testing cycles. The applications included have already been released by their application teams. In Debian, because of the many hardware architectures it supports. packages in certain hardware groups build readily, but are challenging in others, hence the levels of testing.

Veteran software builders can happily use any of these software build streams. People who just want something to click, install and work are welcome to experiment, but most will prefer to use something either easily understood that is a drop in installation, or even a pre-built system.

--
Brian Masinick

[Author]

Posts