I am getting the same problem here, but using the open-iscsi initiator
(which - of course - depends on the network being initialized):
Found ordering cycle on sysinit.target/start
[3.657825] systemd[1]: Found dependency on open-iscsi.service/start
[3.657827] systemd[1]: Found dependency
So, is this a problem of the 4.0 kernel itself or the kernel
configuration?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1429098
Title:
systemd[1]: ureadahead.service failed.
To manage
In my case, I see the following:
ureadahead[275]: ureadahead: Error while tracing: No such device
systemd[1]: Stopped Read required files in advance.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just wanted to add my findings to this as I was also curious to get
user/group mapping to work without the need of a Kerberos server.
However, what I saw especially in comments and documentation from
upstream is that this was never designed to work that way. Instead, the
idmapper only works in
Ah, OK.
Thank you for pointing me into the right directions and sorry for not
looking into the latest release.
As I have some LTS clients I will apply the configuration file change
there.
Again, thank you for your time! :-)
--
You received this bug notification because you are a member of
Public bug reported:
I want to configure sm-notify to use a pre-configured port (at least)
for communication, so that I can open up my iptables rules specifically.
In the current situation, the upstart job for statd just calls exec sm-
notify without providing any environment variables for
I would advocate for the following change:
1.) Add a new option like SMNOTIFY_OPTS to /etc/default/nfs-common
2.) Modify /etc/init/statd.conf to do exec sm-notify $SMNOTIFY_OPTS instead
Then, I could set SMNOTIFY_OPTS=-p 1234 to have a well-known port on
the clients.
--
You received this bug
