0
bertc3p0

[Misc. / systemd removal] Removing systemd from Jessie

Recommended Posts

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 by wildcat_paris
Changed topic title to more neutral and descriptive

Share this post


Link to post
Share on other sites

./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).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ....

Share this post


Link to post
Share on other sites

 

 

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.

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0