MX Linux Forum

Posted: **Tue Sep 17, 2019 10:11 pm**

My question is at the bottom.

# Background and History

Unbelievable!
I try my best to make sure systemD is NOT installed on my system as it royally mucks up absolutely everything eventually.
I check all dependencies to be installed and wrote a cron script to notify me if systemD snake ever wormed its way onto my servers.

SystemD was NOT installed on my system, as I make sure the snake doesnt muck up a perfect system....which it always does/

Well, today I did a simple

Code: Select all

apt update
apt upgrade

Lo and behold systemD was installed again during the upgrade, although, it was NEVER installed before the aptery I mention above.
My cron script sounded the alarm halfway during the upgrade and there it was systemd installed again even though there was no systemD installed before.

This time systemD really mucked up everything.
Trying to uninstall systemD
it uninstalled the following

Code: Select all

pulseaudio pulseaudio-module-bluetooth pulseaudio-module-jack
  python3-pyqt5.qtwebengine qml-module-org-kde-kio
  qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons
  simplescreenrecorder squeezelite unpaper vlc vlc-plugin-base
  vlc-plugin-vlsub vlc-plugin-zvbi x264

Go figure .... and also uninstalled a loooot of kernel modules I carefull insmodded for my server top work.
The systemD crap just broke things it was not even supposed to be controlling.

So systemD installed itself and absolute wrecked my server.

After systemD was removed and then I tried

Code: Select all

apt update
apt upgrade

again,
Lo and behold the snake systemD installs itself again.

This time when I tried to do an
apt remove systemd I get.

Code: Select all

# apt remove systemd
Reading package lists... Done
Building dependency tree       # apt remove systemd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  systemd
0 upgraded, 0 newly installed, 1 to remove and 15 not upgraded.
After this operation, 9,516 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 636371 files and directories currently installed.)
Removing systemd (232-25+deb9u12) ...
systemd is the active init system, please switch to another before removing systemd.
dpkg: error processing package systemd (--remove):
 subprocess installed pre-removal script returned error exit status 1
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Reading state information... Done
The following packages will be REMOVED:
  systemd
0 upgraded, 0 newly installed, 1 to remove and 15 not upgraded.
After this operation, 9,516 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 636371 files and directories currently installed.)
Removing systemd (232-25+deb9u12) ...
systemd is the active init system, please switch to another before removing systemd.
dpkg: error processing package systemd (--remove):
 subprocess installed pre-removal script returned error exit status 1
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

So, SystemD now refuses to uninstall itself as I have to first install another init.
SysVinit is ALREADY installed.

Question1)
How do I resolve this.

SystemD is the ultimate PITA.
I tried to blacklist it in dpkg but it does not work. as you can see attempts to do so never really works.
https://askubuntu.com/questions/75895/h ... -installed

Question2) Anyone has a way to ultimately block a package .... such as systemDuh

Posted: **Tue Sep 17, 2019 10:19 pm**

You resolve by using antix. Mx repos are not systemd free. The debian pulseaudio package depends on systemd i think. Antix packages one that doesnt.

Posted: **Tue Sep 17, 2019 10:25 pm**

Is the system forcing you to boot into SystemD, and if so, what problems are you experiencing?

You'll probably do more harm than good trying to "block systemd" than simply not booting into it in the first place. Since MX uses SysV Init by default, you are unlikely to experience a systemd problem unless you choose to boot into it. Although systemd is installed, it doesn't get run unless you make a choice to run it.

And if you're worried about systemd getting on your perfect, pristine, holy and pure system, pay attention to the Linux kernel which supports lots of file systems you'll probably never use, and is now bloated to the core. But we all still live with it.

Posted: **Tue Sep 17, 2019 10:41 pm**

Here we go again. Seems to be another rehash of your thread here...

https://forum.mxlinux.org/viewtopic.php ... el#p522180

We've tried to explain MX's position on systemd many times.

Posted: **Tue Sep 17, 2019 10:42 pm**

For the umpteenth time, zimbodel:
https://mxlinux.org/about-us/

Our Positions
Systemd

Because the use of systemd as a system and service manager has been controversial, we want to be clear about its function in MX Linux. Systemd is included by default but not enabled. You can scan your MX system and discover files bearing systemd* names, but those simply provide a compatibility hook/entrypoint when needed.

MX Linux uses systemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVinit remains the default init yet MX Linux can use Debian packages that have systemd dependencies such as CUPS. This approach also allows the user to retain the ability to choose his/her preferred init. For details, see the MX/antiX Wiki.

https://mxlinux.org/wiki/system/systemd/

If you want a Linux distro that's completely, entirely, utterly systemd-free MX isn't it. Feel free to use another distro such as antiX or Devuan instead.

SystemD merely being present in MX but not being used isn't going to break anything, but attempting to rip necessary components out of MX by their roots surely will, as you've found. As far as how to fix your system goes, reinstall MX and leave it alone. Or as I said, change to a different distro that's completely systemd-free.

Posted: **Tue Sep 17, 2019 10:44 pm**

Code: Select all

aptitude why systemd

generally will tell you what's going on with the upgrade pulling it in, too.

Posted: **Tue Sep 17, 2019 11:48 pm**

Mx works perfectly without systemd, so did pulseaudio and myriads of applications.
SystemD was not at all needed.
It comes up again, because the SystemD snake struck again ..... dont understand your issue about other posts.
Two trainwrecks doesnt make one trainwreck.

So...

MX was the best OS I ever had to work with without systemd, I guess some of you are hell bent to stab me with my own problem but missed my many compliments..........
It actually works fantastic when systemD is not installed and I used it now for abou 6 months without systemd....flawless.
The curiously unwarranted SystemD however now borked it good!

Fair you made it clear now that MXLinux is a systemD Debian Roll, so I will move to Devuan.
I already have two servers running Devuan and it works great.

Thank you for the heads up that I should have used Antix to be systemD free.
I think the problem arose that Antix/MX are so intertwined that it is hard to see the difference.
If I knew that I would have used antix.

I thank all for the kind !@#$%$%^^ you so I will leave and move to Devuan and if that doesnt work to Antix.
I just had it with systemD messing up perfectly working systems.
I just had it.
I came to MX on recommendation from a package developer involved at MX who invited me over due to my SystemD problems I posted elsewhere. He must have meant Antix and not MX.
He meant well,. but I can see his company doesnt serve him well.

It will be a month to rebuild all my MX servers to run all applications on Devuan but it is worth everything possible to be free of the SystemD rubbish.
I cannot maintain the servers for two businesses with MX systemD crap interjecting itself all the time. Devuan so far gives me zero trouble.

I thank those responses above who tried to help with the problem without agenda.
Thank you very much

Bye.

Posted: **Tue Sep 17, 2019 11:54 pm**

Stevo wrote: Tue Sep 17, 2019 10:44 pm
Code: Select all
aptitude why systemd
generally will tell you what's going on with the upgrade pulling it in, too.

Thanks for the honest attempt to help.

As you can see very little is dependent.
For some reason rtkit installed in the upgrade, it wasnt installed beforehand either.
I know that it wasnt there as I keep textfiles of cron dumps of what is installed on my computer every hour to detect anything new appearing out of the blue or to see what really happened during an app install.

Code: Select all

$ aptitude why systemd
i   rtkit          Depends policykit-1               
i A policykit-1    Depends libpam-systemd            
iBA libpam-systemd Depends systemd (= 232-25+deb9u12)

What will help is if I can switch to another init system. That way I can get rid of systemD
As I mention SysVinit is already installed and ran before the apt upgrade, but somehow systemD cannot figure out to activate a different init when uninstalled.

Do you know ho to resolve this ?
I already did

Code: Select all

cp /usr/share/sysvinit/inittab /etc/inittab

but systemD still doesnt recognise the SysVinit is now to be the new init system and therefore borks its own uninstallation.

I solved it: It finally uninstalled.
It refused to uninstall with

Code: Select all

apt uninstall systemd

but it was removed good with

Code: Select all

apt remove  --purge --auto-remove systemd

There should not be a difference, where the former throws an error and the latter just does it, but hey its systemd.
It has its fingers everywhere. Jack of all trades Master of Nothing.

Seems like purging some config files makes systemd forget about another init, so why even bother with the bogus error, which is most likely bogus to keep you in SystemD.
Thanks for your help, I should be able to bring this server up to how it was again and then move them all over to Devuan during next 30 days.

Posted: **Wed Sep 18, 2019 4:05 am**

As long as you don't boot in systemd when you are in grub (you can select it in advanced) you are not using systemd.
It is there, yes, for those who DO need it.

It's like a browser and google.

You can open a browser and use google. Or not. If you don't want to use google simply don't go there. It will still BE there even if you don't go there, but it won't influence the browser.

