Talk:Systemd

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

LVM initramfs

Talk status
This discussion is done.

Section Systemd#Using_LVM2_with_Initramfs

Shouldn't the complete command be:

root #genkernel --udev --lvm --install initramfs

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)

Looks like the Systemd#Using_LVM_and_initramfs section now correctly contains ths --lvm flag and defines it is only needed when rebuilding the initramfs. --Maffblaster (talk) 23:16, 2 February 2022 (UTC)

kernel

Talk status
This discussion is done as of 2022-02-02.

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

This discussion was resolved in 2013. Closing discussion. --Maffblaster (talk) 23:13, 2 February 2022 (UTC)

Installation

Talk status
This discussion is done as of 2022-02-02.

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). — The preceding unsigned comment was added by Gottlieb (talkcontribs) 2013-09-13

Many changes to system profile targets have been made in the 9 years since this discussion originated. Such changes are no longer necessary as long as a correct profile has been selected... besides, it appears you adjusted the information here Special:Diff/49773/50225. Closing this discussion. --Maffblaster (talk) 23:12, 2 February 2022 (UTC)

genkernel-next

Talk status
This discussion is done as of 2020-10-01.

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 — The preceding unsigned comment was added by Valenistiy (talkcontribs) 2013-12-06

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

Talk status
This discussion is done as of 2022-02-02.

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)
There seems to be nothing to discuss here. By now most of our users know there's a large difference between OpenRC and systemd. This is by design. Besides... Gnome 3 works again on OpenRC systemd due to elogind. Closing this discussion. --Maffblaster (talk) 23:07, 2 February 2022 (UTC)

systemd and LVM

Talk status
This discussion is done as of 2022-02-02.

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)

The wiki is open to contributors who wish to write such a guide. There is no need for 'discussion'. Talk pages are not designed for requesting documentation be written. They are designed to discuss improvements to existing docs. If you do some searching and find that such a guide does not already exist on the wiki, you have a couple of options. 1) You can write it yourself and add it under your userspace. 2). You can put it somewhere under Requested articles. Hope this helps! --Maffblaster (talk) 23:04, 2 February 2022 (UTC)

state systemd is udev integrated

Talk status
This discussion is done as of 2022-02-02.

It should be denoted that systemd is an acceptable udev replacement for openrc use. — The preceding unsigned comment was added by 666threesixes666 (talkcontribs) 2013-12-19

This discussion does not make any sense to me. We'll close until someone can explain what this statement means. --Maffblaster (talk) 22:54, 2 February 2022 (UTC)

nm-applet

Talk status
This discussion is done as of 2022-02-02.

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

root #dbus-launch nm-applet --sm-disable &

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

user $dbus-launch nm-applet --sm-disable &

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)

This is an issue anymore. On systemd systems NetworkManager is started by a service file. See the NetworkManager article for more information. If anything, this discussion should be on the NetworkManager article. --Maffblaster (talk) 22:58, 2 February 2022 (UTC)

Reason for genkernel-next

Talk status
This discussion is done as of 2020-10-01.

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

Talk status
This discussion is done as of 2023-07-16.

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)

Feel free to mention it in the article if this is still an issue a few years later; as it is editable by anyone with an account. Thank you! --Maffblaster (talk) 08:19, 16 July 2023 (UTC)

Symlink for /etc/mtab

Talk status
This discussion is done as of 2021-07-16.

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)

I agree. This section has been removed since it is no longer relevant within modern environments. If someone finds the need to know about it, it can always be restored. See [[Special:Diff/1251938/1251940}}. Thank you! --Maffblaster (talk) 08:25, 16 July 2023 (UTC)