Version bump to systemd-43 / Move to /usr
Exherbo / February 19, 2012

(This is the same as the news item but I want this to get maximum exposure.) Read ALL of this, it’s important to everyone using systemd. Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr. systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr. This won’t matter much to you if you don’t have /usr split from / (it should not be split; cf. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken). Even if you don’t have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I’ve rev-bumped all packages, that install their own custom systemd units but even after you’ve updated those, you’ll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them. Should you forget to do so, you might end up in systemd’s emergency mode. If that happens, don’t panic. Get your network connection up and continue updating/re-installing. You’ll live, I promise. There might be orphaned systemd units left behind. Check those on your own and decide if…

HowTo: systemd on Exherbo
Exherbo / October 18, 2010

This comes up all too often, so here’s a HowTo for systemd on Exherbo: You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd. You should run a Linux kernel >=3.8. The new kernel is only needed at runtime, not for building systemd. Kernel options for systemd: cf. systemd’s README, here’s an excerpt: CONFIG_DEVTMPFS CONFIG_CGROUPS (it’s OK to disable all controllers) CONFIG_INOTIFY_USER CONFIG_SIGNALFD CONFIG_TIMERFD CONFIG_EPOLL CONFIG_NET CONFIG_SYSFS Linux kernel >= 3.8 for Smack support Udev will fail to work with the legacy layout: CONFIG_SYSFS_DEPRECATED=n Legacy hotplug slows down the system and confuses udev: CONFIG_UEVENT_HELPER_PATH=”” Userspace firmware loading is deprecated, will go away, and sometimes causes problems: CONFIG_FW_LOADER_USER_HELPER=n Some udev rules and virtualization detection relies on it: CONFIG_DMIID Mount and bind mount handling might require it: CONFIG_FHANDLE Optional but strongly recommended: CONFIG_IPV6 CONFIG_AUTOFS4_FS CONFIG_TMPFS_POSIX_ACL CONFIG_TMPFS_XATTR CONFIG_SECCOMP For systemd-bootchart a kernel with procfs support and several proc output options enabled is required: CONFIG_PROC_FS CONFIG_SCHEDSTATS CONFIG_SCHED_DEBUG For UEFI systems: CONFIG_EFI_VARS CONFIG_EFI_PARTITION Furthermore: CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.) CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)   Set the “systemd” option globally in /etc/paludis/options.conf: */* systemd Install…

systemd and the Linux kernel
Exherbo / September 13, 2010

This comes up all too often, so here’s a HowTo for systemd on Exherbo: You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd. You should run a Linux kernel >=3.0. The new kernel is only needed at runtime, not for building systemd. Kernel options for systemd: In your kernel config, enable autofs4, devtmpfs and cgroups. Do not enable autofs3. Here’s what I’m using (I enable more kernel options than strictly necessary, though.): CONFIG_DEVTMPFS=y (Strictly required!) CONFIG_DEVTMPFS_MOUNT=y (unless you’re using an initramfs that’s mounting it for you, e. g. one created by Dracut) # CONFIG_AUTOFS_FS is not set (Strictly required!) CONFIG_AUTOFS4_FS=y (Strictly required!) CONFIG_CGROUPS=y (Strictly required!) # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_CGROUP_SCHED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.) CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

systemd in Exherbo – what’s happened so far…
Exherbo / September 12, 2010

It has been quite a while since I last wrote something about my work on systemd in Exherbo, so here’s an update: What has been accomplished so far: The Exherbo patches are done. Do NOT try to submit them upstream yet, though. I’ll take care of that when the time is ripe. Lots of services are done. You can boot and run most systems using systemd now. I’ve built new amd64 and x86 stages without any init system so you can start out without the baselayout-1/sysvinit cruft. The installation guide has been updated. Every systemd service is implemented natively and we’re not using anything from baselayout-1 or sysvinit anymore. Instead, all the important stuff has been moved to skeleton-filesystem-layout. systemd’s dependencies have been updated accordingly. Thus, for people using systemd, baselayout-1 and sysvinit are now obsolete. YAY! What still needs to be done: Improve existing service definitions for systemd. Create socket definitions for several of the existing service definitions. (And new ones, of course.) Create systemd service files for missing services. Rules for new service files: Please make sure they’re implemented natively. I won’t accept non-native service files unless you can convince me there’s definitely no other solution. If you…

systemd in Exherbo – Rules of Engagement
Exherbo / June 9, 2010

As you may have noticed, I’ve recently added systemd to ::philantrop for use in Exherbo. I’m writing this to warn you that I will break systemd (and consequently your boot process) until further notice recklessly, repeatedly and without prior warning to anyone make clear what I intend to do with systemd in Exherbo make a plan for myself. What I want to do first is get a feeling for systemd and see if it might have the potential to replace baselayout-1 (bl-1) and, at least for myself, be used instead of the init-system-that-is-not-to-be. 😉 As I really want to replace bl-1, I’m not going to go the Gentoo way of simply adding a handful of pseudo-units that essentially just call the openrc init scripts. If you want that, you’re on your own and I won’t accept patches that do that. Instead, I’m aiming for: a full native set of systemd units not tainted by anything else a minimal set of non-native configuration files (what we currently have in /etc/conf.d; I don’t think it will be possible to avoid them completely but I will if I can) staying as near to upstream as possible and I’ll try to submit my patches…