I once installed openSUSE-factory mainly for trying the new init: systemd
For a longer time I had no courage to really try it, but now I edited my grub Kernel line: init=/sbin/systemd
Rebooting didn’t make it, because the correct line would be: init=/bin/systemd
I never get it what the difference of /bin and /sbin shall be. Using that unwanted sysvinit session I installed additional:
systemd-sysvinit, which forces a removal of package sysvinit. That way “/bin/init” is exchanged with a symlink to “/sbin/systemd” and vice-versa programs like reboot and poweroff symlink to systemctl.
systemd-gtk, which holds /usr/bin/systemadm
Now this is a fantastic openSUSE-factory installation: It booted without a problem into my Lxde-session!
And using the just installed systemadm I could explore all of systemd targets, mounts, services and devices. Started as root I am able to misuse this fancy tool to even unmount partitions! I would never have thought of systemd to have no problems at all!
Best wishes and gratulation to the openSUSE release team!
I once heard that the ‘s’ in sbin stood for static binaries (vs. dynamic
binaries) meaning those that do not need any outside libraries (.so
files) to run. I do not know that this is true but I do not really care
either. Basically I think the SUSE way is described well above, as well
as in the Filesystem Hierarchy Standard.
With all this in mind, why is systemd in bin? Not sure… can systemd
be run again by a user? If so it’d make sense but if not perhaps it
should be moved to /sbin. I hope to setup systemd before too much
longer to do my own testing.
On 09/18/2011 04:06 PM, Knurpht wrote:
>
> I used to run systemd, but since this summer it’s faults at boot, jumps
> to a login prompt, where anything I do makes the system reboot.
Have you upgraded to the latest factory? My MS5 installation failed to mount
/home, but an upgrade last Monday fixed that.
My final problem with systemd was that sound came up with a dummy output device
with no sound. This is a permissions problem. Adding my users to the “audio”
group cured the situation.
@ab, yes systemd shall be used for dbus, xinetd, cron in the future. This surely is the point: systemd for also normal users!
@Knurpht, your case is the more interesting than mine: problems to solve! Finding a bug?
Perhaps it is needed now: systemd-sysvinit ?! I didn’t try without (only a false try). With systemd-sysvinit there is no need to set init at grubs kernel-line to come systemd into play …
You could set a minor ambitious default.target than graphical.target, perhaps linking recovery.target? What else: rsyslog as syslog?
And sure, it is absolutly needed to have the newest factory udev, kernel, systemd etc installed!
Factory-tested lags behind, isn’t cared about anymore?
Having had a working sound before systemd, audio worked as expected, but: It is now possible to adjust sound volumes by a pulseaudio device and an alsa device at the same time! This should not, i think. Lennart.P. develops systemd without knowing how pulseaudio works (ironic tag)?