If you absolutely want nothing to do with systemd, then you either remove all of it (although I don't know if it is possible to remove the whole thing *shrug*) or use a distro that is completely systemd free, like antiX.

Posted: **Wed Sep 18, 2019 5:10 am**

Reasoning will never make a Man correct an ill Opinion, which by Reasoning he never acquired

-Jonathan Swift, from A Letter to a Young Gentleman, Lately Enter’d Into Holy Orders by a Person of Quality (1721)

Posted: **Wed Sep 18, 2019 5:34 am**

MX works absolutely great with the entire systemD removed.
I never had any purpose fopr it other than messing up great working systems.
It truly is superfluous garbage that truies to do too many things that are done better by separate daemons and programs.

AGAIN, I totally remove systemD and then it works stellar and all my problems disappear with cron not working, sound interference with jack and pulse, alsa that does horrible strange things. etc.
As soon as systemD is gone, these problems resolve...

It seems like no one here ever tried running MX without SyastemD !?
From the responses it sure seems so.

NO, I dont boot the systemD MX kernels. I never will make that mistake again.

The big problem is keeping systemD not to install itself by some dependency I overlooked.
At the moment I first have to grep apt through a pipe to detect systemD before I install anything, but somehow it still installs sometimes.

What will really help me is a means to completely ban systemD from installing through apt/dpkg.
That would be great, but I couldnt find a working solution.

Eadwine Rose wrote: Wed Sep 18, 2019 4:05 am As long as you don't boot in systemd when you are in grub (you can select it in advanced) you are not using systemd.
It is there, yes, for those who DO need it.

It's like a browser and google.

You can open a browser and use google. Or not. If you don't want to use google simply don't go there. It will still BE there even if you don't go there, but it won't influence the browser.

If you absolutely want nothing to do with systemd, then you either remove all of it (although I don't know if it is possible to remove the whole thing *shrug*) or use a distro that is completely systemd free, like antiX.

Posted: **Wed Sep 18, 2019 5:37 am**

Rrrightio...

“Your worst dungeon might be the room with the most windows.”

JayM wrote: Wed Sep 18, 2019 5:10 am
Reasoning will never make a Man correct an ill Opinion, which by Reasoning he never acquired
-Jonathan Swift, from A Letter to a Young Gentleman, Lately Enter’d Into Holy Orders by a Person of Quality (1721)

Posted: **Wed Sep 18, 2019 5:38 am**

I always run MX without systemD. I do not choose it in the boot menu. Therefore I am not running it under systemD.

Posted: **Wed Sep 18, 2019 5:55 am**

zimbodel wrote: Wed Sep 18, 2019 5:34 am It seems like no one here ever tried running MX without SyastemD !?
From the responses it sure seems so.

Personally, I do so every single time I turn on my computer. I simply don't select the systemd init option in the grub boot menu. All of my PCs have been systemd-free since I began using MX.

Posted: **Wed Sep 18, 2019 6:32 am**

Zimbodel

The thing that is happening here is that the post you made has lots of drama in it, as if systemd just ate your youngest child or something, which is what people are going to react to and the actual question you WANT to get an answer to gets overlooked. Think about it, asking plainly what you want to know without all the swearing and stuff around it will get you the answer you want much sooner.

I wager you really wanted to ask this:

"Can I completely get rid of systemd? I just don't want it installed on my system at all because I don't like it. How do I do that if possible?"

You would have gotten the exact answer you needed in no time, without the need to defend your decision.

Posted: **Wed Sep 18, 2019 6:32 am**

zimbodel wrote: Wed Sep 18, 2019 5:37 am Rrrightio...

“Your worst dungeon might be the room with the most windows.”

Posted: **Wed Sep 18, 2019 6:42 am**

Hey if Z wants to run systemd-free on the since of it not even installed that ok with me. But MX's repos (and debian's) are not set up for it. At least not without a lot of work. libpam-systemd dpeendecies are usually the culprit.

for those that want to run as systemd-free as possible, they should start with antix (or Devuan but I'm partial to antix)

Posted: **Wed Sep 18, 2019 7:19 am**

Or one of these:
(from https://ungleich.ch/en-us/cms/blog/2019 ... t-systemd/)
Alpine Linux, Arctixlinux, Void, Slackware, Gentoo, Funtoo, GUIX, Linux From Scratch, Crux, PCLinuxOS (one of my old favorites.)

Posted: **Wed Sep 18, 2019 8:45 am**

I think the answer to his question is:

if you want to keep running mx with no systemd-related packages at all, then you are making a choice to have to conduct occasional pruning and package removal whenever certain packages update, because of systemd-related dependencies.

That is inevitable because of the way mx and Debian is set up, as dolphin has explained.

There's no point complaining about your removal struggles, because it's going to keep happening once in a while.

Posted: **Wed Sep 18, 2019 12:35 pm**

The problem you have starts with blindly accepting updates without looking at what new dependencies they drag in.
If there is something you want to keep off your computer you must watch what is installed every time.

Posted: **Sun Sep 22, 2019 2:20 pm**

Hi jeffrey, exactly, but I think you missed the CRON part of my posts which addresses this if systemD is accidentally installed again.
I found that the list of packages "going to be installed in apt" and specifically MXInstaller, is not perfect .
Surely you dont profess that the listed packages to be installed is perfect and the gospell?
I had it often that it lists no systemD to be installed, but then it is installed regardless and my cron script allerts me right after installation.
It is annoying.

To some of the other comments.
I think we get a bit off track.
Of course I dont boot with the systemD kernel.
I am talking about systemD creeping back in as a dependency and totally mucking up everything including CRON which it usurps and make into something else which doesnt execute my cronjobs anymore, several sound issues with JACK pops up, alsa stops recognizing particular devices, rc.local doesnt execute anymore neither does @reboot and the list of annoyance just goes on.

As I ran MX for the last couple of months it was stellar with no SystemD installed. Everytime I picked up trouble out of the blue, lo and behold SystemD slithered onto the drives again. That is why I let Cron warn me on a per minute basis.

jeffreyC wrote: Wed Sep 18, 2019 12:35 pm The problem you have starts with blindly accepting updates without looking at what new dependencies they drag in.
If there is something you want to keep off your computer you must watch what is installed every time.

Posted: **Sun Sep 22, 2019 2:42 pm**

cat /var/log/apt/history.log may show us what part of systemd got installed and why.

Also inxi -r (it shows the repos you use)

Posted: **Sun Sep 22, 2019 2:48 pm**

zimbodel wrote: Sun Sep 22, 2019 2:20 pmI had it often that it lists no systemD to be installed, but then it is installed regardless and my cron script allerts me right after installation.

I'm pretty sure you are mistaken about this, please post a relevant except from the APT package log to verify your claim. Full command output would be better if you can reproduce this.

zimbodel wrote: Sun Sep 22, 2019 2:20 pmOf course I dont boot with the systemD kernel.

Not according to your OP:

zimbodel wrote: Tue Sep 17, 2019 10:11 pm
Code: Select all
systemd is the active init system, please switch to another before removing systemd.

You were booted with systemd (not "SystemD") running as PID1 when this message appeared.

Is systemd specified on the kernel command line?

Code: Select all

cat /proc/cmdline

Or is it symlinked to init?

Code: Select all

ls -l /sbin/init

zimbodel wrote: Sun Sep 22, 2019 2:20 pmI am talking about systemD creeping back in as a dependency and totally mucking up everything including CRON which it usurps and make into something else which doesnt execute my cronjobs anymore, several sound issues with JACK pops up, alsa stops recognizing particular devices, rc.local doesnt execute anymore neither does @reboot and the list of annoyance just goes on.

As I ran MX for the last couple of months it was stellar with no SystemD installed. Everytime I picked up trouble out of the blue, lo and behold SystemD slithered onto the drives again. That is why I let Cron warn me on a per minute basis.

I think you are getting confused here, if you don't even know that you're using systemd as init then I doubt that you have a firm grasp on the situation.

For the record if systemd is installed but not running as PID1 (init) then it cannot influence the workings of your system at all. And to enable rc.local under systemd simply make the file executable.

Posted: **Sun Sep 22, 2019 3:41 pm**

To Head_on_a_Stick:
Nope I dont think I am the one who is confused here:

Code: Select all

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=c7eca528-9d40-4071-ab79-c273b78e0185 ro quiet
$ ls -l /sbin/init
-rwxr-xr-x 1 root root 44856 Apr 23 16:21 /sbin/init

Posted: **Sun Sep 22, 2019 3:45 pm**

Head_on_a_Stick wrote: Sun Sep 22, 2019 2:48 pm For the record if systemd is installed but not running as PID1 (init) then it cannot influence the workings of your system at all. And to enable rc.local under systemd simply make the file executable.

So what ?
It mucks up rc.local execution out of the box, and on all my servers which has systemDuh rc.local NEVER executes after I chmod
+x it as what ashouold make it execute. Furthermore SystemDuha bsolutely REFUSES to execute @reboot in crontabs.

This is a different issue, which is well documented as systemD issues, so lets stick to my original questions please.

Posted: **Sun Sep 22, 2019 3:50 pm**

anticapitalista wrote: Sun Sep 22, 2019 2:42 pm cat /var/log/apt/history.log may show us what part of systemd got installed and why.

Also inxi -r (it shows the repos you use)

Here you go,

Code: Select all

$ cat /var/log/apt/history.log |grep -i systemd 
Install: gir1.2-soup-2.4:amd64 (2.56.0-2+deb9u2, automatic), libpam-systemd:amd64 (232-25+deb9u11, automatic), gufw:amd64 (17.04.1-1.1), policykit-1:amd64 (0.105-18+deb9u1, automatic), gir1.2-webkit2-4.0:amd64 (2.24.3-1~mx17+1, automatic), gir1.2-javascriptcoregtk-4.0:amd64 (2.24.3-1~mx17+1, automatic)
Upgrade: kicad-footprints:amd64 (5.1.2-1~mx17+1, 5.1.3-1~mx17+1), libopencv-core-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), mx-packageinstaller-pkglist:amd64 (19.05.07, 19.05.08), grub-themes-mx:amd64 (18.12.02, 19.08.03), librecad-data:amd64 (2.1.2-1, 2.1.2-1+deb9u1), musescore-common:amd64 (2.3.2+dfsg1-1~mx17+1, 2.3.2+dfsg2-6~bpo9+1), libkf5config-data:amd64 (5.28.0-2, 5.28.0-2+deb9u1), linux-headers-4.9.0-9-common:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), firmware-iwlwifi:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libnghttp2-14:amd64 (1.18.1-1, 1.18.1-1+deb9u1), libgles2-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), vlc-plugin-svg:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), grub-efi:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), firmware-realtek:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), mx-usb-unmounter:amd64 (19.04, 19.08.01), libcups2:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libcups2:i386 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-nouveau2:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-nouveau2:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libsox-fmt-all:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-ivtv:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libsox-fmt-ao:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), linux-libc-dev:amd64 (4.20-2~mx17+1, 5.2.9-1~mx17+1), linux-libc-dev:i386 (4.20-2~mx17+1, 5.2.9-1~mx17+1), libldap-2.4-2:amd64 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), libldap-2.4-2:i386 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), vlc-plugin-samba:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libxslt1-dev:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), libllvm7:amd64 (1:7-6~mx17+1, 1:7.0.1-8~deb9u2), libllvm7:i386 (1:7-6~mx17+1, 1:7.0.1-8~deb9u2), libsox-fmt-pulse:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), libopencv-ml-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), libegl1-mesa-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), qemu-system-mips:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), qemu-system-misc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), libegl-mesa0:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), kicad-demos:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), qemu-system-ppc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), vlc-plugin-qt:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), linux-image-4.9.0-9-amd64:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), libsystemd0:amd64 (232-25+deb9u11, 232-25+deb9u12), libsystemd0:i386 (232-25+deb9u11, 232-25+deb9u12), shotwell-common:amd64 (0.30.2-0.1~mx17+1, 0.30.7-0.1~mx17+1), adobe-flash-properties-gtk:amd64 (1:20190709.1-1mx17+1, 1:20190910.1-1mx17+1), grub-common:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), libgd3:amd64 (2.2.4-2+deb9u4, 2.2.4-2+deb9u5), libgd3:i386 (2.2.4-2+deb9u4, 2.2.4-2+deb9u5), libasprintf-dev:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libfaad-dev:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), featherpad:amd64 (1:0.10.0-1~mx17+1, 1:0.11.1-1~mx17+1), libgs9:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libglapi-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libglapi-mesa:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), mesa-common-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), neofetch:amd64 (6.0.0-1~mx17+1, 6.1.0-1~mx17+1), libicu57:amd64 (57.1-6+deb9u2, 57.1-6+deb9u3), libicu57:i386 (57.1-6+deb9u2, 57.1-6+deb9u3), libasprintf0v5:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), vlc-plugin-skins2:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), firmware-amd-graphics:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), vlc-plugin-visualization:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libkf5configcore5:amd64 (5.28.0-2, 5.28.0-2+deb9u1), libsox2:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), libgettextpo0:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), qemu-system-x86:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), firmware-myricom:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), insserv:amd64 (1.14.0-5.4+b1, 1.18.0-2mx17+1), libxatracker2:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), openssh-sftp-server:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), firmware-samsung:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), vlc-plugin-notify:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libtk-img:amd64 (1:1.4.6+dfsg-1, 1:1.4.6+dfsg-1+deb9u1), grub2-common:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), skypeforlinux:amd64 (8.50.0.38, 8.52.0.138), udev:amd64 (232-25+deb9u11, 232-25+deb9u12), libfribidi-dev:amd64 (0.19.7-1+b1, 0.19.7-1+deb9u1), libegl1-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), cups-server-common:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), mx-tools:amd64 (19.4, 19.9.01), x42-plugins:amd64 (2:20190206-1kxstudio1, 2:20190820-1kxstudio1), libsox-fmt-mp3:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-atheros:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), qemu-user:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), linux-compiler-gcc-6-x86:amd64 (4.20-2~mx17+1, 5.2.9-1~mx17+1), cups-common:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libsox-fmt-alsa:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), brave-browser-beta:amd64 (0.69.119, 0.70.97), libsox-fmt-oss:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-libertas:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libudev1:amd64 (232-25+deb9u11, 232-25+deb9u12), libudev1:i386 (232-25+deb9u11, 232-25+deb9u12), firmware-netxen:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcaca-dev:amd64 (0.99.beta19-2+b2, 0.99.beta19-2.1~deb9u1), libgettextpo-dev:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libgbm1:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), adobe-flashplugin:amd64 (1:20190709.1-1mx17+1, 1:20190910.1-1mx17+1), libkf5configgui5:amd64 (5.28.0-2, 5.28.0-2+deb9u1), kicad-libraries:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), grub-pc-bin:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), smxi-inxi-antix:amd64 (0.4.16, 0.4.17), libmlt-data:amd64 (6.12.0-1~mx17+1, 6.16.0-3~mx17+1), libdrm-amdgpu1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-amdgpu1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), firmware-intelwimax:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libmbedtls-dev:amd64 (2.4.2-1+deb9u3, 2.16.0-1~mx17+1), gthumb:amd64 (3:3.4.4.1-5, 3:3.4.4.1-5+deb9u1), libva2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), libva2:i386 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), qemu:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), grub-efi-amd64-bin:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), libudev-dev:amd64 (232-25+deb9u11, 232-25+deb9u12), cups-ppdc:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), firmware-linux-nonfree:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcupsmime1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libcaca0:amd64 (0.99.beta19-2+b2, 0.99.beta19-2.1~deb9u1), firmware-brcm80211:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), firmware-intel-sound:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), reportbug:amd64 (7.1.7+deb9u2, 7.1.7+deb9u3), libnss-myhostname:amd64 (232-25+deb9u11, 232-25+deb9u12), sox:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), ssh:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), mx-snapshot:amd64 (19.7.3, 19.9), qemu-utils:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), faad:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), libldap-common:amd64 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), libwayland-egl1-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), gthumb-data:amd64 (3:3.4.4.1-5, 3:3.4.4.1-5+deb9u1), libopencv-flann-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), firmware-qlogic:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libmbedx509-0:amd64 (2.4.2-1+deb9u3, 2.16.0-1~mx17+1), mx-codecs:amd64 (19.4.3, 19.9), vlc-plugin-access-extra:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), librecad:amd64 (2.1.2-1+b1, 2.1.2-1+deb9u1), libpam-systemd:amd64 (232-25+deb9u11, 232-25+deb9u12), qemu-system-sparc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), clamav:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), libdrm2:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm2:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), linux-kbuild-4.9:amd64 (4.9.168-1+deb9u4, 4.9.189-3), liquidsoap:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), ghostscript:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libopencv-imgproc-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), systemd:amd64 (232-25+deb9u11, 232-25+deb9u12), shotwell:amd64 (0.30.2-0.1~mx17+1, 0.30.7-0.1~mx17+1), linux-image-4.19.0-5-amd64-unsigned:amd64 (4.19.37-2~mx17+2, 4.19.37-5+deb10u2~mx17+1), python3-reportbug:amd64 (7.1.7+deb9u2, 7.1.7+deb9u3), clamav-freshclam:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), lightning:amd64 (2:60.8.0-1~mx17+1, 2:60.8.0-2~mx17+1), libgl1-mesa-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), openssh-server:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), ghostscript-x:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libgl1-mesa-dri:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgl1-mesa-dri:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), unzip:amd64 (6.0-21+deb9u1, 6.0-21+deb9u2), openssh-client:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), grub-efi-amd64:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), linux-headers-4.9.0-9-amd64:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), firmware-misc-nonfree:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libosmesa6:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgs9-common:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), thunderbird:amd64 (2:60.8.0-1~mx17+1, 2:60.8.0-2~mx17+1), usbutils:amd64 (1:007-4+b1, 1:007-4+deb9u1), mx-packageinstaller:amd64 (19.7.3, 19.9), palemoon:amd64 (28.6.1+repack-1~mx17+1, 28.7.1+repack-1~mx17+1), catfish:amd64 (1.4.7-0.1~mx17+1, 1.4.10-0.1~mx17+1), vlc-plugin-video-splitter:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), liquidsoap-plugin-alsa:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), libgl1-mesa-glx:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgl1-mesa-glx:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libcupsppdc1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-intel1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-intel1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), xfce4-weather-plugin:amd64 (0.9.0really0.8.11-0.1~mx17+1, 0.10.0-0.1~mx17+1), apache2-bin:amd64 (2.4.25-3+deb9u7, 2.4.25-3+deb9u8), libva-x11-2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), firefox:amd64 (68.0.1~mozillabinaries-1mx17+1, 69.0~mozillabinaries-1mx17+1), libva-wayland2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), firmware-bnx2x:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), mx-tweak:amd64 (19.05.01, 19.05.04), libopencv-photo-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), clamav-base:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), kicad:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), libdrm-radeon1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-radeon1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libva-drm2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), qemu-system-arm:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), mesa-vdpau-drivers:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), cups-core-drivers:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), autopoint:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), cups-daemon:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libsdl-image1.2:amd64 (1.2.12-5+deb9u1, 1.2.12-5+deb9u2), libsox-fmt-base:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), xsltproc:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), gettext-base:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), gettext:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libcupsimage2:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), opera-stable:amd64 (62.0.3331.99, 63.0.3368.91), cups:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), musescore-general-soundfont:amd64 (0.1.1-2~mx17+1, 0.1.7-2~mx17+1), firmware-linux:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcupscgi1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), cups-client:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-dev:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), virtualbox-6.0:amd64 (6.0.10-132072~Debian~stretch, 6.0.12-133076~Debian~stretch), kicad-templates:amd64 (5.1.0-1~mx17+1, 5.1.3-1~mx17+1), libopencv-video-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), linux-source-4.19:amd64 (4.19.37-2~mx17+1, 4.19.67-2~mx17+1), firmware-bnx2:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), qemu-system-common:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), liquidsoap-plugin-gstreamer:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), firmware-ipw2x00:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libfribidi0:amd64 (0.19.7-1+b1, 0.19.7-1+deb9u1), qemu-system:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), mesa-va-drivers:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libxslt1.1:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), libxslt1.1:i386 (1.1.29-2.1, 1.1.29-2.1+deb9u1), base-files:amd64 (9.9+deb9u9, 9.9+deb9u11), tzdata:amd64 (2019a-0+deb9u1, 2019b-0+deb9u1), libglx-mesa0:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libglx-mesa0:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libdrm-common:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1)
Commandline: apt remove systemd
Remove: libpam-systemd:amd64 (232-25+deb9u12), systemd:amd64 (232-25+deb9u12), gufw:amd64 (17.04.1-1.1), policykit-1:amd64 (0.105-18+deb9u1)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Install: rtkit:amd64 (0.11-4+deb9u1), paprefs:amd64 (0.9.10-2+b1), pulseaudio-module-zeroconf:amd64 (10.0-1+deb9u1, automatic), libpam-systemd:amd64 (232-25+deb9u12, automatic), policykit-1:amd64 (0.105-18+deb9u1, automatic), pulseaudio-module-gconf:amd64 (10.0-1+deb9u1, automatic), libgconfmm-2.6-1v5:amd64 (2.28.3-1, automatic)
Commandline: apt remove libpam-systemd
Remove: libpam-systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove --purge --auto-remove systemd
Purge: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Install: systemd-sysv:amd64 (232-25+deb9u12, automatic)
Remove: systemd-sysv:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove --purge --auto-remove systemd
Purge: systemd:amd64 (232-25+deb9u12)

