- This topic has 61 replies, 7 voices, and was last updated Dec 16-7:34 pm by olsztyn.
-
Posts
-
Brian Masinick
Though it’s not “easy” or automatic to produce Sid images, it’s certainly NOT impossible; Debian Sid has had available images available for years. Distributions in the Kanotix/sidux/aptosid/siduction tree have also done so for at least two decades. Even Ubuntu is based on stuff from code bases ranging from “Experimental” to Sid to Testing, so even hybrid collections of packaging is possible, as long as the libraries in the packaging are compatible with the selections of software used.
As for me, I haven’t personally built one in years, but in the past, I had either two or three versions of antiX available at any point in time. My standard, usual version of antiX in the distant past was typically based on “Testing” and because of this, I generally could choose to either continue to use the software across releases or rebuild a new one when a new release came out – that’s how I sometimes had THREE – one would be the released version, a second would be my “rolling” adaptation, and a third was my customized antiX Core desktop, a Sid variation with an Xfce desktop.
While I admit that I have NOT been doing this over the past several years, I DID do this for at least a decade, and it’s both possible AND reproducible, and more than that, it actually works really well!
Once you do the work to put your creation together, after that it gets much easier!
--
Brian MasinickBobC
It looks like running the dist-upgrade on the sid causes any additional updates to no longer find the servers.
- This reply was modified 5 months ago by BobC.
Brian Masinick
It looks like running the dist-upgrade on the sid causes any additional updates to no longer find the servers.
That’s odd behavior; it sounds as if it’s changing the servers or altering the networking from a working state to a dysfunctional state.
I’d start over and carefully observe any and all changes; if the changes pertain in any way to either repositories or network updates, either note them or don’t select them; in either case retain a list of every package changed; that can be then used for further analysis to track and identify the root cause of this problem.--
Brian Masinickolsztyn
My standard, usual version of antiX in the distant past was typically based on “Testing” and because of this, I generally could choose to either continue to use the software across releases or rebuild a new one when a new release came out – that’s how I sometimes had THREE – one would be the released version, a second would be my “rolling” adaptation, and a third was my customized antiX Core desktop, a Sid variation with an Xfce desktop.
Very similar to what I am attempting to do. Stable production version is what I am running now. SID version is what I am attempting to put together would be managed version in terms of tested upgrades to develop new baseline.
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersBrian Masinick
@olsztyn: What you are attempting to do is definitely possible. It’s certainly easier if you set up your initial configurations during a period when most, if not all, of the packages and libraries correctly match. Then you can build your initial system. Then, as you update it, you can reject, or omit, any updates that upset the packaging balance, or you can “walk on the wild side” with one of them, experiment, break, and learn from that one, reinstalling when necessary, while also retaining at least one really solid, stable version.
That’s exactly what I did in the early days. The good news is that even package breakages only occasionally break the system; that most commonly occurs when you effectively break networking. There are at least TWO ways to fix it: the easiest is to reinstall, the more difficult, but sometimes the way to really learn a few things is to find the right combination of packages and libraries, then manually graft (place) them back into the defective system, then reboot it and find out whether the changes work or fail. These things can take time, and like I also said, sometimes it results in a disaster, but as long as you make sure you have other working systems, it’s well worth the practice and it greatly helps to learn things.
I’m getting to the age where I no longer remember everything I’ve done anymore, unless I have notes or examples. Many times that’s why I write about them here and in other places; I have on-line journals of what I’ve done, so looking them up, I can reproduce things I’ve done in the past.
You may have different, possibly better techniques; we each have our methods; I’m hoping only to stimulate ideas, not dictate anyone else’s personal approach. As we each try things out and share our ideas, sometimes we find better solutions; other times we share something good; each of us is free to decide what’s best for our personal situations and our current objectives.
--
Brian Masinicklive-remaster changed antix.list to an invalid server, it looks. I had saved the /etc folder just before the remaster. I remastered, then rebooted, now its different.
PS: I see it also changed the debian server.
- This reply was modified 5 months ago by BobC.
I’m going to stop. This is hopeless. It’s like being back in 1986 with MicroPort or 2007 with Arch.
My hardwired ethernet no longer works. No need to reply or try to assist further. Thanks for trying.
anticapitalista
Debian sid (systemd) is easy to maintain.
antiX-sid (systemd-free and elogind-free) is much more of a moving target.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Brian Masinick
Debian sid (systemd) is easy to maintain.
antiX-sid (systemd-free and elogind-free) is much more of a moving target.That makes sense and it also explains the difficulties.
Great challenge for those with the time and energy to pursue! 🙂
--
Brian MasinickantiX-sid (systemd-free and elogind-free) is much more of a moving target.
Understood. I do appreciate (I am sure others do too) your continual putting work into modifying packages to systemd-free and elogind-free versions. It is a moving target indeed.
Once I succeed (if I do) in putting together a Base-lookalike SID working baseline I am not planning to run indiscriminate updates to baseline. New changes will be permanently incorporated only after testing. So in a way attempting to put together a relatively stable and working SID that on occasions could be slightly behind the ‘official’ and wild SID.
My testing criteria for SID baseline will be:
– Must boot successfully on all machines I have.
– No systemd or *elogind* ‘virus’ introduced.
– Booting all the way to IceWM (or JWM) and all functions appear to be working as expected.It would be easier project if some working antiX SID Base was already available but there is none so far officially available so it is in the individual court to attempt to put together such one for testing…
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersI understand… I will just try to get it running without upgrading for now. It sounds like an arduous list of tasks.
anticapitalista
IMO trying to have some sort of base with X environment antiX-sid is doomed to fail (which is why I have not made available any iso files with a graphical environment).
antiX has built a systemd/elogind-free xserver-xorg version so that needs to be working before anything else (graphically speaking).
Another component is our modified apt package. Also vte needs to be systemd/elogind – free.
Upstream Debian sid can make any such antiX package ‘faulty’ before we can package, upload our systemd/elogind -free fixes.
It is impossible for our tiny team to support an antiX-sid-base iso.- This reply was modified 5 months ago by anticapitalista.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Brian Masinick
IMO trying to have some sort of base with X environment antiX-sid is doomed to fail (which is why I have not made available any iso files with a graphical environment).
antiX has built a systemd/elogind-free xserver-xorg version so that needs to be working before anything else (graphically speaking).
Another component is our modified apt package. Also vte needs to be systemd/elogind – free.
Upstream Debian sid can make any such antiX package ‘faulty’ before we can package, upload our systemd/elogind -free fixes.
It is impossible for our tiny team to support an antiX-sid-base iso.I accept and understand this. I love using our distribution and I use it every day as part of my regular computer use.
Recognizing also that we do certain things well and other systems also do other things well, I use a variety of distributions and tailor each of them to either use or experiment with various things.
True Debian Sid definitely isn’t systemd free, but it can certainly be useful for certain things. A distribution called siduction can be helpful for those who have those occasional needs, and those of us who are able to either load or use more than one distribution may find it useful for certain things. I still like it, but I don’t mix it with antiX; I keep copies of each and use each of them for specific reasons and use cases.
I wrote another post in the “Whatever” thread about the distributions I have available on my HP-14 laptop; I keep a copy of antiX on ALL of my systems, even those tucked in a corner the majority of the time; antiX works on all of my Linux-based systems.
--
Brian MasinickIMO trying to have some sort of base with X environment antiX-sid is doomed to fail (which is why I have not made available any iso files with a graphical environment).
antiX has built a systemd/elogind-free xserver-xorg version so that needs to be working before anything else (graphically speaking).Thank you for confirming. I spent lots of time the past two days trying (unsuccessfully) to build a SID antiX with IceWM from SID Core ISO. Regardless whether upgrades were done before or after Xorg and the entire kaboodle of graphical environment installation the resulting SID antiX was not booting to IceWM. The same as before…
Not ready yet to give up on such challenge I decided on a different approach, which seems to be finally working. The process to arrive to SID antiX Base I used was the following:
– Started from antiX 22 Runit Base ISO, instead of SID Core ISO.
– Ran update and all upgrades with apt dist-upgrade.
– Installed Synaptic. This allowed to better see and control upgrading steps to SID going forward.
– Replaced kernel from 4.9 to 5.10.142 for the time being, but will also include kernel 6.0.
– Changed repositories to SID/Debian Unstable in preparation to move to SID world.From experience, an indiscriminate upgrade to SID across the board leads to the same failure as before. The upgrade to SID must be done manually and selectively, being sensitive to antiX architecture.
Manual process. I may be missing a few details but the idea is the same and can be repeated by anyone:
– Upgrade all antiX specific files to their new antiX SID versions, so those appended with ‘Nosystemd’ or ‘antix’.
– Upgrade those packages that are antiX specific in SID but not yet in antiX 22 Base.
– Do not upgrade yet those files that are antiX specific as above in antiX 22 Stable but their SID version is not yet antiX specific.
– Gradually select for upgrade the remaining packages (not antiX specific) that have new versions in SID. This I have done in steps, after each step verifying the new system is still working fine.
In principle:
The objective is to create an antiX SID Base that would be antiX specific after all, so:
– Do not upgrade packages that replace systemd/elogind-free versions with their systemd Debian versions
– Do not upgrade packages that in turn remove Runit init files or remove seatd.
– Do not install packages that in their turn install elogind or libelogind0.Is there any problem with this approach to create a SID antiX base, that I am missing?
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersModdIt
I am unsure how well it would work but maybe worth pinning elogind libelogind0 libpam-elogind
to a minus value in a file called for example /etc/apt/preferences.d/05elogind for first package
I am unsure if you then need 010packagename for next package then 015packagename and so on.
I only used the method to pin my nvidia driver so it would not be destroyed as happened several
times in the past.00systemd for example uses text as below to prevent inadvertant install.
Package: *systemd*:any Pin: origin * Pin-Priority: -1
- You must be logged in to reply to this topic.
