- This topic has 391 replies, 17 voices, and was last updated Nov 4-12:22 pm by Brian Masinick.
-
Posts
-
ProwlerGr
A few updates to antiX packages might have resulted to the removal of sysvinit scripts (affecting both sysvinit & OpenRC).
I think only connman was affected by the recent update (there might be more – I could be wrong).To fix the connman issue as a workaround
sudo apt update && sudo mv /sbin/runit /sbin/runit-bak && sudo apt -y reinstall connman && sudo mv /sbin/runit-bak /sbin/runit
Brian Masinick
I ran these, first as you suggested, then one by one, individually, NOT stringing them together, just in case any one of them did not work. I tried, (unsuccessfully) last night to run these commands: this morning it had no effect on sysVinit (did not check OpenRC yet).
This morning I tried sysVinit; no difference, so I logged in with 66, which has it’s networking functioning with Connman/CMST, so I went through the commands, NOT using && between each of them, instead running each specific command separately. I’ll check to see if that makes any difference at all, since the first way did not appear to work.
I’ll have more shortly.
--
Brian Masinick
Alternate "Search B":
This search pageBrian Masinick
@ProwlerGr – I’ve given your suggestions a couple of tries now.
I’ve definitely messed up the sysVinit and OpenRC setups, to the point that:
1) Connman/CMST continue NOT to work, despite your suggested work around, reboots, and other measures attempted to correct it.
2) Even worse, I’ve had difficulties, even with the other network management tool, Ceni; it appears that I’ve started up the network, even connected to my WiFi only connections – no Ethernet at all available where I live.
3) Just as strangely, I also have some package warnings I’m not seeing in my other setups; they haven’t stopped all software from updating, but given the difference, I’m suspicious about problems in that area too, since I don’t see them on my main antiX 23.2 Full Runit instance or my antiX 23.1(2) Full “Privacy Edition”, created from sysvinit by @calciumsodium.
4) Finally, all of this started acting up fairly recently and I may have worsened it in my attempts to get rid of the apt package warnings.I am typing this from the “init-diversity” edition; I’m using the runit edition at the moment to make sure that the changes made didn’t break runit too; (fortunately, it did not; runit, s6-* and dinit still seem to be working).
--
Brian Masinick
Alternate "Search B":
This search pageI’ve definitely messed up the sysVinit and OpenRC setups
Try this as the last resort (dbus also breaks when it gets upgraded with runit present)
sudo apt update && sudo mv /sbin/runit /sbin/runit-bak && sudo apt -y reinstall dbus connman && sudo mv /sbin/runit-bak /sbin/runitI guess I will most likely need to make the hard decision to stop offering runit on my (antiX based) init-diversity remasters, if antiX repackaging continues to remove sysvinit scripts when runit is detected.
It is not reasonable to expect users to not update their systems, or risk breaking their system every time they update or install a new deb.
anticapitalista
I’ve definitely messed up the sysVinit and OpenRC setups
Try this as the last resort (dbus also breaks when it gets upgraded with runit present)
sudo apt update && sudo mv /sbin/runit /sbin/runit-bak && sudo apt -y reinstall dbus connman && sudo mv /sbin/runit-bak /sbin/runitI guess I will most likely need to make the hard decision to stop offering runit on my (antiX based) init-diversity remasters, if antiX repackaging continues to remove sysvinit scripts when runit is detected.
It is not reasonable to expect users to not update their systems, or risk breaking their system every time they update or install a new deb.I could start checking for init-diversity in the postinst scripts and if detected (regardless of which init running) do nothing to existing init scripts.
So what is a fail proof way to detect it?Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Brian Masinick
I’ve definitely messed up the sysVinit and OpenRC setups
Try this as the last resort (dbus also breaks when it gets upgraded with runit present)
sudo apt update; sudo mv /sbin/runit /sbin/runit-bak; sudo apt -y reinstall dbus connman; sudo mv /sbin/runit-bak /sbin/runitI guess I will most likely need to make the hard decision to stop offering runit on my (antiX based) init-diversity remasters, if antiX repackaging continues to remove sysvinit scripts when runit is detected.
It is not reasonable to expect users to not update their systems, or risk breaking their system every time they update or install a new deb.I’ll try adding in the restart of both dbus AND connman, plus instead of ampersands, I’ll run the commands one at a time to ensure that each step is properly executed.
One other thing: what’s the recommended init to be running at the time that I do these steps?
Also, I’d be disappointed at having to remove runit from the equation. Though there may be issues to resolve, personally I think the more challenging and interesting alternative is to figure out an intelligent way to have all of the init alternatives co-habitate. Yes, I have another image with JUST runit, but I really happen to like runit, even with our “different way” of providing services with and for it. So I urge all of us to work together to overcome these issues, and in so doing we will all learn something about their interactions, conflicts, and methods to overcome each of these things. I like that challenge, even if I’m personally struggling with it right now, and one reason is that when we (or I) figure out what’s happening here, that’s knowledge that any of us can use to help others, plus it’s another cool way to do things differently – if for no other reason than to be unique in our services.--
Brian Masinick
Alternate "Search B":
This search pageanticapitalista
If you boot into sysVinit and update connman then it should leave the /etc/init.d/connman script alone
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
anticapitalista
If you boot into sysVinit and update connman then it should leave the /etc/init.d/connman script alone
Hmm, I just did this and both dbus and connman /etc/init.d/ scripts got removed even though they shouldn’t.
What is more baffling is why /etc/init.d/dbus gets removedPhilosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
anticapitalista
@masinick Use the live medium and copy /etc/init.d/connman and /etc/init.d/dbus into the installed /etc/init.d directory
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Brian Masinick
@masinick Use the live medium and copy /etc/init.d/connman and /etc/init.d/dbus into the installed /etc/init.d directory
Would copying them from one of my existing antiX setups (multi-partition installed images) accomplish the same thing? Hopefully yes; I’ll try that first and see if it works.
--
Brian Masinick
Alternate "Search B":
This search pageanticapitalista
@masinick Use the live medium and copy /etc/init.d/connman and /etc/init.d/dbus into the installed /etc/init.d directory
Would copying them from one of my existing antiX setups (multi-partition installed images) accomplish the same thing? Hopefully yes; I’ll try that first and see if it works.
That should work.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Brian Masinick
Good; I’m copying them from the system I used to run the init-diversity bash script from which I built the init-diversity partition; this way I’ll be able to check it out in a few minutes [hopefully].
--
Brian Masinick
Alternate "Search B":
This search pageBrian Masinick
Looks like it worked; checking out all init alternatives to make sure all is well. Assuming yes, then the solution to any changes involving systems with both sysvinit and runit in a diversity configuration suggests that making a copy of connman and dbus in another location when updating conflicting packages, then replacing them upon completion is a viable solution to the issue.
Doing more testing to confirm that everything is back in place and working properly.
--
Brian Masinick
Alternate "Search B":
This search pageBrian Masinick
It works.
So here’s one recommendation:
Create a temporary /etc/init.d-tmp directory and copy connman directory, dbus directory and any other impacted elements, now or in the future into the directory, perform the impacted updates, confirm they completed successfully and if so, the temporary directory can be removed.I suggest that this be implemented for the next update. Also, during the testing of the new script component don’t remove anything until successfully confirmed results and once solid, then the final removal of the extra directory can be safely removed.
Do others agree with this suggestion?
--
Brian Masinick
Alternate "Search B":
This search pageanticapitalista
What we need to figure out is a bullet-proof way that antiX-init-diversity debs and antiX debs for its inits can coincide.
It is not as simple as it may initially seem since our implementation of runit is different to that of ProwlerGR.
ProwlerGR had also got specific debs for the runit service scripts eg runit-connman, runit-dbus while we have them included in our nosystemd.antix debs because we wanted user to choose one init at download time ie choose our runit version or sysVinit one.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
- You must be logged in to reply to this topic.