Posted: **Sun Sep 22, 2019 4:00 pm**

dolphin_oracle wrote: Wed Sep 18, 2019 6:42 am Hey if Z wants to run systemd-free on the since of it not even installed that ok with me. But MX's repos (and debian's) are not set up for it. At least not without a lot of work. libpam-systemd dpeendecies are usually the culprit.

for those that want to run as systemd-free as possible, they should start with antix (or Devuan but I'm partial to antix)

You are right about libpam dependancies but I worked around it.
MX runs absolutely fantastic without SystemD and as soon as it creeps back then everything literally goes to hell.
Looks like systemD was written/sponsored maybe by the same people as SELinux which caused me so much trouble 10 years ago, breaking so many processes for no reason.

Also regarding your other statements: I am running Devuan on several of my rackservers and it is fantastic, without this creepy systemD problem I have with MX18. I ran into systemD problems as a debian user and that is why I came to MX. If you read the thread you will see that I already addressed it. I was supposed to use Antix not MX to get rid of the horrid systemduh, and that was my oversight initially. I was invited by an MX developer who saw my systemD trouble at Debian posted. Since he was from MX I asumed I must use MX, but I guess I misunderstood as MX/Antix is almost indistinguishable to someone new to Antix/Mx.reading online they sort of share the same usergroup which really confused me.
This is the last MX server I have to migrate to Devuan, but I need to get it back working first completely as before the systemD infection in order to tend to the migration.

anticapitalista wrote: Sun Sep 22, 2019 2:42 pm cat /var/log/apt/history.log may show us what part of systemd got installed and why.

Also inxi -r (it shows the repos you use)

Here you go,

Code: Select all

$ cat /var/log/apt/history.log |grep -i systemd 
Install: gir1.2-soup-2.4:amd64 (2.56.0-2+deb9u2, automatic), libpam-systemd:amd64 (232-25+deb9u11, automatic), gufw:amd64 (17.04.1-1.1), policykit-1:amd64 (0.105-18+deb9u1, automatic), gir1.2-webkit2-4.0:amd64 (2.24.3-1~mx17+1, automatic), gir1.2-javascriptcoregtk-4.0:amd64 (2.24.3-1~mx17+1, automatic)
Upgrade: kicad-footprints:amd64 (5.1.2-1~mx17+1, 5.1.3-1~mx17+1), libopencv-core-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), mx-packageinstaller-pkglist:amd64 (19.05.07, 19.05.08), grub-themes-mx:amd64 (18.12.02, 19.08.03), librecad-data:amd64 (2.1.2-1, 2.1.2-1+deb9u1), musescore-common:amd64 (2.3.2+dfsg1-1~mx17+1, 2.3.2+dfsg2-6~bpo9+1), libkf5config-data:amd64 (5.28.0-2, 5.28.0-2+deb9u1), linux-headers-4.9.0-9-common:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), firmware-iwlwifi:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libnghttp2-14:amd64 (1.18.1-1, 1.18.1-1+deb9u1), libgles2-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), vlc-plugin-svg:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), grub-efi:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), firmware-realtek:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), mx-usb-unmounter:amd64 (19.04, 19.08.01), libcups2:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libcups2:i386 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-nouveau2:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-nouveau2:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libsox-fmt-all:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-ivtv:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libsox-fmt-ao:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), linux-libc-dev:amd64 (4.20-2~mx17+1, 5.2.9-1~mx17+1), linux-libc-dev:i386 (4.20-2~mx17+1, 5.2.9-1~mx17+1), libldap-2.4-2:amd64 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), libldap-2.4-2:i386 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), vlc-plugin-samba:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libxslt1-dev:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), libllvm7:amd64 (1:7-6~mx17+1, 1:7.0.1-8~deb9u2), libllvm7:i386 (1:7-6~mx17+1, 1:7.0.1-8~deb9u2), libsox-fmt-pulse:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), libopencv-ml-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), libegl1-mesa-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), qemu-system-mips:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), qemu-system-misc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), libegl-mesa0:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), kicad-demos:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), qemu-system-ppc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), vlc-plugin-qt:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), linux-image-4.9.0-9-amd64:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), libsystemd0:amd64 (232-25+deb9u11, 232-25+deb9u12), libsystemd0:i386 (232-25+deb9u11, 232-25+deb9u12), shotwell-common:amd64 (0.30.2-0.1~mx17+1, 0.30.7-0.1~mx17+1), adobe-flash-properties-gtk:amd64 (1:20190709.1-1mx17+1, 1:20190910.1-1mx17+1), grub-common:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), libgd3:amd64 (2.2.4-2+deb9u4, 2.2.4-2+deb9u5), libgd3:i386 (2.2.4-2+deb9u4, 2.2.4-2+deb9u5), libasprintf-dev:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libfaad-dev:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), featherpad:amd64 (1:0.10.0-1~mx17+1, 1:0.11.1-1~mx17+1), libgs9:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libglapi-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libglapi-mesa:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), mesa-common-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), neofetch:amd64 (6.0.0-1~mx17+1, 6.1.0-1~mx17+1), libicu57:amd64 (57.1-6+deb9u2, 57.1-6+deb9u3), libicu57:i386 (57.1-6+deb9u2, 57.1-6+deb9u3), libasprintf0v5:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), vlc-plugin-skins2:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), firmware-amd-graphics:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), vlc-plugin-visualization:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libkf5configcore5:amd64 (5.28.0-2, 5.28.0-2+deb9u1), libsox2:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), libgettextpo0:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), qemu-system-x86:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), firmware-myricom:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), insserv:amd64 (1.14.0-5.4+b1, 1.18.0-2mx17+1), libxatracker2:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), openssh-sftp-server:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), firmware-samsung:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), vlc-plugin-notify:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), libtk-img:amd64 (1:1.4.6+dfsg-1, 1:1.4.6+dfsg-1+deb9u1), grub2-common:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), skypeforlinux:amd64 (8.50.0.38, 8.52.0.138), udev:amd64 (232-25+deb9u11, 232-25+deb9u12), libfribidi-dev:amd64 (0.19.7-1+b1, 0.19.7-1+deb9u1), libegl1-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), cups-server-common:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), mx-tools:amd64 (19.4, 19.9.01), x42-plugins:amd64 (2:20190206-1kxstudio1, 2:20190820-1kxstudio1), libsox-fmt-mp3:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-atheros:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), qemu-user:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), linux-compiler-gcc-6-x86:amd64 (4.20-2~mx17+1, 5.2.9-1~mx17+1), cups-common:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libsox-fmt-alsa:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), brave-browser-beta:amd64 (0.69.119, 0.70.97), libsox-fmt-oss:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), firmware-libertas:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libudev1:amd64 (232-25+deb9u11, 232-25+deb9u12), libudev1:i386 (232-25+deb9u11, 232-25+deb9u12), firmware-netxen:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcaca-dev:amd64 (0.99.beta19-2+b2, 0.99.beta19-2.1~deb9u1), libgettextpo-dev:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libgbm1:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), adobe-flashplugin:amd64 (1:20190709.1-1mx17+1, 1:20190910.1-1mx17+1), libkf5configgui5:amd64 (5.28.0-2, 5.28.0-2+deb9u1), kicad-libraries:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), grub-pc-bin:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), smxi-inxi-antix:amd64 (0.4.16, 0.4.17), libmlt-data:amd64 (6.12.0-1~mx17+1, 6.16.0-3~mx17+1), libdrm-amdgpu1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-amdgpu1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), firmware-intelwimax:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libmbedtls-dev:amd64 (2.4.2-1+deb9u3, 2.16.0-1~mx17+1), gthumb:amd64 (3:3.4.4.1-5, 3:3.4.4.1-5+deb9u1), libva2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), libva2:i386 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), qemu:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), grub-efi-amd64-bin:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), libudev-dev:amd64 (232-25+deb9u11, 232-25+deb9u12), cups-ppdc:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), firmware-linux-nonfree:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcupsmime1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libcaca0:amd64 (0.99.beta19-2+b2, 0.99.beta19-2.1~deb9u1), firmware-brcm80211:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), firmware-intel-sound:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), reportbug:amd64 (7.1.7+deb9u2, 7.1.7+deb9u3), libnss-myhostname:amd64 (232-25+deb9u11, 232-25+deb9u12), sox:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), ssh:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), mx-snapshot:amd64 (19.7.3, 19.9), qemu-utils:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), faad:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), libldap-common:amd64 (2.4.44+dfsg-5+deb9u2, 2.4.44+dfsg-5+deb9u3), libwayland-egl1-mesa:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), gthumb-data:amd64 (3:3.4.4.1-5, 3:3.4.4.1-5+deb9u1), libopencv-flann-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), firmware-qlogic:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libmbedx509-0:amd64 (2.4.2-1+deb9u3, 2.16.0-1~mx17+1), mx-codecs:amd64 (19.4.3, 19.9), vlc-plugin-access-extra:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), librecad:amd64 (2.1.2-1+b1, 2.1.2-1+deb9u1), libpam-systemd:amd64 (232-25+deb9u11, 232-25+deb9u12), qemu-system-sparc:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), clamav:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), libdrm2:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm2:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), linux-kbuild-4.9:amd64 (4.9.168-1+deb9u4, 4.9.189-3), liquidsoap:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), ghostscript:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libopencv-imgproc-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), systemd:amd64 (232-25+deb9u11, 232-25+deb9u12), shotwell:amd64 (0.30.2-0.1~mx17+1, 0.30.7-0.1~mx17+1), linux-image-4.19.0-5-amd64-unsigned:amd64 (4.19.37-2~mx17+2, 4.19.37-5+deb10u2~mx17+1), python3-reportbug:amd64 (7.1.7+deb9u2, 7.1.7+deb9u3), clamav-freshclam:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), lightning:amd64 (2:60.8.0-1~mx17+1, 2:60.8.0-2~mx17+1), libgl1-mesa-dev:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), openssh-server:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), ghostscript-x:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), libgl1-mesa-dri:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgl1-mesa-dri:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), unzip:amd64 (6.0-21+deb9u1, 6.0-21+deb9u2), openssh-client:amd64 (1:7.4p1-10+deb9u6, 1:7.4p1-10+deb9u7), grub-efi-amd64:amd64 (2.02~beta3-5+deb9u1, 2.02~beta3-5+deb9u2), linux-headers-4.9.0-9-amd64:amd64 (4.9.168-1+deb9u4, 4.9.168-1+deb9u5), firmware-misc-nonfree:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libosmesa6:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgs9-common:amd64 (9.26a~dfsg-0+deb9u3, 9.26a~dfsg-0+deb9u5), thunderbird:amd64 (2:60.8.0-1~mx17+1, 2:60.8.0-2~mx17+1), usbutils:amd64 (1:007-4+b1, 1:007-4+deb9u1), mx-packageinstaller:amd64 (19.7.3, 19.9), palemoon:amd64 (28.6.1+repack-1~mx17+1, 28.7.1+repack-1~mx17+1), catfish:amd64 (1.4.7-0.1~mx17+1, 1.4.10-0.1~mx17+1), vlc-plugin-video-splitter:amd64 (3.0.7.1-1mx17+2, 3.0.8-2mx17+2), liquidsoap-plugin-alsa:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), libgl1-mesa-glx:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libgl1-mesa-glx:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libcupsppdc1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-intel1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-intel1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), xfce4-weather-plugin:amd64 (0.9.0really0.8.11-0.1~mx17+1, 0.10.0-0.1~mx17+1), apache2-bin:amd64 (2.4.25-3+deb9u7, 2.4.25-3+deb9u8), libva-x11-2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), firefox:amd64 (68.0.1~mozillabinaries-1mx17+1, 69.0~mozillabinaries-1mx17+1), libva-wayland2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), firmware-bnx2x:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), mx-tweak:amd64 (19.05.01, 19.05.04), libopencv-photo-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), clamav-base:amd64 (0.100.3+dfsg-0+deb9u1, 0.101.4+dfsg-0+deb9u1), kicad:amd64 (5.1.2+dfsg1-1~mx17+1, 5.1.4+dfsg1-1~mx17+1), libdrm-radeon1:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libdrm-radeon1:i386 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), libva-drm2:amd64 (2.3.0-2~mx17+1, 2.4.0-1~mx17+1), qemu-system-arm:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), mesa-vdpau-drivers:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), cups-core-drivers:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), autopoint:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), cups-daemon:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libsdl-image1.2:amd64 (1.2.12-5+deb9u1, 1.2.12-5+deb9u2), libsox-fmt-base:amd64 (14.4.1-5+deb9u1, 14.4.1-5+deb9u2), xsltproc:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), gettext-base:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), gettext:amd64 (0.19.8.1-2, 0.19.8.1-2+deb9u1), libcupsimage2:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), opera-stable:amd64 (62.0.3331.99, 63.0.3368.91), cups:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), musescore-general-soundfont:amd64 (0.1.1-2~mx17+1, 0.1.7-2~mx17+1), firmware-linux:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libcupscgi1:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), cups-client:amd64 (2.2.1-8+deb9u3, 2.2.1-8+deb9u4), libdrm-dev:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1), virtualbox-6.0:amd64 (6.0.10-132072~Debian~stretch, 6.0.12-133076~Debian~stretch), kicad-templates:amd64 (5.1.0-1~mx17+1, 5.1.3-1~mx17+1), libopencv-video-dev:amd64 (2.4.9.1+dfsg1-2, 3.2.0+dfsg-3mx17+1), linux-source-4.19:amd64 (4.19.37-2~mx17+1, 4.19.67-2~mx17+1), firmware-bnx2:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), qemu-system-common:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u1, 2.8.0~cvs20161113-1+deb9u2), liquidsoap-plugin-gstreamer:amd64 (1.1.1-7.2, 1.1.1-7.2+deb9u1), firmware-ipw2x00:amd64 (20190502-1~mx17+1, 20190717-1~mx17+1), libfribidi0:amd64 (0.19.7-1+b1, 0.19.7-1+deb9u1), qemu-system:amd64 (1:2.8+dfsg-6+deb9u7, 1:2.8+dfsg-6+deb9u8), mesa-va-drivers:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libxslt1.1:amd64 (1.1.29-2.1, 1.1.29-2.1+deb9u1), libxslt1.1:i386 (1.1.29-2.1, 1.1.29-2.1+deb9u1), base-files:amd64 (9.9+deb9u9, 9.9+deb9u11), tzdata:amd64 (2019a-0+deb9u1, 2019b-0+deb9u1), libglx-mesa0:amd64 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libglx-mesa0:i386 (18.3.2-1~mx17+1, 18.3.6-2~mx17+1), libdrm-common:amd64 (2.4.95-1~mx17+1, 2.4.97-1~mx17+1)
Commandline: apt remove systemd
Remove: libpam-systemd:amd64 (232-25+deb9u12), systemd:amd64 (232-25+deb9u12), gufw:amd64 (17.04.1-1.1), policykit-1:amd64 (0.105-18+deb9u1)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Install: rtkit:amd64 (0.11-4+deb9u1), paprefs:amd64 (0.9.10-2+b1), pulseaudio-module-zeroconf:amd64 (10.0-1+deb9u1, automatic), libpam-systemd:amd64 (232-25+deb9u12, automatic), policykit-1:amd64 (0.105-18+deb9u1, automatic), pulseaudio-module-gconf:amd64 (10.0-1+deb9u1, automatic), libgconfmm-2.6-1v5:amd64 (2.28.3-1, automatic)
Commandline: apt remove libpam-systemd
Remove: libpam-systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove --purge --auto-remove systemd
Purge: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Install: systemd-sysv:amd64 (232-25+deb9u12, automatic)
Remove: systemd-sysv:amd64 (232-25+deb9u12)
Commandline: apt remove systemd
Remove: systemd:amd64 (232-25+deb9u12)
Commandline: apt remove --purge --auto-remove systemd
Purge: systemd:amd64 (232-25+deb9u12)

