[Misc. / systemd removal] Removing systemd from Jessie

[bertc3p0]

Hi,

 

I want a clean Armbian image for BPi without systemd. I pulled the actual Armbian 5.02, elected jessie and vanilla/next kernel (4.4.2)

and checked SYSTEMD settings:

gerd@development ~/projekte/armbian/lib (git)-[master] % find ./ -type f -exec grep -H SYSTEMD {} \;
./configuration.sh:    SYSTEMD="no" # Enable or disable systemd on Jessie in debootstrap process

but systemd is still active in the created image. Is there a way to get rid off it ?

 

I saw in the blog that systemd is now default for jessie

 

 

Regards

 

Gerd

Edited February 21, 2016 by wildcat_paris
Changed topic title to more neutral and descriptive

[Igor]

We had this solution when there were booting problems because of systemd. Since it's solved this become deprecated. Switch is not operational but we forget to remove it.

[zador.blood.stained]

./configuration.sh:    SYSTEMD="no" # Enable or disable systemd on Jessie in debootstrap process

This option is obsolete (not supported currently). You should be able to remove systemd from Jessie after installation using this wiki article.

 

FYI, you may loose some Systemd-specific settings (like serial console settings, shutdown by pressing power button).

[wildcat_paris]

@zador.blood.stained

 

thanks

 

tested on raspbian jessie

needed to:

- clean some stuff with aptitude

- reboot

- remove systemd package without error

[bertc3p0]

Hi,

 

thanks for all your responses, but removing systemd afterwards isn't an option as I need an image for beginners.

 

Regards

 

Gerd

[zador.blood.stained]

thanks for all your responses, but removing systemd afterwards isn't an option as I need an image for beginners.

I don't know why systemd affects "image for beginners" use case, but if you don't want systemd, you can either build wheezy/trusty image, or try to implement systemd removal for jessie in customize-image.sh

[bertc3p0]

I don't know why systemd affects "image for beginners" use case, but if you don't want systemd, you can either build wheezy/trusty image, or try to implement systemd removal for jessie in customize-image.sh

the removal of systemd is far to complex for beginners - systemd itself simply sucks

I will have a look at the customizing script ....

[zador.blood.stained]

 

 

Yes, "systemd sucks" is very constructive, mixing PID 1 related functionality with everything else in the article truly shows "professionalism" of a person who wrote that.

I'm sure "beginners" will be happy when any Jessie-related instructions that use "systemctl" command won't work as expected.

 

I don't want to say that I totally agree with different subsystems depending on systemd or with one(or 2-3) package(s) implementing half of base system services, but current stable version of systemd does its job.

 

 

[bertc3p0]

Hi,

 

 

 

Yes, "systemd sucks" is very constructive, mixing PID 1 related functionality with everything else in the article truly shows "professionalism" of a person who wrote that.

 

I'm sure "beginners" will be happy when any Jessie-related instructions that use "systemctl" command won't work as expected.

 

I don't want to say that I totally agree with different subsystems depending on systemd or with one(or 2-3) package(s) implementing half of base system services, but current stable version of systemd does its job.

 

I don't want to bore other people with the 495th discussion about systemd. First time I had a look systemd wasn't there in armbian. Now it's standard and I need to look for another distribution.

 

Anyway: keep your good work going ...

 

Regards

 

Gerd

[blindpet]

Gerd I'm not sure why you are against systemd. I was pissed about it in the beginning until I learned all init.d scripts work on Debian Jessie with systemd. Then my anger disappeared

[zador.blood.stained]

Gerd I'm not sure why you are against systemd. I was pissed about it in the beginning until I learned all init.d scripts work on Debian Jessie with systemd. Then my anger disappeared

The "problem" is not that something doesn't work, it's more a philosophical issue. I'll just leave this here.

[pmpp]

following the wiki link offered in this thread, guessing that probably any GRUB/GRUB2/GRUB4DOS section would not apply to U-Boot , boldly ignoring the pam related red warning  without a password less login on uart i edited /boot/boot.cmd

 

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} ........................

by

setenv bootargs "init=/lib/sysvinit/init root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs}  ..................

did:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

 

 

i hope armbian-config will offer a way to do that more easily. giving the choice is important for aging guy who can't remember systemctl stuff.

[umiddelb]

I've just managed to build Devuan/Aarch64 for the Odroid C2 using the traditional debootstrap (on an Ubuntu host) way, so I might be able to patch the armbian/build scripts in order to generate a Devuan image.

[righttobeararm]

I kinda followed the advice here on an odroid c1, installed sysvinit* debs, checked that an inittab was present, edited boot.ini to include init=/lib/sysvinit/init as the last of bootargs, checked network.conf to feature the correct network setting, crossed fingers, rebooted, the touchscreen does not work but ssh does. Removed systemd and voila'.

 

If you wonder why, I use systems on the road and I have already experienced all the possible breakages when you alter some conditions, compared to whatever worked at home. I want a system with a fixed boot order, with a good amount of fully tested code. Systemd can't even manage to close the ssh connection before rebooting, nice to have a terminal windows hanging because of that huh?