My question is not necessarily about EOS, but about sytemd in general. There are distributions (such as MX Linux) where systemd is not enabled by default because sysvinit is used as an example. What could be the reasons why, after enabling systemd, the system does not start normally but gets into the emergency shell? My other question, and by that I do not want to open a debate, is whether sysvinite has distinct advantages over systemd?
arch uses systemd per default https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
And what do you do to enable systemd?
As it is used per default and in relation to that EndeavourOS using systemd services/timers/targets to run.
1 Like
The kernel parameter must be: init = / lib / systemd / systemd Otherwise, syvinit works fine. At the time, there was a lot of debate in the community, especially in Debian, about the mandatory introduction of systemd. For some reason, MX Linux sticks to sysvinit by default, but it doesn’t rule out using systemd, you just need to enable it separately. Otherwise, systemd is probably more advanced than syvinit due to the automatic launch of various services. I would turn it around. the question is, does it have an advantage and if so what is the advantage of sysvinit over systemd?
That’s a bit of a complicated question I think. That would require someone versed in both and what is your idea of advantageous
To my knowledge sysvinit is the previous/traditional init system before systemd at least for RHEL. I suppose if you’re of the sort to feel systemd touches too many things that’s an advantage.
If you have some particular or personal reason to not use systemd then use sysvinit, its fine and a learning experience. I personally find systemd to be easy to work with but to each their own. Many things expect systemd these days so you may run unto issues.
When the system drops to an emergency shell, it typically gives you an indication of why depending on how far you got in the boot process.
How could anyone answer this without starting a debate? It is mostly a subjective question.
It is bit like asking “What is better, KDE or Gnome?”
3 Likes
My other question, and by that I do not want to open a debate, is whether sysvinite has distinct advantages over systemd?
a lot of linux users think systemd violates the unix philosophy of do one thing and do it well, and complain about it’s feature creep, say it is bloated, and insecure. this has created several non systemd forks of popular distros like debian (devuan, mx), arch (artix), and unique non systemd distros like void, etc
I also know that in Unix sysvinit is the traditional init process. The situation is that the particular distribution uses Sysvinit by default, but it also allows systemd, which is not enabled by default. The former works fine, but after switching to systemd, the system does not start, so there is no choice as to which one to use. Since most modern distributions today already work with systemd, there are plenty of even those starting with sysvinit, so they can be easily compared. Looking at them externally, there is not much difference between them, only the details are hidden under the hood.
Yes, and MX Linux is included in this line, which makes the default use of sysvinit more secure, but does not preclude the use of systemd. The latter doesn’t work for some reason. I know that even in the case of kernels, they are told not to update if something works. 
however, i would be interested to see why the system cannot boot properly with the systemd enabled.
What do they say about systemd not working over at MX Linux forum?
In response to a question about a similar error, they wrote on their own forums that it is a good idea to reinstall the systemd and systemd-shim packages because there may be problems with the packages after the system upgrade. (I also did a system update manually.) However, after reinstalling the mentioned packages and entering the appropriate kernel parameter, the system will not boot normally with systemd, you will need to return to sysvinit.
Alright, I see.
It’s been long ago I used MX Linux for a while. I do recall however that systemd worked for me back then.
I have been thinking of installing MXL in not so a distant future. I think I will be facing some challenges. First I would need to “convert” the system into btrfs’ subvolumes and then convert it to systemd to have it in multiboot system which uses systemd-boot. Sorry for a bit OT.
A few years ago, when I started to use Manjaro, then Antergos, I gave a chance to MX Linux, because like others I started to get acquainted with Linux through Debian. However, the simplicity and the initial friendly approach is priced. In one of the forum entries, I read that part of the community because of the age (gently expressed old guys :)) SYSVINIT likes better. Some special features of the Live CD they released works with sysvinit flawlessly. I guess that therefore supports Syvinit by default, so that they will also leave the possibility of using Systemd, only such mule solutions are not always good.
2 Likes
Best sales pitch ever: “sysvinit, it’s for old guys”
5 Likes
Well, they didn’t use exactly the same words.
1 Like
Did you install any systemd sysvinit compatibility layer (e.g. systemd-sysvcompat) ?
Since the network manager didn’t work after upgrading from MX Linux 19.4 to MX 21, I installed the network-manager-sysvinit-compat package based on the wiki.
https://mxlinux.org/wiki/upgrading-from-mx-19-to-mx-21-without-reinstalling/
Then I wanted to try systemd either by booting the system from the advanced menu or by typing the appropriate kernel parameter. On the MX forum, I asked directly if the network-manager-sysvinit-compat package affects the network management of a system started with systemd, the answer was no. Instead, with systemd, the system starts slowly and after a while gets into the emergency shell.
The problem was solved, all you had to do was turn off the automatic mount of the EFI partition in the fstab file.
That means the entry in /etc/fstab is probably wrong.
Keep in mind while the efi partition doesnt need to be mounted for the system to run, it does need to be mounted at times.
I don’t know if the efi partition entry would be wrong, but I do know that it had to be created before installing another distribution for multiple boot to work.
I am saying that systemd should be mounting the EFI partition. If it is failing, the mostly likely cause is that there is something wrong with what is added to /etc/fstab. The EFI partition shouldn’t need to be mounted nofail or noauto
Just having it not be mounted is usually not the solution. If you share the efi partition line from /etc/fstab and lsblk -o name,type,fstype,size,uuid,mountpoint we can probably figure out what the issue is.