Furthermore the log shows my attempts getting rid of systemDuh which finally was successful.

# apt remove systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.

Now most of the cron issues, apple mouse issues, sound issues, cdemu issues, and what not also disappeared with the good riddance of systemD.
It did somehow mess with usb, as suddenly I cannot use some of my USB devices after systemD appeared.

I will have to reinstall the entire usb subsystem.

Posted: **Sun Sep 22, 2019 4:24 pm**

I am very curious why most of us are running quite well without removing anything. Everything is just working for me both with MX 18.3 and MX 19 Beta 2.1. I have installed a lot of additional software as well from the Main and Test repos.

Posted: **Sun Sep 22, 2019 4:25 pm**

Final remaining question (*See my original post*)
Question2) Anyone has a way to ultimately block a package .... such as systemDuh to be banned from installing though apt/dpkg

Posted: **Sun Sep 22, 2019 4:34 pm**

richb wrote: Sun Sep 22, 2019 4:24 pm I am very curious why most of us are running quite well without removing anything. Everything is just working for me both with MX 18.3 and MX 19 Beat 2.1

MX18 was one of the greatest Distros I ever use if systemD is removed. It absolutely worked spectacular for a couple of months running a myriad of tricky applications.

It is just this unwarranted installation of systemD that keeps happening not listed in the apt " to be installed" list which is curiously inadequate.

