Talk:Systemd

LVM Initramfs
Section Systemd

Shouldn't the complete command be:

or does the sentence means you've got to build both the kernel and initramfs by adding these two options if you use genkernel to build your kernel? Jil (talk) 11:24, 19 October 2013 (UTC)

kernel
The kernel options are outdated and look very different in 3.10.7 --Jonasstein (talk) 18:44, 9 September 2013 (UTC)

Does [ ] Enable Deprecated sysfs mean do NOT select this option? --allan gottlieb (talk) 22:38, 11 September 2013 (UTC)

I hear from 666, the answer to the above is yes. So does this mean tha " path to ueven helper" means we must clear this field out? I have (still from openrc) /sbin/hotplug.

id be careful if i were you.... id test this on a virtual machine and document down your procedure of what is working. id test blanking it first, then if it fails to load then insert it back and update wiki. 666threesixes666 (talk) 00:04, 12 September 2013 (UTC)

I don't have a virtual machine, but I am going to try on a test machine first. Indeed, I don't want to remove /sbin/hotplug and I am not sure that is the intent. I suspect I don't understand the in " path to uevent helper"

mkultra@mksrv [ ~ ]$ zcat /proc/config.gz | grep /sbin/hotplug CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"

i want to say that it should have /sbin/hotplug in the parenthesis. 666threesixes666 (talk) 00:37, 12 September 2013 (UTC)

So why don't we put it there in the wiki?

i haven't tested it, or marked it known to be working, that's why. u test it, if it works, then remove any references to the unaltered line, that sounds most reasonable to me. 666threesixes666 (talk) 00:55, 12 September 2013 (UTC)

I will test it. I am just held up while I check outthe point below on installation

gentoo-users plus the kernel comments itself say that the helper path should be blank, i.e., the wiki is correct as is

Installation
The wiki says you must install systemd before setting the use flag (or you get conflicts). My experience is the opposite. I have made the kernel changes, /run is there /etc/mtab is a symlink. If I now try to emerge systemd I get conflicts, but if I *first* set USE="$USE systemd -consolekit" and run emerge ... @world, I get no conflicts and systemd is among the packages to be installed. I will ask canek (a knowledgeable gentoo-user contributor on systemd/gnome3) what he thinks). As I said I don't have a virtual machine so it is not as easy for me to "start over". I am hoping that after the make ... @world I have not passed the point of no return.  That is I hope reverting the USE change and again doing emerge ... @world gets me back.  Thanks for your responses.  It is less frightening to believe there is someone to talk to / ask questions of.  --allan

Canek agrees and I have successfully booted into systemd with this method. So I changed to wiki to first change USE and then emerge @world, which automatically merges systemd.

I also changed some ordering and headings (but no content changes). I believe the ordering should be<br/ Pre Installation configuration Installation Booting Post installation configuration Other

I will start this. I have myself gone through booting on my system. As I said the content will not change (except for saying the USE should change before installing the package).

genkernel-next
There are problems with stable genkernel-next-35: kernel use init system from /sbin/init instead of /usr/lib/systemd/systemd Grub2 config is right: GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" Updating to unstable genkernel-next-47 fix this problem


 * genkernel-next is no longer part of Gentoo. Even if it was, this is now very much outdated. --Grknight (talk) 13:06, 1 October 2020 (UTC)

