This what I did so far (multiarch x86-64 desktop on AMD cpu running in virtualbox)
1. installed systemd as per http://wiki.gentoo.org/wiki/Systemd with only these modifications
substituted 'real_init=/usr/lib/systemd/systemd' for 'real_init=/usr/lib64/systemd/systemd' as no systemd under lib (no lib at all in usr, instead I have lib32 and lib64 under usr)
also made /etc/localtime' a symlink (as per 'systemd-timedated' request, '/etc/localtime' needs to be a link)
2. added '/etc/modules-load.d/virtualbox.conf' containing 'vboxvideo' and 'vboxsf'
3. enabled the following services:
systemctl enable virtualbox-guest-additions.service
systemctl enable xdm.service
systemctl enable cups.service
systemctl enable dhcpcd.service
systemctl enable metalog.socket (made '/etc/systemd/system/metalog.service' and '/etc/systemd/system/metalog.socket' files for this one as per the instructions on http://gentoo-en.vfose.ru/wiki/Systemd)

Any advice on these errors? Any additional services which must be enabled?

Also, I have metalog running; is syslog-ng required too, and if so, how do you set that up as my '/etc/syslog-ng/syslog-ng.conf' does not contain 'unix-stream('/dev/log');' to replace? if I add 'unix-dgram('/dev/log');' under 'options' in the conf file I get "failed" errors._________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

Lucius Annaeus Seneca

Last edited by seneca on Sat Sep 28, 2013 11:19 am; edited 3 times in total

You must look with journalctl for the actal error messages. For instance which modules failed to load? Do you actually have the modules xvoxvideo and vboxsf in your kernel? (/usr/lib/modules-load.d might list further modules which you perhaps do not have).

If you reemerge metalog, it will provide its own unit file; I suggest to remove the files you have installed (and also the corresponding symlinks from enabling) and enable the new unit which will be called syslog.service. Of course, you can have only one syslog service, so you have to use either metalog or syslog-ng. I suggest you unmerge the one which you do not use. Since you seem to have problems with syslog-ng, I suggest to use metalog (which is fine IMHO although syslog-ng seems to be more popular - but maybe this is only the case because there are more questions about syslog-ng...)

I deleted 'vboxvideo' (as modprobe didn't find it) from '/etc/modules-load.d/virtualbox.conf' and the 'systemd-modules-load.service loaded failed failed' went away but I still have the other error (proc-sys-fs-binfmt_misc.automount loaded failed failed)

Everything seems to be ok there with no errors....?
vboxsf is loaded; if I remove that from modules-load.d it boots to terminal asking for root password to fix. It boots fine with vboxsf in modules-load.d.
mtab is symlinked to proc and this is the info in mtab

I did an 'emerge -e world' thinking "if metalog does that, what other programs would?", and the darn thing is still going ! ... and another ~350 packages to go. But I think grey_dot might have hit it on the nose with the not so wild guess. I came across this link after the last post, https://www.kernel.org/doc/Documentation/binfmt_misc.txt while checking to see if I had binfmt_misc enabled in the kernel, and it was enabled.

I alredy changed fstab to reflect

Quote:

none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0

but I can't reboot until the -e world finishes... '-e' is for 'eternal', right?

But I can tell you this much: 'modprobe binfmt_misc' gave an exit status of 0 and 'systemctl --failed' returns no failed service now, even without a reboot.

I will post the confirmation after I get to reboot and will mark this post [solved], but I think it is fixed.

One question, grey_dot, as you seem to know about this binfmt_misc: I do have wine emerged. Do I do the following to make it all work ok?

Quote:

echo ':DOSWin:M::MZ::/usr/local/bin/wine:' > register

_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

Hi mv
I see what you mean, emerge takes care of python from the build dependencies without any additional input from the end user, except for the infrequent emerge that asks for a specific one time target.. A simple emerge -NaDu @world takes care of python 99% of the time. I was using 'world" but I will change to '@world' from now on as you specifically reference it.

I will play with 'eix --use python_targets_python3_3' out of interest, as on more than one occasion I had the question of which packages needed which version. Adding that to the notebook too.

Still with 200 more packages to go on the -e world... I think the reboot will wait for tomorrow morning. I can't thank you enough for the tip of your prior post.

Best_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

I seem to remember reading in this forum, maybe it was a comment from Neddy but I can't remember who it was nor can I find it now (accept my apology for bringing you into this mess, Neddy, as possibly it was not you at all who made the statement), that systemd will be replaced at some point and I think the person who made the statement was not emerging it... so the question is this: is all this trouble worth it? should I revert to udev and forget all this? gnome 3.8 seemed to work just fine before I emerged systemd, so is this really needed?_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

The author of systemd is Lennart Poettering who is famous for producing unready software and after forcing everyone to switch recognizes how bad his software actually is and declares something new as the "Only True Way to go". So yes, you can assume that if you use Lennartware you have to reconfigure everything soon.

Quote:

gnome 3.8 seemed to work just fine before I emerged systemd, so is this really needed?

For gnome, it is needed, because gnome and Poettering are from the same institution (paid by Redhat) and gnome decides to be part of the process of shoving systemd down user's throat.

I am "long in the tooth" already and if I learned anything at all after all these years it would be that it is a wise man who listens to the advice of those who know much more than oneself about something.

I am going back to plain old udev, the part removed by systemd when it was emerged, and I will explore KDE further.

Thank you for the frankness and advice.

marking the post as [solved]

_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

gnome 3.8 seemed to work just fine before I emerged systemd, so is this really needed?

For gnome, it is needed, because gnome and Poettering are from the same institution (paid by Redhat) ...

Funny then my case: running kde with systemd for a year without problems (using little sabayon love from overlay before kde-4.11). But many gnome<3.8 users reported harsh problems using systemd the last year, why?

Things I don't want to miss:
- journald, because the old syslog is "unready" without configured extra tools.
- simple declarative style to create units myself
- simple way of masking services I don't want

I still have a problem with:
- efi+nvidia, where I hope current work in git will help ...

But I know
- you simply fail not using the correct kernel .config, which should be worked out due to Toms phantastic work.
- of troubles using Lvm2 with systemd.
Genkernel was designed for official Gentoo openrc setups, not to solve systemd problems ..._________________fun2gen2

Why do you mention only bad things that do disturb horribly with systemd?

Quote:

- journald, because the old syslog is "unready" without configured extra tools.

All classical syslog's are ready right from the start and need no extral tools, certainly not any configured. WIth journald on the other hand you need extra tools and even need to have daemons running just to read the content of the database. Even worse, systemd is not even ready to start the machine without having the corresponding daemons running. All such bad things could never happen with a classical syslog.

Quote:

- simple declarative style to create units myself

I miss in contrast the possibility to execute something more complex than a single command with fixed arguments. Most services now have to call a separate script which does the actual task - only completely primitive things can be done "in the systemd way". BTW, openrc has as an option a simple declarative style - it is just not used very often since practice has shown that most things need a more complicated setup. systemd can only do the primitive thing.

Quote:

- simple way of masking services I don't want

This is what I miss most in systemd. I would like so much to mask the stupid journald which I certainly do not want. Or the hardcoded setting of time and date in systemd which cannot be configured in the way I want. Or the stupid parsing of my /etc/fstab into systemd units which does not work correctly with correct /etc/fstab setups, because it can only do what Poettering's limited mind thought can be done with it. I can mask neither of these services - and certainly not in a simple way.

- journald, because the old syslog is "unready" without configured extra tools.

All classical syslog's are ready right from the start and need no extral tools, certainly not any configured. WIth journald on the other hand you need extra tools and even need to have daemons running just to read the content of the database.

It should be very easy to split out a systemdlessjournalreader application to just read the journals. Like you can read the journal of another root just now by giving its directory as parameter.

For me the old Syslog is NOT ready, because it an overwhelming bunch of unstructered bits. Every time I needed some special bits of information this was hard work to find.

Quote:

Quote:

- simple declarative style to create units myself

I miss in contrast the possibility to execute something more complex than a single command with fixed arguments.

I think sys-apps/gentoo-systemd-integration now has:
/etc/local.d/ start- stop-scripts activations via systemd
which I would wish to be found as standard for systemd distributions everywhere. Exactly what you demand? Also without that new Gentoo addition you are able to start your script in a unit service file.

Quote:

BTW, openrc has as an option a simple declarative style - it is just not used very often since practice has shown that most things need a more complicated setup.

Yes! Openrc is exactly that: Half the way to systemd! Ever I discussed this in our forum I pointed out: Quiet a bunch of systemd features are already implemented by openrc. In the Debian case of transition Openrc would have provided some common ground with their bsd-kernels on the way to systemd.

If "declarative style - it is not used often" by openrc: This points out the development of Openrc was far too slooow! Also the primary goals, obviously.

Quote:

Quote:

- simple way of masking services I don't want

This is what I miss most in systemd. I would like so much to mask the stupid journald which I certainly do not want.

Isn't it possible to just ignore it, or quiet it down? If not, a patch doing just that should be easily done.

Quote:

Or the hardcoded setting of time and date in systemd which cannot be configured in the way I want.

I cannot imagine what you want?

Quote:

Or the stupid parsing of my /etc/fstab into systemd units which does not work correctly with correct /etc/fstab setups, because it can only do what Poettering's limited mind thought can be done with it.

There was done much work recently. You can override some of fstab in the kernel cmdline and you can split out the whole fstab using xy.mount unit files. Because the last months there was a way back and forth, my guess the last word not spoken yet.
But if a local admin gets more powers don't expect it to get simplyfied then _________________fun2gen2

whoa, so much goes on while one sleeps . I will mark the post back to active for you guys. Let me know when you want it closed (solved) again_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.

It should be very easy to split out a systemdlessjournalreader application to just read the journals.

I must write my own program to read the journal! Of course changing it with every time to the non-stable format Poettering is using! And you are calling journald "ready"??

Quote:

For me the old Syslog is NOT ready, because it an overwhelming bunch of unstructered bits.

You can save the log in any format which you like, even using a database if you prefer. If journald would be written in a sane way and not "greatly vertically integrated" into systemd you could even use journald for it everywhere. But as easy as you can split out a journreader application you can as easy use journald as a backend also with saner init systems. Essentially, in both cases you just have to work against the broken "design" principles of systemd.

Quote:

Every time I needed some special bits of information this was hard work to find.

Oh yeah? Give a couple of real (non-theoretical) examples where you really needed it!
On the other hand, I typically use the logs to look for problems I had; if these problems are related with startup and the correct daemons are nor runnig, I cannot do this with journald: I first must be able to boot up with systemd - and nothing else - only to analyze in the logs what caused the problems.

Yes, since you can run arbitrary code you can write workarounds to avoid the broken "design" principles of systemd.

Quote:

Exactly what you demand? Also without that new Gentoo addition you are able to start your script in a unit service file.

I did not say that workarounds are not posssible: Essentially you can work around the problems by essentially using the systemd framework to run a sane init system. Of course, it is much more inconvenient, since instead of one script you have to create the script and a systemd unit for most services. Again, this is working against the broken "design" principles of systemd.

Quote:

Yes! Openrc is exactly that: Half the way to systemd!

Wih openrc I can do declarative style and scripts, just as I like. With systemd I can only do declarative style and have to care about scripts myself when (not if) I need. So I would say quite the opposite that systemd is at most half of openrc.

Quote:

Quiet a bunch of systemd features are already implemented by openrc.

Yes, systemd uses some common features of most other init systems. So what?

Quote:

In the Debian case of transition Openrc would have provided some common ground with their bsd-kernels on the way to systemd.

Every sane init-system would work with every kernel; you should just follow the unix philosophy of keeping everything to the appropriate tool and not do the "great vertical integration" of all sort of complettely unrelated thing in big bulk of unmaintainable code and interconnections. This the main reason why you can wait for the vertical integration experiment (and systemd as an essential part of it) to fail spectacularly, as already proven previously with the hal experiement which was the same on a smaller scale.

Quote:

If "declarative style - it is not used often" by openrc: This points out the development of Openrc was far too slooow!

It proves the most things cannot be done in declarative style. Essentially, the only thing which can be done in a declarative style in a sane way is starting daemons - which is the only thing Poettering obviously thought about - actually, this is apparently the only thing Poettering knows at all. An init system needs much more tasks which you all have to workaround in systemd: Essentially you (as the user) are supposed to write an init-system based on the insufficient systemd framework. Since you can execute arbitrary code this is possible, but you cannot call systemd an init-system. It is a daemon starter system, and nothing else - but of course "vertically integrating" technically unnecessary all sort of other stuff (journald, udev, dbus, polictykit,...) to force everybody to use it.

Quote:

There was done much work recently. You can override some of fstab in the kernel cmdline

So slowly some further hacks are introduced which perhaps after some years are finally able to do everything what "mount -a" was able to do since the beginning of unix. Because why use the existing "mount" if you can reinvent the wheel and force everybody to use "your" new wheel with edges?
I would not mind if somebody writes an alternative implementation of "mount": What I do mind is the "great vertical integration" and forcing everybody to use it!
You mentioned as a positive point of systemd that it is easy to disable services you do not want. It is exactly te most negative point that - in contrast to every other init system you cannot do this with systemd - unless you fork systemd and modify it correspondiingly of course.
But this forking is practically impossible since it means that you have to for also udev, journald, and moreover, dbus, polycikit, and practically all of gnome if you want to use it: This is the real reason for the "great vertical integration": That nobody without enormous resources is able to fork it so that practically redhat alone will keep forever the full control over the code which was originally written by volunteers. It is a pity that you do not see the real interest behind the artificially invented technical reasons.
Another less political reason why this vertical integration thing is horrible are security considerations. Practically, it is not possible to have a secure "vertically integrated" system - it is just a huge hack which "just works" (if you are lucky) but nobody can really overview.

1. "not ready" - changing format of the journal, missing bits
This just is a matter of time
If you observe systemd developers you can see them constantly breaking things and reverse. Often they are trying multiple ways to solve a problem they are working on. And I can point you to many instances in the man pages of systemd releases, where they decided consecutively the opposite way around. Systemd is one of the most active projects in the world of open source. If you compare with kernel.org and ignore the drivers there and the filesystems it might be about the same amount of activity. Systemd surely is "not ready" - see their ever growing TODO file. But it is ready to use for me for a while.

2. "not every kernel"
Makes a strong argument in favour of Systemd: Why shouldn't I use a Bsd distribution otherwise ? Bsd distributions are known to be better integrated and have the better documentation. But the Linux kernel has advanced features waiting to be exploited!

3. A "declarative" language is too simple
For me, this your argument is the most interesting! Sure, Systemd at some points works around by implementing things hardwired. And this intrinsingly working is in effect obscure to the user.

You can see a general trend in the software world to implement domain specific languages around special problems. Just like a specialist in the real world has its own language a normal person doesn't understand.

To build a new language is a task of defining concepts. If these new terms are unclear or overlapping things will go wrong! And if there are missing important terms the area of the obscure will grow. At this point the "broken by design" can happen. Every time I see their "TODO" growing again, I think to myself: Will Systemd developers betray their concepts to just make this new feature happen?

Years ago I studied Debians sysv scripts for hours to get the glimpse what happens at boot. Now it is seconds to look at a unit service file. I strongly hope this "declarative" style be kept a principle. By the way this makes "every thing is a file" possible to the extent to file every statement separately (customization of units).

In the long run we'll see an ever growing complexity, which has an exponential outlook once you try something more than what we can now think of. There surely are groups out there already trying to utilize this "Lego" feature for the yet unseen. (Just last week one of them filed a bug about performance issues using thousands of units.)

If this new "language" fits all needs is yet to be seen:
Expect forks if not! Because:

4. "vertical integration"
is more of a simplification at this point. Surely this obscures things for us as normal users as we both are! But the contrary the case is for a developer - otherwise Systemd couldn't be the project having ever more developers contributing! And for me as a normal user this vertical integration opens far more things than it does obscure: Because it is build to work with all its parts together I don't have to be the specialist of all sub parts to configure them manually.

5. Redhat conspires
to implement a vertical integrated system, which by design is insecure? Come on ..._________________fun2gen2

1. "not ready" - changing format of the journal, missing bits. This just is a matter of time

You are the one who claimed that all well-developed syslog-tools are not ready, in contrast to journald. I showed you that exactly the opposite is true. Good existing software was dumped for an unready nonfinished and - what is most important - conceptionally not thought through poor substitute.

Quote:

If you observe systemd developers you can see them constantly breaking things and reverse

Which is a proof that the concept is bad. They bumble around to make the bad concept at least halfway running.

Quote:

2. "not every kernel"
Makes a strong argument in favour of Systemd: Why shouldn't I use a Bsd distribution otherwise ?

Yes, why shouldn't I? Wouldn't this be natural for an init-system which brags to be the "new standard for an init-system"? How stupid is it if the init system forces me to use a particular kernel. What was your point, why is this a great advantage of the great standard init system to support only one very particular setting?

Quote:

But the Linux kernel has advanced features waiting to be exploited!

Yes, but not by the init-system. There are very few features which might be (optionally!) included into the init-system like cgroups. And if I do not want these features, I can easily mask them in a natural init system. You were the one who was claiming that systemd makes it so easy to mask services which you do not want.

Quote:

3. A "declarative" language is too simple
For me, this your argument is the most interesting! Sure, Systemd at some points works around by implementing things hardwired. And this intrinsingly working is in effect obscure to the user.

It is not obscured to the user, the user cannot mask or modify these things in the way he wants (except by forking systemd, as already mentioned). Making essential parts of the system non-configurable is a horribly broken concept.

Quote:

You can see a general trend in the software world to implement domain specific languages around special problems.

Specific languages are fine. Condition is that they are well thought-through. systemd isn't.

Quote:

To build a new language is a task of defining concepts. If these new terms are unclear or overlapping things will go wrong! And if there are missing important terms the area of the obscure will grow. At this point the "broken by design" can happen.

This did happen with systemd from the very beginning: I had explained you this with many reasons in previous discussions, but you didn't believe me. Now the shortcomings become obvious more and more to everybody.

Quote:

Years ago I studied Debians sysv scripts for hours to get the glimpse what happens at boot. Now it is seconds to look at a unit service file. I strongly hope this "declarative" style be kept a principle. By the way this makes "every thing is a file" possible to the extent to file every statement separately (customization of units).

And you really think going through hundreds of files and their content and manually remembering their implicit dependencies and rules is more simple than looking at 100 ordered lines in a file? I see only an enormous complcation of the setup instead of a simplification.

Quote:

In the long run we'll see an ever growing complexity, which has an exponential outlook once you try something more than what we can now think of.

Yes exactly, this is what you get: Much more complexity and obscurity instead of a well-structured initialization. So it seems we have the same opinion in this point, only that you seem to believe this is an advantage.

Quote:

4. "vertical integration"
is more of a simplification at this point. Surely this obscures things for us as normal users as we both are! But the contrary the case is for a developer [...]

It should be simple for the administrator - this is the first thing which counts for an init system.

Quote:

Because it is build to work with all its parts together I don't have to be the specialist of all sub parts to configure them manually.

Quite the opposite is true. Previously, e.g. mount did its one job reliable, and /etc/fstab had a reliable meaing. Now /etc/fstab is parsed by an accidental tool with a more or less heuristic interpretation which if you have good luck produces some .mount and .automount units which - also if you have good luck - do effectively rather the same what the single and clear command "mount -a" did previously. Of course only indirectly by sending your data to dbus and policykit and what else.

Quote:

5. Redhat conspires
to implement a vertical integrated system, which by design is insecure? Come on ...

You are mixing two things up.
The reasons for Redhat are of course only financial, and for them it is a very convenient way to pay some developers and thus get a quasi-monopole on previously free software. This has nothing to do with conspiracy theory, you just have to open your eyes to see what they are doing and why. It is completely normal behaviour for a company, but unfortunately rather harmful to the previously free software.
The other thing - completely independent of redhat intentions - is that "vertical integration" is insecure by design. To understand this, common sense is completely enough, but if you have doubts I can provide you already some particular problems like here. This is only some in a presumably neverending history of severe security bugs caused by vertical integration. Like web-browser will never be reasonably safe concerning execution of arbitrary code you will never be save with vertical integration from privilege escalation bugs. Both together make security of linux desktop systems a joke, and the latter should prevent any sane adminstrator from ever installing a system whose security can be broken by attacks over dbus or its protocols (like systemd or policykit) - there are too many ways thinkable to exploit such things, certainly more ways than the developers (even less the administrators of the system) can ever think of.

Your assumption of Systemd to be just another init system is plain wrong. It is all about "vertical integration".

Redhat needs a tool for their customers to blame their many admins. Therefore they are interested in journald.
You claim everything essential needs to be configurable. Not in this case of "vertical integration"! Your tries to manipulate time in favor of msWindows was incompatible with Systemds intention to comfort the main sponsor Redhat.

Your claim a new language domain has to be fully "thought-trough" is denouncing the opensource development model (open bazaar). I hope you are wrong. Although the broken "declarative" concept of "net" of Openrc was my motivation to get my system setup using Systemd a year ago: Despite having had a much longer time of existence the Openrc developers got it right just then.

Because "vertical integration" is potentially broken everywhere (but needed everywhere), it is important for developers to get a solid framework they can build upon. This is why Gnome decided in favor of Systemd. No Redhat intentions there ...

At last: Your anger about fstab handling is correct though. And you may have encountered real bugs there ...

@mv, following a disproved conspiration theory
- Redhat hires the dumb guy
- to dominate opensource
- to put their customers in jeopardy
- by needlessly vertical integrating their systems
gets you suprised on and on._________________fun2gen2

I am afraid the discussion leads to nothing, and I am somewhat busy now in real life. Just one final point

Quote:

Although the broken "declarative" concept of "net" of Openrc

At least openrc does something concerning net. systemd, in contrast, has no support for "net" at all: It just relies that the user establishes the connection completely manually by writing his own units or by using networkmanager. There is the user-provided "netctl", but this is also very poor, espcially compared to what openrc was able to do. So this is another basic functionality of an init-system which is just missing in systemd.
(E.g. I want to have a "local" net and through the same interface use pppoe or run dhcpcd - I have to do all this completely through my own scripts without getting the slightest support from systemd or netctl [and I heard that also networkmanager is not able to run a local and external net through the same interface, although I would not install networkmanager anyway due to its hard dependency on polkit]. Such a basic functionality missing is really a big disadvantage of systemd).

The discussion was certainly enlightening, not the least the statement by ulenrich

Quote:

for us as normal users as we both are!

... well, it takes me to a comment I recently read while searching for answers on how to tweak systemd from someone who was answering a post on the Arch linux forum, quite politely I should add, which to paraphrase went something like this

Quote:

"if you don't know how to maintain your system maybe you should consider installing Ubuntu instead"

seeing what is considered a "normal user" in this community, I think the Arch linux statement applies to me, and before someone tells me the same, I will bid you all farewell and thank you all for the patience you've shown. If ever I learn enough about Linux and can provide some useful input to the community, I will return

Best to all_________________Whatever is well said by another, is mine.
I don't consider myself bald, I'm just taller than my hair.