I got incredible latency improvements using MX18 over AVLinux for example, where systemD eventually also bit me and I had to search then already for a systemD free distro.

Except for systemD issue mentioned, MX18 was an absolute pleasure.

We dont get the same results because we diont use the same applications.
I am not saying that you are a mouse-pusher dont get me wrong, but my wife who is a mouse-pusher and knows nothing about programming or sysadmin happily use systemD debian 24/7 in her dayly work.
For me it just doesnt work. The deeper you delve into a systemD system the worse your day get. If you dont jump the mouse-push ship you will never encounter the SystemD shark in the water. That is my point why there are difference in experience.

99.9% of users are mouse-pushers and they wont even e.g. ever touch cron, setup a large virtual cdemu library, setup complex jack routes use extensive IO etc.
Therefore 99.9% of users will jump the very real systemD vicious shark.

Posted: **Sun Sep 22, 2019 4:45 pm**

zimbodel wrote: Sun Sep 22, 2019 4:25 pm Question2) Anyone has a way to ultimately block a package .... such as systemDuh to be banned from installing though apt/dpkg

AntiX:
/etc/apt/preferences.d/00systemd

Code: Select all

Package: *systemd*
Pin: origin ""
Pin-Priority: -1

Links
How to Replace Systemd With SysV Init On Debian Linux
https://linuxconfig.org/how-to-replace- ... bian-linux

Migrating from Debian to Devuan
https://mn3m.info/posts/migrating-from- ... to-devuan/

Posted: **Sun Sep 22, 2019 4:47 pm**

OK. So you are doing things most users do not do. That answers my original question.

I am very curious why most of us are running quite well without removing anything. Everything is just working for me both with MX 18.3 and MX 19 Beat 2.1

I know you like MX as you have stated so. But as was said earlier by anticapitalista, for a hands on user such as you, antiX is really a better choice. You can start with the base version and build it to whatever you want. And no vestiges of systemd.

Posted: **Sun Sep 22, 2019 4:58 pm**

richb wrote: Sun Sep 22, 2019 4:47 pm You can start with the base version and build it to whatever you want. And no vestiges of systemd.

Very true. It was a good learning with the links I posted above, but AntiX does and tailored with same look and feel as MX.

Posted: **Sun Sep 22, 2019 5:04 pm**

rasat wrote: Sun Sep 22, 2019 4:45 pm
zimbodel wrote: Sun Sep 22, 2019 4:25 pm Question2) Anyone has a way to ultimately block a package .... such as systemDuh to be banned from installing though apt/dpkg
AntiX:
/etc/apt/preferences.d/00systemd
Code: Select all
Package: *systemd*
Pin: origin ""
Pin-Priority: -1
Links
How to Replace Systemd With SysV Init On Debian Linux
https://linuxconfig.org/how-to-replace- ... bian-linux

