Installing an isolated sysvinit can coexist with systemd. Obviously, booting our concoction boots with init as the parent process of all processes.

Please note the creation of an isolated sysvinit requires one to manually create symbolic links in its rcN.d. It also requires populating its init.d directory with all the necessary scripts/programs, although symbolic links pointing outside our creation, should also be possible to be used. The script takes care of populating dgli/etc/init.d but leaves populating rcN.d for the user.

The Method (you may call it Russian Roulette if you like):

Download and extract the sources for sysvinit for your version of debian. Make sure the debian directory exists and is not empty. Mine is like this:

Populate the dgli/etc/rcN.d with the respective symbolic links. Make sure that the links are not stale.

Copy the following script, save it to a file in the same directory where you have the newly created .deb packages, and make it executable. Check whether there are any daemons you use that are not listed. Please note, that the standard daemons included in sysvinit are NOT listed as EXTRA DAEMONS. Check the script for this step and follow the syntax.

# What to do when CTRL-ALT-DEL is pressed.ca:12345:ctrlaltdel:/dgli/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).#kb::kbrequest:/bin/echo "Keyboard Request--edit /dgli/etc/inittab to let this work."

# What to do when the power fails/returns.pf::powerwait:/dgli/etc/init.d/powerfail startpn::powerfailnow:/dgli/etc/init.d/powerfail nowpo::powerokwait:/dgli/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.## The "id" field MUST be the same as the last# characters of the device (after "tty").## Format:# <id>:<runlevels>:<action>:<process>## Note that on most Debian systems tty7 is used by the X Window System,# so if you want to add more getty's go ahead but skip tty7 if you run X.#1:2345:respawn:/sbin/getty 38400 tty12:23:respawn:/sbin/getty 38400 tty23:23:respawn:/sbin/getty 38400 tty34:23:respawn:/sbin/getty 38400 tty45:23:respawn:/sbin/getty 38400 tty56:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)##T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.##T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

Edit the scripts in dgli/etc/init.d. Paths must agree with what we did in paths.h they must also be such as to call the appropriate scripts/programs now moved to the tree rooted at dgli.

Inspect dgli directory tree for any broken symbolic links. I found only one at:

You can now understand why I called it a micro-system, or pejoratively, a rootkit.

Move dgli to the root directory.

At the GRUB screen, press 'e' to enter edit mode. Move down to the kernel line and insert the parameter:[code]init=/dgli/sbin/init

If everthing is correct, which usually never is for complex hacks, you should be able to boot.

I am thinking about making these changes into a final binary package, but in the true spirit of open source and freedom, I also gave and will give all the necessary details regarding this hack.

If the forum software allows me, I will also upload the contents of the modified scripts/programs in dgli/etc/init.d.

If you are uncomfortable having something as complex as this installed, without the package management system's knowledge, you can build a package using dpkg -b, but you have to supply a control file, obviously, with correct entries. The other hack, regarding providing an empty package for systemd, can be improved, and that is exactly what I want to achieve, by including a dependency requiring our micro-system, let us call it, born-again-sysv.

I intend to produce these two packages to help those who want to continue using Debian when it decides systemd to become mandatory. Till now, there is no need of these complex hacks, but we have to be prepared for any eventuality.

May the spirit of reciprocal help, promote the cause of free and open source to all.

However, I'm going to fork systemd - as I've already said, I like the idea behind it, but I can't withstand or even tolerate that shitty code which comes with the original implementation of systemd. Of course I'm going to drop most of the "extensions" of systemd, like the DNS daemon... (stupidity has limits - users can vote with their feets - there's no equevalent for as extremely stupid piece of code as systemd' DNS service...)

It's relly not so surprising - RedHat has very similar development model to Microshit: targets. Go to the target, implement a target solution - no matter if the code is a shit - target was reached, money has been paid... Yeah I'm the RMVP (RedHat Most Valuable Professional)...

However, I'm going to fork systemd - as I've already said, I like the idea behind it, but I can't withstand or even tolerate that shitty code which comes with the original implementation of systemd. Of course I'm going to drop most of the "extensions" of systemd, like the DNS daemon... (stupidity has limits - users can vote with their feets - there's no equevalent for as extremely stupid piece of code as systemd' DNS service...)

It's relly not so surprising - RedHat has very similar development model to Microshit: targets. Go to the target, implement a target solution - no matter if the code is a shit - target was reached, money has been paid... Yeah I'm the RMVP (RedHat Most Valuable Professional)...

Morons are not born, morons are created...

Regards

Thanks for the encouragement. If you think, I can help, send me a private message.

These days we do things like install a boot sector virus for our init and then have a boot level anti-virus to deactivate and circumvent that boot sector virus so we can boot and initialize our basic services.

This is wonderful.

This is exactly what we needed.

We needed to first have something that worked, then force something that works in questionable ways or doesn't work, and then have other scripts to deactivate the thing that works in questionable so we can get back to something that works.

anastasis wrote:We needed to first have something that worked, then force something that works in questionable ways or doesn't work, and then have other scripts to deactivate the thing that works in questionable so we can get back to something that works.

You are right this is a contorted solution. Frankly, I would have preferred a solution that worked seemlessly with Debian's package management system. However, it is not up to me to 'oblige' the DDs to continue supporting sysvinit. In fact, systemd, lookd more like an overkill for normal computer uses, but I have to live in a world where decisions may not depend on me. In the real world, many decisions are like that: while they heal many, they injure many others.