A systemd-only Gentoo system Homepage: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/index.html Git repository: git://github.com/canek-pelaez/gentoo-systemd-only.git # git clone git://github.com/canek-pelaez/gentoo-systemd-only.git Or with layman # USE=git emerge -av layman # layman -o https://raw.github.com/canek-pelaez/gentoo-systemd-only/master/overlay.xml -f -a gentoo-systemd-only Introduction The package sys-apps/systemd was added to the portage tree in June of 2011, and since then support for it has only been growing. As of now (February, 2013), almost any hardware configuration it's able to run Linux with systemd. The systemd package is written as a drop-in replacement for SysV init; however, Gentoo utilizes OpenRC, a different init system that runs on top of SysV init. This makes it impossible for systemd to use any of the init scripts that Gentoo packages normally install in /etc/init.d. The Gentoo developers that introduced systemd into the portage tree decided (quite wisely) that systemd should be able to be installed in parallel to OpenRC, so that users will be able to test it first and get back to the default setup if something went wrong, or if the user didn't liked systemd. Nowadays this doesn't always work, since systemd has took over the functionality provided by ConsoleKit (which is unmaintained), and so the user needs to recompile some packages to use ConsoleKit or systemd, depending on if she's using OpenRC or systemd. However, if a user decides to use systemd exclusively, it is not possible to install it as the only init system in a Gentoo machine right now: The package sys-apps/baselayout is included in the @system set, and it depends on sys-apps/ openrc, so every single Gentoo installation includes both packages, unless the user explicitly configures her system to avoid the installation of said packages. This overlay is an experiment to see how difficult it is to remove OpenRC from a Gentoo system, so it runs only with systemd. I will try to keep the overlay in sync with the portage tree until the listed bugs are fixed and the new ebuilds (or similar alternatives) are accepted. Why Why not? More seriously, Gentoo is about choice. Some of us that choose to use systemd see no reason on having OpenRC/SysV init installed; it's the same the other way around, an OpenRC user should not need to have systemd installed on her machine. Instructions This set of instructions assume that you have already installed sys-apps/ systemd. 1. Before anything, BACKUP YOUR SYSTEM AND YOUR PORTAGE CONFIGURATION. Make a backup of: /var/lib/portage/world /etc/portage /etc/runlevels /etc/init.d /etc/conf.d WARNING: IF YOU FAIL TO FOLLOW THESE STEPS PROPERLY, YOU MAY RENDER YOUR SYSTEM UNUSABLE. EVEN IF YOU FOLLOW THESE STEPS PROPERLY, YOU MAY RENDER YOUR SYSTEM UNUSABLE. MAKE SURE YOU KNOW WHAT YOU ARE DOING. I TAKE NO RESPONSIBILITY IF THIS OVERLAY EATS YOUR SYSTEM AND THEN RUNS AWAY WITH ALL YOUR VALUABLES. That being said: If you are already using systemd, the removal of sys- apps/openrc should not affect your system; the removal of sys-apps/ sysvinit should also be safe, provided that you install sys-apps/sysvinit- tools and sys-apps/systemd-sysv-utils; and the removal of sys-apps/ baselayout should also be safe, provided that you install sys-apps/ systemd-baselayout. 2. Add the directory with the gentoo-systemd-only overlay to the PORTDIR_OVERLAY variable in /etc/portage/make.conf: /etc/portage/make.conf PORTDIR_OVERLAY="/path/to/gentoo-systemd-only" 3. Edit /etc/portage/profile/packages (create it if it doesn't exists) and add the following lines: /etc/portage/profile/packages -*>=sys-apps/baselayout-2 *>=sys-apps/systemd-baselayout-10 The first line removes baselayout from the @system set, the second one adds sys-apps/systemd-baselayout to it. 4. Edit /etc/portage/profile/use.mask (create it if it doesn't exists) and add the following line: /etc/portage/profile/use.mask -systemd The systemd USE flag is currently masked, so we unmask it here. 5. Edit /etc/portage/package.keywords and add sys-apps/systemd-baselayout, sys-apps/sysvinit-tools, and and sys-apps/systemd-sysv-utils: /etc/portage/package.keywords =sys-apps/systemd-sysv-utils-37 ~amd64 =sys-apps/sysvinit-tools-2.88-r4 ~amd64 =sys-apps/systemd-baselayout-10.0 ~amd64 The first two packages replace sys-apps/sysvinit; the last one replaces sys-apps/baselayout. 6. Edit /etc/portage/package.unmask and add sys-apps/systemd-sysv-utils to it: /etc/portage/package.unmask =sys-apps/systemd-sysv-utils-37 7. Uninstall sys-apps/openrc, sys-apps/baselayout and sys-apps/sysvinit: # emerge --unmerge --verbose sys-apps/openrc sys-apps/baselayout sys- apps/sysvinit 8. See if you can upgrade the @world set: # emerge --newuse --deep --update --verbose --pretend @world If the emerge is feasible, go for it: # emerge --newuse --deep --update --verbose @world If you have to keyword (possible) and unmask (it should not be necessary) packages, do it and try again. If in the pretended emerge, sys-apps/openrc, sys-apps/baselayout or sys- apps/sysvinit try to get installed again, it means that you have a package installed that needs them, and for which there is no alternative in this overlay. You can get back to the backup you did in step 1 (you did it, right?), and simply install again sys-apps/openrc, sys-apps/baselayout and sys-apps/sysvinit, or you can track the offending package and create an alternative ebuild that uses the replacements in this overlay (please send it to me if you do). If you don't know how to do it, you can send me the output of the pretendend emerge so I can create the alternative ebuild, integrate it in the overlay, and then you will be able to do the emerge. 9. (Recommended). Some packages, like sys-auth/polkit, can only work with systemd or ConsoleKit; you need to compile them with either systemd or ConsoleKit support. If you are running systemd, chances are some packages will fail (sometimes weirdly) if they have ConsoleKit support instead of systemd's. So it is recommended to: # USE="systemd -consolekit" emerge --newuse --deep --update --verbose -- pretend @world If the emerge works, you should probably uninstall consolekit, which is unmaintained anyway. OpenRC init scripts Please note that the instructions from above only remove the package sys-apps/ openrc: They do nothing to prevent arbitrary packages to install init scripts on /etc/init.d. If you want to avoid the installation of init scripts on /etc/ init.d, please edit /etc/portage/make.conf with an appropriate INSTALL_MASK variable. 1. (Optional) Add the following directories to INSTALL_MASK in /etc/portage/ make.conf: /etc/portage/make.conf INSTALL_MASK="/etc/init.d /etc/conf.d /etc/runlevels" In time, those directories will be empty. If you feel adventurous, you can delete them: They should not matter if you use systemd. This is the same for users of OpenRC who don't want to have installed systemd service files on /usr/lib/systemd: They need to set up an appropriate INSTALL_MASK variable in /etc/portage/make.conf. Getting cold feet If you want to get back to the normal portage configuration, just uninstall every package from the overlay, delete the overlay and restore your backup from step 1 (you did a backup, right?). You then do # emerge --newuse --deep --update --verbose @world and, in theory, everything should get back to normal. The bug #373219 (https://bugs.gentoo.org/show_bug.cgi?id=373219) Bug #373219 (https://bugs.gentoo.org/show_bug.cgi?id=373219) deals with the fact that there are scripts all over the portage tree which implicitly depend on sys-apps/openrc since they source /etc/init.d/functions.sh. The devs responsible for OpenRC seems to resist the idea of splitting the e* log functions from OpenRC (which is what most of the scripts on the tree seems to be using) into another package, so if you remove OpenRC (which is one of the goals of this overlay), you loose /etc/init.d/functions.sh and therefore some scripts on the tree will stop working. To workaround this, I'm introducing sys-libs/elog-functions, which provides full compatibilty functions for the e* log functions from OpenRC, and I'm introducing alternative versions of packages that depend (implicitly) on OpenRC so this new versions use it. Right now that's: * app-admin/perl-cleaner * app-admin/python-updater * app-portage/gentoolkit * dev-java/java-config-wrapper * sys-devel/binutils-config * sys-devel/gcc-config They all seem to work in my systems, but please inform me if you find any problem. Also, if you know about other package depending implicitly on OpenRC, please let me know. Besides these packages, sys-libs/glibc provides the /usr/sbin/locale-gen script, and sys-devel/gcc provides /sbin/fix_libtool_files.sh (also on /usr/ share/gcc-data/x86_64-pc-linux-gnu/${PV}/fix_libtool_files.sh). Both scripts sources /etc/init.d/functions.sh, but the ebuilds are complex enough for me to even try to provide alternatives. Therefore, in the no-openrc-scripts directory of this overlay you will find alternative versions of both locale-gen and fix_libtool_files.sh, that you can replace by hand. If you emerge sys-libs/glibc or sys-devel/gcc without OpenRC, the ebuild will print an error when it tries to execute an script that cannot source /etc/ init.d/functions.sh; however, the installation will complete correctly, and you can run the scripts provided here afterwards. Changes from the official portage tree You can see the (simple) changes that the ebuilds in this overlay make by doing a diff to the corresponding ebuilds in the portage tree. * app-admin/perl-cleaner, app-admin/python-updater, app-portage/gentoolkit, dev-java/java-config-wrapper, sys-devel/binutils-config, sys-devel/gcc- config: o Source /usr/lib/misc/elog-functions.sh instead of /etc/init.d/functions.sh. Bug #373219 (https://bugs.gentoo.org/show_bug.cgi?id=373219). * sys-fs/lvm2: o Don't depend on sys-apps/baselayout. No bug reported; the LVM2 ebuild is complex enough, and although it really doesn't need sys-apps/baselayout, I think is best to wait until sys-apps/ baselayout stops depending on OpenRC. * sys-process/audit: o Use the systemd eclass. No bug reported until audit upstream includes the service file by default. Also, the systemd developers don't seem very fond of audit anyway, so I'm thinking in removing this one. * sys-kernel/dracut: o Depend on new package sys-apps/systemd-baselayout instead of sys-apps/ baselayout: No bug filled until sys-apps/systemd-baselayout is good enough to being considered for inclusion in the tree. o Depend on sys-apps/systemd-sysv-utils instead of sys-apps/sysvinit: No bug filled until sys-apps/systemd-sysv-utils gets unmasked. o Depend on new package sys-apps/sysvinit-tools: Bug #399615 (https://bugs.gentoo.org/show_bug.cgi?id=399615). The bug is closed, but sys-apps/util-linux disables most of the utils needed, and we still need killall5 and pidof. New packages: * sys-apps/sysvinit-tools: Initially in response to bug #399615 (https://bugs.gentoo.org/ show_bug.cgi?id=399615), now I keep it here only because dracut uses pidof, which is included here. The moment that binary moves to another package, it goes. * sys-apps/systemd-baselayout: Add systemd base configuration files: http://0pointer.de/blog/projects/the-new-configuration-files.html. Right now this is a replacement for sys-apps/baselayout; however, if sys- apps/baselayout drops the dependency on sys-apps/openrc, then we can make sys-apps/systemd-baselayout parallel-installable with it (or integrate systemd's configuration files into baselayout).