Migrating from Debian to Devuan
https://mn3m.info/posts/migrating-from- ... to-devuan/

Great point! Also, add nosystemd to the antix.list sources repo so it reads

deb http://repo.antixlinux.com/stretch stretch main nosystemd nonfree

Posted: **Sun Sep 22, 2019 5:18 pm**

zimbodel wrote: Sun Sep 22, 2019 4:34 pm 99.9% of users are mouse-pushers and they wont even e.g. ever touch cron, setup a large virtual cdemu library, setup complex jack routes use extensive IO etc.
Therefore 99.9% of users will jump the very real systemD vicious shark.

IMHO this sort of statement is unwarranted or needed on these forums, not the systemd piece, but the down talking of any type of user is ignorant and rude.

Posted: **Sun Sep 22, 2019 5:23 pm**

Sounds like music to my ears with Antix.

If I may ask, is there maybe an easy way to migrate from MX18 to Antix., they do seem very similar.
I can play around with repos on a clone of the existing disk and see for myself, but if you do have a definite answer it will be appreciated.

As MX works great for me if systemD doesnt harass me, and especially on this server that does complex jack sound with hordes of IO, MX worked absolutely stellar with MX18 with 2.6ms latency and no xruns. Never could get that with AVLinux or Debian with RT kernel.
Therefore if there is an easy way to migrate to Antix, it will be a better route than to go to Devuan, which is what my current plan is.
I will really appreciate that as it will prevent me from reinstalling absolutely all applications converting to devuan and can save me literally a months work on and off and might even preserve the latency I get.

anticapitalista wrote: Sun Sep 22, 2019 5:04 pm
zimbodel wrote: Sun Sep 22, 2019 4:25 pm Question2) Anyone has a way to ultimately block a package .... such as systemDuh to be banned from installing though apt/dpkg
AntiX:

Great point! Also, add nosystemd to the antix.list sources repo so it reads

deb http://repo.antixlinux.com/stretch stretch main nosystemd nonfree

Posted: **Sun Sep 22, 2019 5:31 pm**

zimbodel wrote: Sun Sep 22, 2019 5:23 pm If I may ask, is there maybe an easy way to migrate from MX18 to Antix., they do seem very similar.

Take a look in MX Respins List:
https://forum.mxlinux.org/viewtopic.php?f=100&t=48617

Posted: **Sun Sep 22, 2019 5:32 pm**

I tried the pin thing about a week ago and it did not catch systemD.
I sure must have misconfigured it if it really works, as granted I didnt understand how the pinning actually works, as I should understand it.
I had the same failure as many other users had where the package pinned just appeared again.

I will try it again, if I cannot Migrate the system as is to Antix.
It will be valuable to at least run this mission crytical server with MX18 without systemD ever darkening my doorstep if I can get pinning to work which will give me time if I have to do a hard migrate to antix or devuan. As I mention now, I have to use cron to notify me if it installed.

UPDATE: I created a partition on one of my machines I installed MX18 and will test the pinning there till it works.
MX works great if I can ban systemD permanently. I dont want to use any application that is systemD dependent. They are usually gnome apps so I dont bother with that anyway. At the moment I have no systemD dependencies and will see if I can get pinning to work on the test partition.
If I get trouble I will post it in a new thread. Better not to do any apt/dpkg commands on the existing system untill I understand pinning properly in my test partition.

Thanks a lot.

rasat wrote: Sun Sep 22, 2019 4:45 pm
zimbodel wrote: Sun Sep 22, 2019 4:25 pm Question2) Anyone has a way to ultimately block a package .... such as systemDuh to be banned from installing though apt/dpkg
AntiX:
/etc/apt/preferences.d/00systemd
Code: Select all
Package: *systemd*
Pin: origin ""
Pin-Priority: -1
Links
How to Replace Systemd With SysV Init On Debian Linux
https://linuxconfig.org/how-to-replace- ... bian-linux

Migrating from Debian to Devuan
https://mn3m.info/posts/migrating-from- ... to-devuan/

Posted: **Sun Sep 22, 2019 5:39 pm**

richb, since you are a moderator
OT question:
What does MX prefer, top posting or bottom posting when quoting.
I sort of mix and match and dont know what is preferred here.

richb wrote: Sun Sep 22, 2019 4:47 pm

Posted: **Mon Sep 23, 2019 4:09 am**

It is easier to read a top quote since you can read what was said earlier before your reply to it.

Posted: **Mon Sep 23, 2019 4:28 am**

As Eadwine indicated, top quoting helps to understand the context of the reply.

Posted: **Mon Sep 23, 2019 6:19 am**

Consider two examples:

Because it makes your replies harder to read and understand.

Why is top-quoting bad?

vesus

Why is top-quoting bad?

Because it makes your replies harder to read and understand.

In the first example it looks as though you were answering a question before it was asked. Which is OK for those with super-powers, I suppose, but it disrupts the normal chain of a typical conversation, unless you're used to reading from the bottom of a page upward.

Posted: **Tue Sep 24, 2019 2:08 am**

I prefer it too, but I get mostly wanings on most usergroups if I do that.

Eadwine Rose wrote: Mon Sep 23, 2019 4:09 am It is easier to read a top quote since you can read what was said earlier before your reply to it.

Posted: **Tue Sep 24, 2019 2:20 am**

Thanks to all helping out with this thread.

I could get the server to work normal again and wont install anything new until I have tested that pinning works so that systemD doesnt create the usual trouble again. It really causes a lot of trouble here stepping on things it shouldnt.

I appreciate all the responses I received, from mild to inflamatory, it all helped and you are all reasonable people and I appreciate the effort.

At least I have a way now to make sure the trouble doesnt happen again.
The best will be Antix for me in future as was pointed out and will do so once MX18 runs out of gas due to ageing libraries.
At that point I will move over to Antix.

I still stand by my comment: MX18 without systemD is probably the best distro I ever used.
The only other great is the very old Fedora 7 which is enormous and it still runs on one of my servers doing indispensable numerical work since it was installed way back then.

Thanks

Posted: **Tue Sep 24, 2019 3:38 am**

zimbodel wrote: Tue Sep 24, 2019 2:08 am I prefer it too, but I get mostly wanings on most usergroups if I do that.

Eadwine Rose wrote: Mon Sep 23, 2019 4:09 am It is easier to read a top quote since you can read what was said earlier before your reply to it.

Not from here, so please topquote, thanks :)

Posted: **Wed Sep 25, 2019 11:18 am**

Just noticed this on another forum
The D in Systemd is for Directories: Poettering says his creation will phone /home in future.
Systemd-managed home folders are secure, portable, extensible... albeit with broken SSH login

https://www.theregister.co.uk/2019/09/2 ... rectories/

Posted: **Sun Sep 29, 2019 3:44 am**

PondLife wrote: Wed Sep 25, 2019 11:18 am Just noticed this on another forum
The D in Systemd is for Directories: Poettering says his creation will phone /home in future.
Systemd-managed home folders are secure, portable, extensible... albeit with broken SSH login

https://www.theregister.co.uk/2019/09/2 ... rectories/

O Lord Please Please help us if this is true!!!!

How genius.... home directories without ssh ... === the end of Unix&Linux.
You cant make this bork up!!! and the gift just keeps giving and then we have to put up with the piling damages.

Can't peuterhead keep the in my opinion, grubby junk codey hands off systems that actually work.
Potatohead should rather call it borkSys and get done with it.
Its in my opinion the kind of junk you ship to a fascist enemy to bork it up good by letting it do its miraculous im(de)provement of everything.
The crap invention in my opinion, caused me a looooooot of damage.

systemDoitall hey, have some world domination. xxxxx, seemingly now lives on..in code.
What a stupid sh!@#$$#%^& idea. How un-Unix,. how 1/(LinusTorvalds).

"http://www.softpanorama.org/Commercial_ ... temd.shtml"

I used to read the BOFH chronicles in early 2000s at the register.
Register should let BOFH loose on him.....will be hilarious.

Posted: **Sun Sep 29, 2019 3:48 am**

Finally the system is restored to working condition before the systemD induced damage.
I sorted a few things that didnt work today and now it is spnking new.

Everything works again.
It was a month it took to sort out all the damage.
cdemu vhba modules and way more now loads again after systemd completely removed it etc for absolutely no reason,
(although I have to use an old kernel new kernel fails)

USB has been reinstalled and now works with all my devices after systemD borked it good although I could never find out how it was done. It died with arrival of SystemD.
Jack/alsa works perfect again doing all the complex routing that just stopped with the arrival of systemD, my production keyboards now have their maps back after usb was borked.

MX18 without systemD is just downright awesome. I have never had such a great system and I cannot state it enough.
I will now attempt to hard pin systemD to be banned from being installed\ as it always creeps past never mind how well you take care.

Once pinning works it will be absolutely unparalleled system.
As already mentioned for some reason I get ultra low latencys with MX all my virtual machines has flawless low latency sound and device handling/passthrough and the list goes on. Professional production video runs flawless where I usually had huge problems with other distros.

MX 18 sans SytemDonkey rocks as utterly good as systemDuh sucks.

Thanks all for helping it is really appreciated -- warts and all,.

Posted: **Sun Sep 29, 2019 5:03 am**

Calm down. Read the article beyond its title and make a rational attempt to understand what is going on, instead of hurling insults and comparing systemd with World War II.

Posted: **Sun Sep 29, 2019 5:05 am**

Thread locked pending review.

Posted: **Sun Sep 29, 2019 7:32 am**

I have unlocked the thread and edited out any references to an earlier era. Inflammatory comments do not belong on the Forum.

Posted: **Sun Sep 29, 2019 9:39 am**

richb wrote: Sun Sep 29, 2019 7:32 am I have unlocked the thread and edited out any references to an earlier era. Inflammatory comments do not belong on the Forum.

Title should probably be changed to "User shoots himself in the foot, blames systemd"

Posted: **Sun Sep 29, 2019 9:54 am**

Or 'in one era and out the other'. Or was that Richb's typo, era rather than error?

Posted: **Sun Sep 29, 2019 10:00 am**

The content deleted had an era in it. So his wording is correct.

Posted: **Sun Sep 29, 2019 10:04 am**