OpenRC vs SystemD
The difference between OpenRC and SystemD is not well clarified yet. Thank God for Wikipedia, the Wikipedia pages seem to dictate quite well the difference between OpenRC and SystemD. "OpenRC is a dependency-based init system that works with the system provided init program, normally /sbin/init. It is not a replacement for /sbin/init." "SystemD was developed for Linux to replace the init system inherited from UNIX System V and Berkeley Software Distribution (BSD) operating systems." Might want to include this note within the initial paragraphs of both OpenRC & SystemD Gentoo Wiki pages, so people don't get into a frenzy about who's better, or faster. (Also, both are programmed in C, so there's no Python coding political hype.) For now, I'm sticking with OpenRC as OpenRC just works and uninstalled Gnome. Gnome is currently now wanting to install SystemD which is stated to conflict with OpenRC being installed. (I use DWM, and at most XFCE for GUI, but still mostly terminal or keyboard only guy here.) From my experience with Fedora, SystemD seems to be a confusing mess to me for some odd reasons. Might have to do some house cleaning before I'll want to use it. --Roger (talk) 14:38, 10 December 2013 (UTC)


 * systemd is much more intrusive than just an init system. The fact that gnome will depend on it prove it. Another issue is that it is alpha quality software, and they are pushing it like if it was stable and well tested. Last but not least, systemd is already a bigger problem than the one it was intended to solve because instead of providing ways to implement policies, it implement the policies.
 * On gentoo, we have the choice for now, but with the binary distributions, the choice is limited to 1) don't support Gnome, 2) support Gnome the easy way with systemd, 3) support Gnome with the hassle to support different init systems, with only one that is fully compatible with Gnome.
 * The time will tell if systemd will be successful or if it will be like Hal. I hope for the later because if the idea is nice, its implementation is problematic.--Dominique (talk) 15:06, 27 January 2014 (UTC)

systemd and LVM
As one of the powerful features of gentoo is the possibility to make all by yourself, there should be a way how to use systemd+lvm+misc(raid,luks) WITHOUT using dracut or genkernel. There is no description somewhere what to do, to boot a LVM based system with a self-build initramfs and systemd. Tbe (talk)

state systemd is udev integrated
https://wiki.archlinux.org/index.php/Udev#Installation it should be denoted that systemd is an acceptable udev replacement for openrc use.

nm-applet
nm applet loads fine under openrc... systemd is a different story. as root this command works

inserting it into .xinitrc above or below exec startxfce4 does not work. as user it does not work either

errors about user level 1000 not being able to manipulate these commands.

for now i temporarily inserted a sudo dbus-launch nm-applet --sm-disable & @ xfce4 startup scripts as a work around. maybe we should have official intervention here.666threesixes666 (talk) 00:20, 22 December 2013 (UTC)

Reason for genkernel-next
I don't see any explanation why genkernel-next has been created, how does it relate to systemd and why the old genkernel is hard masked! Pavlix (talk) 16:29, 4 February 2015 (UTC)


 * This is no longer an issue. --Grknight (talk) 13:13, 1 October 2020 (UTC)

Keyboard configuration on 32-bit systems
Just a peculiarity, but might be worth mentioning under the "Locale" heading:

The selected keymap is loaded by udev during boot, but on 32 bit systems (i686) this fails because gzip fails to unzip the keymap file.

More information in this link: https://bbs.archlinux32.org/viewtopic.php?id=506

The solution is to unzip the required keyboard files manually, so udev doesn't have to.

(The relevant udev rule is 90-vconsole.rules, which calls systemd-vconsole-setup which in turn runs gzip on the gzipped keymap file, and that call fails on i686-based installs)

Ferdinand (talk) 10:52, 1 October 2020 (UTC)

Symlink for /etc/mtab
I'm trying to improve my understanding of Gentoo. I already have Gentoo running very nicely. with initrc. Since I have plenty of disk space, I have decided to construct an independent instance of Gentoo in a separate partition, using systemd. I realize that I could just "add" systemd support to my kernel and attempt to maintain two different init systems inside a single instance of Gentoo. But I don't want to mess up my existing installation. Better (and safer), I think, to build systemd in a separate partition, and wrestle with it there.

So I'm going through the AMD64 Handbook installation chapters again. I'm about ready to install a kernel in my new instance of Gentoo. And I think the reference to bug #477498 on this page can be dropped. Or at least modified, if the history might be of interest to somebody. The bug itself was marked RESOLVED almost five years ago. And the current stage3 tarball creates this symlink automatically. So the bit about /etc/mtab is superfluous now.

I realize that I could just go ahead and edit the article. But I thought I'd ask, first. Davidbryant (talk) 11:59, 28 June 2021 (UTC)