LinuxBBQ

If you are not following the BBQ philosophy and use heavily systemd related packages (e.g. policykit-1) or Gnome apps that depend on it then you might see the occasion that it wants to pull either systemd for the very first time into your system or even remove sysvinit-core.
Though it should not be a problem but be prepared, read about systemd or ask Pidsley. :)

If you want to avoid systemd taking over your system for now then you should not use Gnome apps that depend on it like network-manager and probably some others that are related to libpam-systemd or install systemd-shim. You will still have to allow systemd, the package, to be installed because Debian prepares the switch, but it won't replace sysv yet without you doing it explicitly at the moment.

Short Wiki article for further reading.

If you want to switch now, search our forums for some experience and read the Debian Wiki.

Please, no init wars! If you have questions about alternate inits then open a new thread in the correct section.

Side note: LinuxBBQ comes with both inits depending on the release. The newest base releases are using sysv as default at the moment.

Great info - Ivan, thanks!

Thanks DD!

Thanks for the info Ivan, cheers.

Simgin

Made it sticky. The shitstorm is already rolling in Debian.

The transition is definitely going on. You will get systemd as the new init system right now if you use packages that depend on systemd-sysv as already said in the OP. It should be smooth according to Debian.
They are rethinking about noticing the user about it in a better way.

Thanks for this one.

Thanks Dave. I'd recommend to stay with what is provided in the release, so systemd in the older ones and sysv in the newer releases. If someone wants to make a switch, he or she can post here about the experience and results, I'd say.

Experience you say, I already tried it just for fun. It worked perfectly. No problem whatsoever on my very old sid system. So the transition just worked as intended by Debian and I am positively surprised that it works so good. Nothing really fancy but the shutdown is just a blink with the eye.

Welcome back if I can say so Mr. Bacon!

that for sure is a + for the big d, fast finish. Well, at least in this context. But shutdowns are few and far between I guess.

It seems Gekko removed a notice before and I was replying to it. Udisks2 will pull also systemd-sysv and that means it will remove sysvinit. It is expected.

^ yes, I forgot about your topic here and since you already wrote about this issue I thought my notice was pointless.

It was ok. Maybe I would have anyway moved it here.

By the way. I installed systemd and it was hanging on boot due to an error on my /etc/fstab. So if anyone should see something similar to this line at boot:
Just double-check that the entries in /etc/fstab match the blkid output. In my case, the entry for the swap partition was wrong.

Yep, it is reported that if you have an entry in fstab the transition can fail.

If I am not mistaken, the wrong UUID in fstab may come from a bug in update-grub. I would recommend to remove anything except the / from fstab and mount manually. systemd will hang at this point up to minutes, sysvinit will skip it with a FAIL.

hplip will pull in systemd, too. I learned that playing around with Sid before it crashed and burned. My next hardware purchases will be a little better thought out, I can tell you that for free.

^ Are you sure about hplip? apt-cache depends doesn't show systemd. Maybe you have --no-install-recommends not turned on and it came from somewhere else.


apt-cache rdepends systemd

^ Installing hplip wants to purge sysvinit-core (I think that's it) and after a reboot, you're using systemd. It happened on Spring, and it happened again on Author.

I read something about that but then I do not use that package:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=578808

Ah, thanks Davidic :D

If you wish to run a headless print server, we now ship the independent
packages of hpijs and hplip-cups, which do not require the full hplip depends.