Adrian wrote: Sun Sep 29, 2019 9:39 am Title should probably be changed to "User shoots himself in the foot, blames systemd"

+1, except user blames systemD

Spelling

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple... The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd.

From https://www.freedesktop.org/wiki/Software/systemd/

Posted: **Sun Sep 29, 2019 11:09 am**

Partially correct, sunrat! However Poettering's systemd was apparently a play on System D which is a way of responding to challenges that requires fast thinking, adaptability and ingenuity.

Posted: **Sun Sep 29, 2019 2:06 pm**

zimbodel wrote: Sun Sep 22, 2019 3:41 pm To Head_on_a_Stick:
Nope I dont think I am the one who is confused here:
Code: Select all
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=c7eca528-9d40-4071-ab79-c273b78e0185 ro quiet
$ ls -l /sbin/init
-rwxr-xr-x 1 root root 44856 Apr 23 16:21 /sbin/init

Well APT was quite clear: you were booted with systemd running as PID1 when you produced the output in the OP. Things have obviously changed since then.

This is particularly amusing to me:

zimbodel wrote: Tue Sep 17, 2019 11:54 pm It refused to uninstall with
Code: Select all
apt uninstall systemd
but it was removed good with
Code: Select all
apt remove  --purge --auto-remove systemd
There should not be a difference, where the former throws an error and the latter just does it, but hey its systemd.

There is no such option as uninstall for the apt command... Who's confused now, eh?

And your second command breaks the desktop:

Code: Select all

empty@mx:~/Desktop
$ apt remove --simulate --purge --auto-remove systemd
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  apt-notifier* apt-transport-https* colord* fskbsetting* gazelle-installer-data-mx*
  gir1.2-javascriptcoregtk-4.0* gir1.2-polkit-1.0* gir1.2-soup-2.4* gir1.2-webkit2-4.0*
  grub-efi-amd64-bin* grub-efi-ia32-bin* gufw* gvfs* gvfs-backends* gvfs-daemons* gvfs-fuse*
  gvfs-libs* libatasmart4* libcolorhug2* libept1.5.0* libgdata-common* libgdata22* libgoa-1.0-0b*
  libgoa-1.0-common* libjansson4* libndp0* libnl-3-200* libnl-genl-3-200* libnm-glib-vpn1*
  libnm-glib4* libnm-gtk0* libnm-util2* libnm0* libnma0* liboauth0* libpam-systemd*
  libpolkit-agent-1-0* libpolkit-backend-1-0* libteamdctl0* libudisks2-0* mx-apps* mx-installer*
  mx-repo-list* mx-repo-manager* network-manager* network-manager-gnome*
  network-manager-openconnect* network-manager-openvpn* network-manager-openvpn-gnome*
  network-manager-pptp* network-manager-vpnc* policykit-1* policykit-1-gnome* pptp-linux*
  python-configobj* python-dbus* python-lxml* python-pyqt5* python-sip* synaptic* systemd*
  udisks2* unattended-upgrades* wpasupplicant*
0 upgraded, 0 newly installed, 64 to remove and 0 not upgraded.

It removes NetworkManager, gvfs (and udisks2), wpasupplicant and policykit-1. The user would then be unable to connect wirelessly, automount any devices or shutdown or restart from the GUI buttons.

Posted: **Mon Sep 30, 2019 12:25 am**

To head on a stick..

# apt remove systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd' is not installed, so not removed
The following packages were automatically installed and are no longer required:
linux-headers-4.19.0-0.bpo.6-amd64 linux-headers-4.19.0-0.bpo.6-common
linux-headers-4.9.0-11-amd64 linux-headers-4.9.0-11-common
linux-image-4.19.0-0.bpo.6-amd64 linux-image-4.9.0-11-amd64 linux-kbuild-4.9
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 109 not upgraded.

Hello? do you see systemd installed here now ???
So how did I manage to uninstall it and run MX without it. ?
Clearly you dont know how to do it and believe it is impossible.
Sure it uninstalled all that AND systemD and then I just took note of what was uninstalled and reinstalled only those that doesnt have systemD as a dependency.
Why is it so hard for you to figure such a simple procedure out on your own? apparently you are still very confused or ?

To other comments:
I am glad systemD works for you.
MX18 works great now with systemD removed. I wish you could experience the difference then you would understand where I come from.
On my system and my experience what is going on, systemD is squarely at fault causing all the trouble.
If you want to sweep it under the rug, do so, but I am not going to tow the line and bend the truth to do so.

I tow the truth as far as I possibly can.
Try and smoke that for a change.

Anyway as you maybe did not notice. The problem is solved.
No reason for us to harp on sour grapes.

This thread is closed solved.
Move on.

Thanks

Posted: **Mon Sep 30, 2019 12:51 am**

No sour grapes, in fact I'm happy you have solved your issues. You must realise that an issue for you may be unique to you because of some configuration you changed or a combination of installed software that does not play well together. You must also realise that most people who use systemd do not have your issues so ranting that it is the root of evil does nothing to boost your credibility, nor does spelling it incorrectly.
It's refreshing though that you are one of the rare people who rant against systemd for practical reasons rather than philosophical ones.

Posted: **Mon Sep 30, 2019 12:55 am**

zimbodel wrote: Mon Sep 30, 2019 12:25 am
...The problem is solved.....

For now.

That is because you have just manually weeded out all the systemd-related packages, as is your right and your choice.

...MX18 without systemD is just downright awesome. I have never had such a great system and I cannot state it enough.
I will now attempt to hard pin systemD to be banned from being installed\ as it always creeps past never mind how well you take care.

Once pinning works it will be absolutely unparalleled system....

I'm happy you are happy with MX running without any systemd-related packages on it. I hope you are able to fully banish systemd-related packages with your hard pinning.

But please do not issue another complaint post if you find that despite your efforts, you still have to carry out another systemd-removal exercise in future when more updates drop.

MX was made to boot into sysvinit by default, but not to be completely free of systemd-related packages by default. So you may have to expend the effort every once in a while to clear your garden. That is the potential consequence if you want to run MX your way.

Posted: **Mon Sep 30, 2019 1:09 am**

asqwerth wrote: Mon Sep 30, 2019 12:55 am
But please do not issue another complaint post if you find that despite your efforts, you still have to carry out another systemd-removal exercise in future when more updates drop.

I will post as much and what I want thank you very much, as long as I stay within forum rules.
That said, it is non of your business what I should or should not post.
I comply to the forum rules, thats it.

The thread is closed and solved unless you didnt notice and I thank again those users who made a positive contribution.
Move on.

Posted: **Mon Sep 30, 2019 1:11 am**

asqwerth wrote: Mon Sep 30, 2019 12:55 am But please do not issue another complaint post if you find that despite your efforts, you still have to carry out another systemd-removal exercise in future when more updates drop.

MX was made to boot into sysvinit by default, but not to be completely free of systemd-related packages by default. So you may have to expend the effort every once in a while to clear your garden. That is the potential consequence if you want to run MX your way.

And if you need to post another help request when (not if) your systems break again please do so in the MX Modified forum as your MX installations have clearly been modified from the original setup. Thanks.

Posted: **Mon Sep 30, 2019 1:15 am**

sunrat wrote: Mon Sep 30, 2019 12:51 am
It's refreshing though that you are one of the rare people who rant against systemd for practical reasons rather than philosophical ones.

Believe me, I have philosophically no problem using systemD if it actually worked for me I would adopt it.
I honestly encountered so many problems that resolved with systemD removed that it became a threat to me running my rackservers.
That is just what it is and what I have to deal with.

Posted: **Mon Sep 30, 2019 1:29 am**

JayM wrote: Mon Sep 30, 2019 1:11 am And if you need to post another help request when (not if) your systems break again please do so in the MX Modified forum as your MX installations have clearly been modified from the original setup. Thanks.

You are going in circles arn't you getting tired?
So to break this psychological loop you are in.
As I already clearly stated in the thread.
1) System ran spectacular, best I ever had for 6 months till systemD crept in again . So dont blame me for having turned MX into Antix. Rant at Antix then not me if you dont like that it works better for me.
2) SystemD will now be pinned as we discussed and I will alter apt with a wrapper to always grep for systemD so it never happens again.
3) Once MX18 gets too old and I am forced to upgrade, I will move to Antix, because that is actually what I made out of MX18 it seems. Until then, I will ask any question I want and post it where I feel it is relevant. Its none of your business as long as it complies to forum rules.
4) The Antix maintainer indicated that he will hard pin systemD, so the few users with positive contributions did help achieve something good.
5) I refuse to run an application that is completely sytemD dependent. I always find a substitute.

Thats it, MX18 runs like greased lightning again with 2.8ms latency and no xruns - freekin enormous.
I take my hat off to the MX developers.

At any rate, you are good people, but I urge you not to try to continue the senseless rants.
The thread is closed, Problem solved
Move On.

Posted: **Mon Sep 30, 2019 1:39 am**

I made a polite request saying "please" and "thanks". There's no need for the snotty responses.

Posted: **Mon Sep 30, 2019 1:44 am**

JayM wrote: Mon Sep 30, 2019 1:39 am I made a polite request saying "please" and "thanks". There's no need for the snotty responses.

Lets agree to disagree,

Snotty, no. Accurate summary of the scope of the thread yes.
Thanking the maintainers and complimenting MX is a snotty remark ??

Break your psychological circle please
Lets Move on.
Thank you

Posted: **Mon Sep 30, 2019 1:46 am**

The thread is closed, Problem solved
Move On.

I don't think it works this way. You open a discussion you have to be open to hear what people think about it, you cannot shut them up when you don't like what they tell you. Especially if you kick and scream about something you should expect that people who disagree will respond to your posts.

Also, you claim you follow the forum rules, but you are a bit rude and I see you already have a warning. I think we are on 3 strikes = you are out, you are probably half-way towards the 2nd strike, so now it would probably be a good idea to tone the level of your rhetoric down and stop telling people who respond here what is their business or not.

Ultimately, f you hate systemd touching your system I would actually urge you to use another OS, MX is probably not for you, antiX will probably be a better choice, although I hate it to point you their direction, they've done only nice things for us...

