I just got the following entry on my boot up today:
systemd[1]: Failed to start Create Volatile Files and Directories.
After a while of searching using my favorit searchengine, I (as usual ;-)) found the most fitting solution in the bbs.archlinux.org.
The solution is given in the manpage of the tmpfiles.d.
tmpfiles.d(5) wrote:
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.
So all you have to do is:
# sudo su
# cd /usr/lib/tmpfiles.d
# cp journal-nocow.conf journal-nocow.conf.bak
# rm journal-nocow.conf.bak
# ln -s /dev/null journal-nocow.conf
And thats it. Fingers crossed you system will boot without errors.
I was wondering why my system clock was "so damn wrong". A quick check with systemctl status openntpd.service showed me "Active: inactive (dead) since ...". An other "journalctl -xfn" on the command line and "fatal: bad privsep dir /var/lib/ntp permissions: 40755" was marked red.
Searching on the web was, well, some kind of helpful. An old (asian?) entry was the highest in the ranking. After that, I searched on the official repository on github.com and found this patch (full patch view).
After that, it was an easy one to get openntpd back on track. chown -R root /var/lib/ntp and to be on the save side chmod -R 700 /var/lib/ntp followed by systemctl restart openntpd.service and my clock was back on track :-).
So I'm having this problem on three machines. I've also done the advice "udevadm hwdb --update" but the error still exists on the next boot.
Good thing about it, all is still working. My machines have a "hwdb.bin" file in "/etc/udev/hwdb.bin". I found a bug report on the arch linux bug report list as well as one on the systemd bug report list but no solution.
I will update this entry when I've found a solution or if the error disappears on one of the upcomming updates.
Im freien magazin, Ausgabe 11/2012 bin ich über eine kleine und nette Erläuterung zum Thema systemd gestolpert.
Unit Files
Ein zentrales Konzept von systemd sind die Unit-Files, welche die Init-Skripte von anderen Systemen ersetzen und einfacher aufgebaut sind.
Unit Typen
Es gibt verschiedene Arten von Unit Files, nachfolgend ein paar Beispiele:
Unit FilesDienste____Typen.service____Typ für normale Dienste
.target____Zieltyp, dient z .B. als Ersatz für Runlevels (graphical.target), aber auch für Zwischenschritte (network.target, local-fs.target, …)
.mount____Typ für Mountpoints, meist automatisch durch systemd-fstab-generator erzeugt
.socket____Typ für Socket Activation von Diensten
Quelle
Auf der Seite vom freien magazin gibt es auch Gegenüberstellungen von systemd skripte zu systeminitV skripten. Bei mir kam ein kleiner "ahh" Effekt :-).