Linda Walsh said the following on 04/11/2013 05:58 PM:
I would point out that the suse implementors believe it impossible to create backwards compatible systemd files to *allow* the *option* of booting from disk and have separate root and /usr file systems.
Lennart points out a number of things. First, he mentions that it's not systemd that introduced the issue of /usr being needed early on in the boot-init sequence, but that its something which has come about over the years. Second, he points out that there is an option with systemd to allow for separate / and /usr BUT ONLY IF YOU TAKE MEASURES TO GET OVER THOSE OTHER PROBLEMS THAT EXIST ANYWAY. One way he suggests is to have separate / and /usr and them modify the initrd to load both. Not something that is difficult, just something that you need to actually do.
That is trivial in sysVinit scripts. If the learning curve in systemd is not so steep, why wasn't anyone in SuSE able to figure this out before rolling 12.3?
I'd say the results speak for themselves about how easy it is to get things right in systemd.
Ah, sorry, I believe that its better to, as the proverb goes, "light a candle than curse the darkness". As far as I can see the people who have problems with systemd are the ... well "unbelievers", the people who don't want to listen, to research. The people who are again it from the get-go. They perpetuate various myths and repeat misinformation. That being said, Linda, you do have a point that the openSUSE packagers have not done a good job. I've pointed out that I had experience with systemd on Fedora before dealing with it openSuse. Because of that I never tried to use Yast to do systemd stuff. And yes, I had a system set up with / and /usr separate. I also ran openSuse 12.2 under systemd with / and /usr separate. I can't recall what I did so it was obviously not a big deal. The only reason I'm not running this 12.3 with them separate is that I'm experimenting with an all-in-one-BtrFS. The problems I'm having might be more to do with that since they seem to be disk/fs related.
NOTE: that doesn't mean the end product might not be better than what you have in sysVinit -- but things that handle alot more situations and are more comprehensive are almost always more difficult to configure in the first place.
The complexity of systemd is a lot less than that of sysvinit. Please don't confuse complexity with volume. The number of "config" files in systemd, files that specify targets and services, is quite large. This is because systemd is following the old adage that Tom Duff stated: "Each thing does one thing, only one thing and does it well". Each "config" file under /etc/systemd specifies just one activity in the dependency tree. The whole point is that the old sysvinit did not make a lot of things like dependencies explicit and could get itself into paradoxical situations. If you find systemd difficult to configure then I can see that you may be falling into a couple of traps. The first is that you're not looking at it from the POV of the dependency tree. This is understandable if you still have sysvinit convictions since sysvinit doesn't make its dependencies clear - that's because the only dependency is sequential. The only cure for this is to to let go of the sysvinit approach, flush it from your mind. The second is that you think that you need to configure everything. I've seen a few posts that imply that. This is no more true for systemd that it was for sysvinit. Its comes configured for the baseline case. You may need to customise some things. I did on one server. What you might have to do is so radically different from what you might have to do with sysvinit that there is little congruence and the tools and vision are quite different. Let me illustrate that. I converted a server from sysvinit to systemd and DNS stopped working. The server was the local server and used one of the tables at http://pgl.yoyo.org/ locally to stop adverts being visible in web pages and email. It took a long time to load. Under sysvinit the relevant script runs to completion. Under systemd the dispatcher times out; it thinks the job has hung and kills it, so the named never starts. It took me a while to figure out what was going on. Thankfully this was on a Mageia system, and they don't have a system manager anywhere as capable as Yast, so I wasn't tempted to waste time trying to solve this with Yast :-) As Lennart says: <quote src="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities"> Timeouts apply to all init script operations in systemd. While on SysV systems a hanging init script could freeze the system on systemd all init script operations are subject to a timeout of 5min. </quote> As I said, the problems people seem to have with systemd seem to come from expecting it to behave like sysvinit. It won't, it doesn't, and there for Yast as it stands cannot be used to to manage it. As I said, since I learnt systemd on systems without Yast, I don't have a problem with systemd since I don't expect to use Yast to manage it. But openSuse has always been my preferred distribution, so I'm disappointed that Yast isn't keeping up and I'd disheartened that so many people are blaming systemd for things that have nothing to do with systemd, like the /usr issue. quote src="http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken"> Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. </quote> Perhaps you recognise some of those from ussies that have come up on this list? -- Rock journalism is people who can't write interviewing people who can't talk for people who can't read. Frank Zappa, quoted in Linda Botts, "Loose Talk" (1980) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org