Posted: **Mon Sep 30, 2019 1:56 am**

Adrian wrote: Mon Sep 30, 2019 1:46 am
The thread is closed, Problem solved
Move On.
Ultimately, f you hate systemd touching your system I would actually urge to use another OS, MX is probably not for you, antiX will probably be a better choice, although I hate it to point you their direction, they've done only nice things for us...

1) The entire Antix option has been discussed in detail in this thread. I even explained how I was invited to MX and why that was relevant. You seemingly missed that.
2) I donot HATE systemD (althought that is not what you imply), but it is catastrophic what it actually does to my system. I cannot just ignore the facts because some systemD attaboy Jedi waves fingers at me to adopt it regardless. I will use systemD if it works for me which it clearly doesnt as I verified empirically. If systemD worked I would be the first to use it. No hate, just factual experience that negates its use
As I said about five times during the life of this topic/thread, I will move to Antix once this systemD pinned MX18 becomes too old.
Regardless MX18 without systemD is the best Distro I ever had.-- no contest.

We already discussed all this.
Please take the time and read the thread before you repost old issues that has been solved and addressed.

Posted: **Mon Sep 30, 2019 2:06 am**

zimbodel wrote: Mon Sep 30, 2019 1:56 am 2) I donot HATE systemD (althought that is not what you imply), but it is catastrophic what it actually does to my system.

The only catastrophic thing happened when you mucked up with your system trying to remove packages. What does systemd do to your system if you leave in on? I'm interested to know because hey, I run MX on a multitude of systems and never had one issue... But again the use cases might be different, so I am interested to know what danger systemd poses on systems booted up with sysvinit. I'm open to learn new things.

Posted: **Mon Sep 30, 2019 2:09 am**

Adrian wrote: Mon Sep 30, 2019 2:06 am
zimbodel wrote: Mon Sep 30, 2019 1:56 am 2) I donot HATE systemD (althought that is not what you imply), but it is catastrophic what it actually does to my system.
The only catastrophic thing happened when you mucked up with your system trying to remove packages. What does systemd do to your system if you leave in on? I'm interested to know because hey, I run MX on a multitude of systems and never had one issue... But again the use cases might be different, so I am interested to know what danger systemd poses on systems booted up with sysvinit. I'm open to learn new things.

No, the catastrophic thing happened when systemD was installed as a dependency after I ran MX systemD free for 6 months, you are twisting my words.
Read the thread, I listed a couple, but there are hordes.
For starters sysvinit cron jobs dont run, rc.local dont run anymore (crucial to me) etc etc etc.. serious problems and that is just the tip of the iceberg.
alsa/jack gets borked solid until systemD is removed again and the list goes on.
I am really not going to repeat the thread to you.

It all resolves when I remove systemD for some reason.

I kindly ask that we move on.
The problem has been resolved with the help of positive contributions.
thanks

Posted: **Mon Sep 30, 2019 2:13 am**

zimbodel wrote: Mon Sep 30, 2019 1:44 am
JayM wrote: Mon Sep 30, 2019 1:39 am I made a polite request saying "please" and "thanks". There's no need for the snotty responses.

You are flat rude to people that are helping you and helping others. (interestingly, I don't see you trying to help anyone, funny, how this goes...) You got all good suggestions, those that triggered you are very good suggestions, starting with please.... but you are acting like spoiled brat. It is going to be my way.... Since you are running MX differently that it is designed, you shouldn't be keep ranting for months when thinks breaks. It is your choice, to run it differently. But to me, you are coming across like: "I will rant, it is my right, until you guys change MX the way I want it!!!"

I hope good people here would just start ignoring you and stop helping you.

zimbodel wrote: Mon Sep 30, 2019 1:09 am
asqwerth wrote: Mon Sep 30, 2019 12:55 am But please do not issue another complaint post if you find that despite your efforts, you still have to carry out another systemd-removal exercise in future when more updates drop.
...I will post as much and what I want thank you very much, as long as I stay within forum rules.
That said, it is non of your business what I should or should not post.

zimbodel wrote: Mon Sep 30, 2019 1:29 am
...Until then, I will ask any question I want and post it where I feel it is relevant. Its none of your business as long as it complies to forum rules.

...At any rate, you are good people, but I urge you not to try to continue the senseless rants.
Problem solved

Well and you are not good people and you are the one making rants starting early this year. And in many of your posts, there are some kind of insults, snotty responses... Frankly your posts are becoming tiresome.

Posted: **Mon Sep 30, 2019 2:15 am**

zimbodel wrote: Mon Sep 30, 2019 2:09 am For starters sysvinit cron jobs dont run, rc.local dont run anymore etc etc etc.. serious problems.

Never had a problems with those. Cron jobs work just fine, rc.local runs just fine on my systems. You probably mucked up something else but that's just a guess.
Can you replicate the problem, show us how cron jobs/rc.local don't work on a freshly installed and updated MX?

Posted: **Mon Sep 30, 2019 2:23 am**

@zimbodel
Maybe windows may solve your snake troubles. It is systemd free.

Posted: **Mon Sep 30, 2019 2:27 am**

I would suggest something more robust like FreeBSD which is a true Unix and uses BSD Init, or perhaps Gentoo Linux minimal installation which is available with a choice of several init systems including SysV, rather than modifying and using any consumer-oriented desktop/laptop distro, whether MX, antiX or Devuan, on mission-critical servers. (I would actually choose something like Red Hat Enterprise, SuSE Enterprise or possibly CentOS if I were an IT manager, but these are all systemd distros which zimbodel objects to. In any event I certainly wouldn't run a desktop Linux distro on my servers. I also wouldn't allow updates on my production servers without first installing and testing them on an identical non-production server reserved for that purpose.)

Posted: **Mon Sep 30, 2019 2:32 am**

KoO wrote: Mon Sep 30, 2019 2:23 am @zimbodel
Maybe windows may solve your snake troubles.

+1 !!!
Windows indeed are systemd free

(for the record, the reason I come to MX is because it is not running on systemd. So, I too am avoiding systemd.
But I use MX as developers designed it. And I'm running antiX as developers designed it)

Posted: **Mon Sep 30, 2019 2:35 am**

Buck Fankers wrote: Mon Sep 30, 2019 2:32 am (for the record, the reason I come to MX is because it is not running on systemd. So, I too am avoiding systemd.
But I use MX as developers designed it. And I'm running antiX as developers designed it)

Thanks, and properly reporting a problem might actually get it solved, instead of breaking your system and coming here kicking and screaming and telling developers to read 7 pages of rambling forum posts.

Posted: **Mon Sep 30, 2019 2:38 am**

You can all continue your systemD party and rant and rave and insult as much as you want.
The thread has been solved if you look at the topic.

I am not taking part in your self-serving pie fight.

Enjoy
Cheers kids.

Posted: **Mon Sep 30, 2019 2:52 am**

zimbodel wrote: Mon Sep 30, 2019 2:38 am You can all continue your systemD party and rant and rave and insult as much as you want.
The thread has been solved if you look at the topic.

I am not taking part in your pie fight.

Enjoy
Cheers kids.

Please ignore the kids, I would still like a clear bug report showing how to replicate the rc.local problem (let's take one problem at a time -- that's the first rule of bug reporting "nothing works" won't lead anywhere)

So here's how to report a problem:
1. let us know what version you use (MX18.3 for example, fully upgraded from regular repos)
2. let us know the version of the relevant package. In case of rc.local I guess the relevant packages would be sysvinit-core sysv-rc-conf, throw in systemd version but I doubt that's relevant)
3. tell us what line you added in /etc/rc.local, preferable something we can try too.
4. how exactly it fails, do you have a log or something that shows that?
5. can you add something else in /etc/rc.local that makes it work?

Then if we have enough information and if we can replicate the problem we might be able to zoom in and fix it, the rest is irrelevant banter...

Posted: **Mon Sep 30, 2019 2:59 am**

Lets move on. MX runs well as non-systemd. How zimbodel did is a bit more work instead of using antix repo after removing all systemd based packages. Here is a sample respin.
https://forum.mxlinux.org/viewtopic.php?f=100&t=50981

@zimbodel, I suggest you make a snapshot, one respin and post in a new thread. It will be listed in MX Desktop Respins (list).
https://forum.mxlinux.org/viewtopic.php?f=100&t=48617

Posted: **Mon Sep 30, 2019 3:06 am**

Adrian wrote: Mon Sep 30, 2019 2:52 am
Please ignore the kids, I would still like a clear bug report showing how to replicate the rc.local problem (let's take one problem at a time -- that's the first rule of bug reporting "nothing works" won't lead anywhere)

So here's how to report a problem:
1. let us know what version you use (MX18.3 for example, fully upgraded from regular repos)
2. let us know the version of the relevant package. In case of rc.local I guess the relevant packages would be sysvinit-core sysv-rc-conf, throw in systemd version but I doubt that's relevant)
3. tell us what line you added in /etc/rc.local, preferable something we can try too.
4. how exactly it fails, do you have a log or something that shows that?
5. can you add something else in /etc/rc.local that makes it work?

Then if we have enough information and if we can replicate the problem we might be able to zoom in and fix it, the rest is irrelevant banter...

Give me the address to the bug tracker and I can deal with it there when I have time.
Although by doing so, I will be helping exactly those systemD attaboys who shout loudest right now, with systemD problems they will encounter in future.
See the conflict of interest ?
Just saying.
I will have to install MX on another partition and do it there.
It will be a cold day in hell before I install systemD on this server again.
It works perfectly now.

Thats all. I wont post in this thread anymore.
Thanks, bye.

Posted: **Mon Sep 30, 2019 3:17 am**

The MX bug tracker's link is listed at the top right of the forum.

Posted: **Mon Sep 30, 2019 3:29 am**

Bug tracker link is at the top of the Forum

Posted: **Mon Sep 30, 2019 9:18 am**

This thread has run its course and become repetitive. The OP has marked it solved. Therefor I am locking it.

MX Linux Forum

[solved] @#$%^*&! SystemD .. the snake strikes again

[solved] @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again

Re: [solved] @#$%^*&! SystemD .. the snake strikes again