<div dir="ltr"><div>Thank you so much Andrew! I understand why protected property is there now, also I don't have much nice things to say about systemd so </div><div>When things didn't work as it used to be, I assumed the worst and blamed the usual suspect. </div><div>So the whole thing works nicely with:</div><div><br></div><div>apt-get --allow-remove-essential --no-install-recommends     --purge install sysv-rc sysvinit-core systemd-sysv-</div><div><br></div><div>Another thing is, I had to install ifupdown otherwise the nics don't go up, maybe it needs to be a recommended package? Just an idea. </div><div>Let me know if you need help on the init page wiki. </div><div>Thanks so much everyone for keeping sysvinit alive. </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>aldemir</div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 19 Feb 2026 at 11:11, Andrew Bower <<a href="mailto:andrew@bower.uk">andrew@bower.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 19, 2026 at 09:49:39AM +0300, Aldemir Akpinar wrote:<br>
>    That kind of worked. At least apt obeyed and tried to remove systemd:<br>
<br>
I realise you ran the command Thorsten gave you but it would be better<br>
if you had included the command line with your output here to confirm<br>
exactly what command was run:<br>
<br>
>    (Reading database ... 27088 files and directories currently installed.)<br>
>    Removing systemd (257.9-1~deb13u1) ...<br>
>    systemd is the active init system, please switch to another before<br>
>    removing systemd.<br>
<br>
I don't believe you needed to include 'systemd-' in this command line -<br>
you do that as a second step after reboot, as before.<br>
<br>
>    dpkg: error processing package systemd (--remove):<br>
>     installed systemd package pre-removal script subprocess returned error<br>
>    exit status 1<br>
>    dpkg: too many errors, stopping<br>
>    /usr/lib/tmpfiles.d/legacy.conf:14: Duplicate line for path "/run/lock",<br>
>    ignoring.<br>
>    Errors were encountered while processing:<br>
>     systemd<br>
>    Processing was halted because there were too many errors.<br>
>    E: Sub-process /usr/bin/dpkg returned an error code (1)<br>
>    Now <a href="https://wiki.debian.org/Init" rel="noreferrer" target="_blank">https://wiki.debian.org/Init</a> tells me to boot to single user mode,<br>
>    mount /dev and /proc etc. and install sysvinit-core. This is a regression<br>
>    imo (not blaming sysvinit-core maintainers obviously).<br>
<br>
I don't think this is necessary. Sorry, I think the wiki page needs<br>
rewriting. I have never done this - perhaps it was necessary in the<br>
past. It seems the optimal instructions are a hybrid of the "at<br>
installation time" and "at runtime" instructions.<br>
<br>
>    I used to do an apt-get install sysvinit-core, reboot, and apt-get remove<br>
>    systemd. It always worked from jessie to bookworm. <br>
<br>
Sorry for having directed you to the wiki when it merely added confusion<br>
- I didn't realise how out of date it was.<br>
<br>
However, the core point was that you needed to use<br>
--allow-remove-essential with the 'apt-get install' command as I told<br>
you previously. That was just one option change from before.<br>
<br>
>    Especially doing this boot to rescue and switch to another init on a<br>
>    virtual server on hosting platforms is a chore. I also thought systemd was<br>
>    dropping sysv support so why all of a sudden systemd-sysv becomes an<br>
>    essential package?<br>
<br>
systemd-sysv is the package that allows systemd to replace sysv-init.<br>
<br>
There is a bit of terminological confusion here. The<br>
--allow-remove-essential actually enables the removal of packages<br>
with the "Protected: yes" property. So systemd hasn't been deemed<br>
essential.<br>
<br>
What has changed is that init systems, including sysvinit, have gained<br>
this protected property to stop init systems being changed accidentally<br>
when you install other packages. That used to happen in multiple<br>
directions and, while it could be deemed unnecessary, is not done to<br>
hurt any group of users and has actually benefitted runit users who used<br>
to have more hoops to jump through.<br>
<br>
>    I feel like debian doesn't care about choice anymore, becoming just<br>
>    another redhat clone. <br>
<br>
Then you will be pleased to know that that was not the motivation here!<br>
</blockquote></div>