I can confirm the issue still occurring in 12.04.
openssh-client and openssh-server version 1:5.9p1-5ubuntu1
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/592434
Title:
ssh -X
For me workaround given in comment #8 in bug 525154 worked on four
systems, but on the fifth it was not enough, and I had to combine it
with #15 from this bug report. I have to admit that number of problems
caused by Upstart is astoundingly high, and they crop up unexpectedly in
a random fashion.
On yet another machine autofs would not start correctly neither with the
workaround from comment #15, nor without it. My efforts to convince
Upstart to run startup scripts in a correct sequence ended in an utter
failure. What I did instead is to modify /etc/init/autofs.conf so that
Upstart doesn't
Further investigation revealed that in my case autofs was not racing
with statd, but rather with nis (client daemon): bug 569757 and bug
570513. The workaround #15 appeared to work in some cases, because it
introduced a small delay into autofs init script, which gave time for
the nis daemon to
On my mail server postfix and dovecot depend on nis. Currently this
particular dependency is handled properly, because all three daemons are
started by means of /etc/rc?.d in the correct order. Please correct me
if I am wrong, but I worry that the solution suggested by Clint Byrum in
#18 might
I am also experiencing this problem on Ubuntu 10.04, openssh-server
1:5.3p1-3ubuntu4, as well as on Ubuntu 9.10. I would like to clarify
that the problem appears to lie within the server, not the client. My
client is running CentOS 5.5 and the problem occurs when connecting to
Ubuntu servers, but
I am also experiencing this problem on Ubuntu 10.04, openssh-server
1:5.3p1-3ubuntu4, as well as on Ubuntu 9.10. I would like to clarify
that the problem appears to lie within the server, not the client. My
client is running CentOS 5.5 and the problem occurs when connecting to
Ubuntu servers, but
For me workaround given in comment #8 in bug 525154 worked on four
systems, but on the fifth it was not enough, and I had to combine it
with #15 from this bug report. I have to admit that number of problems
caused by Upstart is astoundingly high, and they crop up unexpectedly in
a random fashion.
For those for whom workarounds in comments #8 and #13 do not work and
who use autofs, there is a separate Upstart-induced problem related to
statd: it races not only with mountall, but also with autofs. Bug 573919
has more information. Autofs users should also see bug 579858 if they
wish to have
Further investigation revealed that in my case autofs was not racing
with statd, but rather with nis (client daemon): bug 569757 and bug
570513. The workaround #15 appeared to work in some cases, because it
introduced a small delay into autofs init script, which gave time for
the nis daemon to
On my mail server postfix and dovecot depend on nis. Currently this
particular dependency is handled properly, because all three daemons are
started by means of /etc/rc?.d in the correct order. Please correct me
if I am wrong, but I worry that the solution suggested by Clint Byrum in
#18 might
The workaround provided in the previous comment works splendidly.
Unfortunately every update to ia32-libs overwrites libpam.so.0.81.6 with
the original unpatched version. While the bug is waiting to be fixed,
would it be possible, as a temporary workaround, to rename libpam.so in
the ia32-libs
On yet another machine autofs would not start correctly neither with the
workaround from comment #15, nor without it. My efforts to convince
Upstart to run startup scripts in a correct sequence ended in an utter
failure. What I did instead is to modify /etc/init/autofs.conf so that
Upstart doesn't
I can confirm the issue still occurring in 12.04.
openssh-client and openssh-server version 1:5.9p1-5ubuntu1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/592434
Title:
ssh -X user@machine hangs
John, can you provide the output of the following command:
dmesg | egrep DMI|ACPI
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1158746
Title:
fails to suspend
To manage notifications about this
John, please disregard my request; I did not notice that you included
your dmesg file. I have recently found a kernel regression that affects
ACPI on some older machines and might give symptoms similar to yours.
However, looking at your dmesg I do not see the output that this
regression would
Public bug reported:
This report concerns changes introduced to file
linux-3.2/drivers/firmware/dmi_scan.c as a result of backport of patches
as described in bug #1117693, specifically:
drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it
exists. This modification has been introduced
In response to the above automatic message:
Invoking apport-collect yields the following message: ERROR: connecting to
Launchpad failed: [Errno 110] Connection timed out. This is likely due to the
affected machine being behind the corporate firewall. None of the usual ways of
passing proxy
I tested the latest kernel on the affected machine and can confirm that
the bug is fixed. The affected machine correctly reads legacy DMI
information and ACPI works without acpi=force boot parameter.
** Changed in: linux (Ubuntu)
Status: Incomplete = Fix Released
--
You received this bug
I guess this has gone off the radar, having been fixed in Saucy - so
here's a reminder:
This vulnerability is still present in Precise, current LTS release. As
that release would be most often used in servers where this
vulnerability is relevant, may I kindly ask that some attention is paid
to
I have noticed the same problem on Ubuntu 12.04 LTS (Precise). In that
release, the package is named python-software-properties. It is not
clear to me why there is a hard dependency here. When forced to
install without unattended-upgrades, add-apt-repository works without a
hitch. Perhaps a better
Thank you very much for an explanation. I understand that thus is not a
trivial fix, but I would nevertheless ask you to reconsider your
position. As we can see in this bug report, many users consider this
issue important and the workaround problematic. For some users this
issue alone is a show
The workaround is to enter the interface name (for example, br0)
manually. Due to another bug in virt-manager, this is only possible when
running virt-manager locally on the kvm host. If virt-manager connects
to the remote kvm host, the edit box is not accessible and the only way
to select the
May I kindly ask why this bug has been fixed in Quantal, but marked as
won't fix for Precise - current LTS release that will most likely be
used as VM host OS for the next couple of years?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is interesting:
[ 4650.205313] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint called with
disabled ep f3133600
[ 4650.205329] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint called with
disabled ep f313362c
I am getting the same errors with most USB 3.0 devices that I tried. These
errors
Christopher, due to the nature of this bug, I cannot perform the reverse
bisect. I explained it already in comment #8. Just to be clearer: the
regression has not been fixed upstream. There is no 3.x kernel branch
which would contain the regression and the subsequent fix. The
regression either is
I think that I may have found the bug, and since the newest upstream kernel
3.16.0-rc3 has the affected code essentially unmodified, I contacted the
maintainer of the XHCI driver and the author of the problematic commit. I also
asked for help on linux-usb kernel mailing list:
Public bug reported:
This bug report is a follow-up to bug 1328984, describing a successful
attempt to replicate that bug on another hardware. As advised, I am
opening a new bug to avoid mixing information related to two hardware
configurations.
Conditions triggering this bug:
As the original
** Attachment added: Result of apport-cli
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+attachment/4132664/+files/bug1330530.apport
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
A few notes regarding the contents of the apport file submitted above:
1. Times logged in syslog are incorrect and do not reflect the 18-minute delay.
It appears that rsyslog is started after the delay and logs its startup time,
not the real time of events.
2. Nouveau segfaults are not related
I have created a new bug report describing this problem replicated on another
hardware: bug 1330530
As that is a test machine entirely devoted to this issue, I will test the
upstream kernel on it and post the results in bug 1330530.
Regarding testing of the upstream kernel on PowerEdge
Following the advice given for bug 1328984, I have tested the latest
upstream kernel, and I am happy to report that the problem did not occur
(neither during boot or hotplug).
Kernel tested: 3.16.0-031600rc1-generic x86_64
URL: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc1-utopic/
I have tested the mainline kernel 3.2.60, and was able to reproduce the
problem, with exactly the same symptoms as with kernel 3.2.0-64 (3.2.59).
Kernel URL: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.60-precise/
I also tested Western Digital My Passport 2TB USB 3.0 drive (Part#
I have tested kernels 3.16.0-031600rc1-generic and 3.2.60-030260-generic. On
the former, the problem does not appear, on the latter, the bug is replicated
with similar symptoms as on 3.2.0-64. I used a flash drive with a vanilla
Ubuntu 12.04 desktop install for all tests. To summarize kernels
** Tags removed: kernel-fixed-upstream-3.16
** Tags added: kernel-fixed-upstream-3.16-rc1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1328984
Title:
[Dell PowerEdge R510] Regression: Kernel
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1328984
Title:
[Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with
tl;dr: This bug report is a duplicate of bug 1330530.
I am going to focus my efforts on bug 1330530, and I do not intend to do
any work on this bug report until bug 1330530 is resolved. This is
because doing the same work twice is not a good use of time and effort
of anybody involved. Please do
I have tested 28 mainline kernels from 9 branches currently maintained
(3.2, 3.4, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15, 3.16), focusing on those
that were built around the time the problematic commit was introduced
(May-June 2014). The bug appears to affect the 3.2 branch exclusively.
Thus I will
I bisected commits between Ubuntu-3.2.0-63.95 and Ubuntu-3.2.0-64.97,
and arrived at a specific xhci-related commit. However, manual
modification of the relevant file to revert the effects of this commit
yielded a kernel that still suffered from a regression. Further
complicating the matter is the
After testing this thoroughly, I am confident to say that the regression is
caused by commit usb: xhci: Prefer endpoint context dequeue pointer over
stopped_trb. In ubuntu-precise git repository this is commit
f04e4b02bce3a0ce19f9673bbefde9b8c624c00a.
However, an equivalent commit is part of
** Tags removed: needs-reverse-bisect
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1330530
Title:
[Dell Vostro 430] Regression:
Roman, compared to bugs 1330530 and 1328984, you have a similar USB 3.0
controller: ASM1042 (this bug) vs ASM1042A (other bugs). So this may be
the same issue. Would you be able to test the regression with other USB
devices?
--
You received this bug notification because you are a member of
I'm trying to find similarities between this bug and the bugs I reported.
Speaking about the devices mentioned above, but only those that cause problems:
1. Is any a USB 3.0 device?
2. If you boot with any of the problematic devices plugged in, do you
experience boot problems of any kind (stuck,
The patch has been somewhat reworked and added to the upstream mainline kernel
3.17-rc3, and to the 3.16-stable tree.
https://lkml.org/lkml/2014/8/29/386
http://www.spinics.net/lists/stable/msg59724.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The patch has been added to the upstream mainline kernel 3.17-rc3, and
to the 3.16-stable tree. Please see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/comments/16
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
One more thing, the patch as included in upstream mainline kernel (3.17)
will fail to build in the 3.2 branch, because it removes function
find_trb_seg, which is still needed in the 3.2 kernel. This function
should be left in place when patch is applied to 3.2 kernel. Further
details available
Joseph, thank you for pointing my attention to this bug. On my hardware
(bug 1330530) the problem is not reproducible with kernel 3.13.y, so
unfortunately I can neither confirm nor deny whether your test kernel
fixes it. However, I would very much like to see the patch being
backported to 3.2.y.
** Project changed: software-center = linux-meta (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1328984
Title:
Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
To manage
I am unable to run the apport-collect command for two reasons:
1. The bug in question renders the machine unbootable. To boot the
machine and run apport-collect, it is necessary to change either the
software or hardware configuration. This would create an environment in
which bug is not
Thank you for the information. I collected apport data, but I am
currently unable to submit it, as the procedure outlined on the linked
page still requires usage of tools that do not work with a proxy. Unless
I run into more apport-related problems, I will be able to submit it
later today or
I am unable to submit apport-collected data due to what appears to be
numerous bugs in apport tools:
1. Submitting data directly from the affected machine is not possible
due to apport not being able to connect through a proxy.
2. Following instructions on referenced page to submit previously
I'm attaching the file generated by command:
apport-cli -f -p linux --save bug1328984.apport
This was done with the machine running 12.04 Server with kernel 3.2.0-63.
May I ask for the reply to my question about the results of testing the
problem on a different hardware? (The regression has been
Julius Werner, the author of the commit in question, has found the problem and
created a patch. The problem is in the place that I identified, but specific
regression-triggering details are different that I originally thought. The
patch is available here:
https://lkml.org/lkml/2014/7/8/571
I
Problem has been identified and patch created. Please see the following link
for details:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/comments/15
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
For a system with a separate /var partition, the workaround from year 2010
appears to work:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154/comments/8
For the Ubuntu 14.04 this workaround translates to:
--- /etc/init/statd.conf.ORIG 2013-09-11 16:46:50.0 -0500
+++
For a similar bug affecting Ubuntu 14.04, please see bug #1371564
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/525154
Title:
mountall for /var or other nfs mount races with rpc.statd
To manage
The same problem exists on Ubuntu 14.04 LTS (Trusty). In this case, add-
apt-repository is in package software-properties-common, which depends
on python3-software-properties, which depends (needlessly) on
unattended-upgrades.
--
You received this bug notification because you are a member of
It appears that GnuTLS initialization is failing with an error, perhaps because
there is something in your slapd configuration that newer version of GnuTLS (in
xenial) does not like.
Can you post your slapd config? Please redact it so that it does not contain
any host names, IP addresses, user
Public bug reported:
May I ask that you backport an upstream patch that resolves the issue of
use-after-free in libldap that interferes with syncrepl, causing
failures and segfaults.
OpenLDAP commit: 283f3ae1713df449cc170965b311b19157f7b7ea
Link:
Public bug reported:
May I ask that you backport an upstream patch that resolves the issue of
use-after-free in libldap that interferes with syncrepl, causing
failures and segfaults.
OpenLDAP commit: 283f3ae1713df449cc170965b311b19157f7b7ea
Link:
Perhaps the issue is that your certificates have too short RSA keys. In
GnuTLS SECURE256 requires at least 3072-bit public key. Unfortunately,
this is not clearly documented.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Perhaps the issue is that your certificates have too short RSA keys. In
GnuTLS SECURE256 requires at least 3072-bit public key. Unfortunately,
this is not clearly documented.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in
Public bug reported:
After phpldapadmin package dependencies have been switched to php7.0
(LP: #1564121), a routine package update (apt-get update; apt-get
autoremove) causes phpldapadmin's web interface to stop working and
display a page indicating that php is not enabled.
Workaround: a2enmod
Public bug reported:
After phpldapadmin package dependencies have been switched to php7.0
(LP: #1564121), a routine package update (apt-get update; apt-get
autoremove) causes phpldapadmin's web interface to show a warning about
missing XML support.
Workaround: apt-get install php7.0-xml
$
This update to package phpldapadmin causes two problems. As this bug report has
been closed, I reported them as new bugs:
Bug 1566481 phpldapadmin missing dependency php7.0-xml
Bug 1566491 phpldapadmin fails to enable php7.0 module
If you are affected by one or both of these bugs, please post
** Description changed:
- After phpldapadmin package dependencies have been switched to php7.0 (LP
- #1564121), a routine package update (apt-get update; apt-get autoremove)
- causes phpldapadmin's web interface to show a warning about missing XML
- support.
+ After phpldapadmin package
I reported the bug to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820244
** Bug watch added: Debian Bug tracker #820244
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820244
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Patch added: "autofs.conf.diff"
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+attachment/4625148/+files/autofs.conf.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1566508
Public bug reported:
This report concerns a configuration where autofs and sssd are both
installed, sssd is configured to provide automount maps, and
nsswitch.conf directs autofs to use sssd. In such a configuration autofs
often fails on boot complaining "no mounts in table". This is because
> I believe that is all tied together. php7.0 and php5 conflict with one
another in apache's configuration.
I see that the root of the problem was that apt did not remove php5
while installing php7.0.
> Right, but you're running a not-yet-released Ubuntu :)
Yes, of course. I've been running it
** Description changed:
After phpldapadmin package dependencies have been switched to php7.0
- (LP: #1564121), a routine package update (apt-get update; apt-get
+ (LP: #1564121), a routine package update (apt-get upgrade; apt-get
autoremove) causes phpldapadmin's web interface to show a
** Description changed:
After phpldapadmin package dependencies have been switched to php7.0
- (LP: #1564121), a routine package update (apt-get update; apt-get
+ (LP: #1564121), a routine package update (apt-get upgrade; apt-get
autoremove) causes phpldapadmin's web interface to stop working
Thank you for a quick response. Yes, I can find "ERROR: php5 module
already enabled, not enabling PHP 7.0" in /var/log/apt/term.log. Not
sure if this is relevant, but before I ran "a2enmod php7.0", directory
/etc/apache2/mods-enabled contained a link php7.0.load, but did not
contain php7.0.conf.
Patch created by OpenLDAP team applies cleanly to openldap 2.4.41+dfsg-
1ubuntu2 (wily).
** Patch added: "tls_g.patch"
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+attachment/4607004/+files/tls_g.patch
--
You received this bug notification because you are a member of
Patch created by OpenLDAP team applies cleanly to openldap 2.4.41+dfsg-
1ubuntu2 (wily).
** Patch added: "tls_g.patch"
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+attachment/4607004/+files/tls_g.patch
--
You received this bug notification because you are a member of
I created a PPA with patched deb packages, available at:
https://launchpad.net/~maciej-puzio/+archive/ubuntu/openldap
Currently it contains openldap-2.4.41 source package with the above patch
applied, as well as binary debs built from it, for amd64 and i386. These
packages are for Ubuntu 15.10
I created a PPA with patched deb packages, available at:
https://launchpad.net/~maciej-puzio/+archive/ubuntu/openldap
Currently it contains openldap-2.4.41 source package with the above patch
applied, as well as binary debs built from it, for amd64 and i386. These
packages are for Ubuntu 15.10
** Tags added: patch-accepted-upstream
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557248
Title:
OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
To manage
** Tags added: patch-accepted-upstream
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1557248
Title:
OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
To manage notifications about
I have just found that Howard Chu of OpenLDAP team had already uploaded this
patch to Launchpad VCS:
http://bazaar.launchpad.net/~vcs-imports/openldap/master/revision/20757
Hopefully we will have the package released soon.
--
You received this bug notification because you are a member of Ubuntu
I have just found that Howard Chu of OpenLDAP team had already uploaded this
patch to Launchpad VCS:
http://bazaar.launchpad.net/~vcs-imports/openldap/master/revision/20757
Hopefully we will have the package released soon.
--
You received this bug notification because you are a member of Ubuntu
A bug has been found in libldap code that interferes with the value of
"require cert" option. It affects libldap built with GnuTLS, as is done
in packages supplied by Ubuntu and Debian. The bug causes the value to
be read from previously freed memory, often resulting in incorrect or
random value
A bug has been found in libldap code that interferes with the value of
"require cert" option. It affects libldap built with GnuTLS, as is done
in packages supplied by Ubuntu and Debian. The bug causes the value to
be read from previously freed memory, often resulting in incorrect or
random value
I created patched openldap packages for xenial, available on the same
PPA as above. I tested amd64 packages on xenial beta 2.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1557248
Title:
OpenLDAP:
I created a PPA with patched openldap packages for wily and xenial. If
you would like to test them, there is more information in bug 1557248.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1547927
I created patched openldap packages for xenial, available on the same
PPA as above. I tested amd64 packages on xenial beta 2.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557248
I created a PPA with patched openldap packages for wily and xenial. If
you would like to test them, there is more information in bug 1557248.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
Same problem with plain ext4 root partition. I have two systems
configured very similarly with 16.04, one has this problem and another
has not. But their hardware is different, so I'd make an educated guess
that this is a timing issue. Good thing is that it appears benign.
BTW, I get three
I can confirm that the following packages from xenial-proposed fix the bug:
slapd 2.4.42+dfsg-2ubuntu3.1
libldap-2.4-2 2.4.42+dfsg-2ubuntu3.1
ldap-utils 2.4.42+dfsg-2ubuntu3.1
I did not test the packages in wily-proposed. Setting the test
environment is not trivial, and I don't think it is
Due to the nature of this bug (referencing previously freed memory
leading to an undefined behavior), a reliable testing procedure is
difficult to create. This bug was originally found by looking for a
cause of syncrepl failures. The reproducibility of these failures was
about 50%, enough to make
Chris, thank you very much for preparing the packages for -proposed
repos. I started testing of xenial-proposed version, but tests are not
progressing quickly, due to issues that I described above. In addition I
have run into another problem, likely unrelated to this bug, which is
further
Victor, you are right saying that we are dealing with more than one bug
here. It appears to me that we have 3 or 4 separate bugs all conspiring
to prevent autofs from starting in the configuration as described above.
I think that the "setautomntent" error message is a symptom of a
different bug
In order to test whether the bug which is the subject of this bug report
(i.e. "no mounts in table", not "setautomntent") occurs in Xenial with
systemd, I created autofs.service as attached below. This way I could
dispense with /etc/init.d/autofs and directly control when autofs is
started. I can
Here is the autofs.service file mentioned above.
** Attachment added: "autofs.service"
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+attachment/4719398/+files/autofs.service
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Jakub, thanks for the information.
Launchpad mangles the URL that you posted in an attempt to hide email addresses
from public view, here it is in an equivalent form that does not include '@':
Jakub, the "setautomntent" message occurs at the same time when autofs
fails to mount shares on startup. So, while itself it is not a bug and
nobody here suggests that the message should be silenced, it is
nonetheless one of the symptoms of the problem, which is caused most
likely by a number of
I finally had a chance to test this issue in Ubuntu 16.04. In a setup
described as in the bug description above, autofs still won't start
correctly, and this is a result of the whole string of problems. Most of
them appear to be separate bugs, but I will list them here for
completeness:
1. ifup
This problem occurs because on Ubuntu 16.06 both sssd and autofs are started
too early, before network is up. This has been observed in setups with network
interfaces configured statically in /etc/network/interfaces (is that your setup
as well?) Sssd itself recovers from this condition
Public bug reported:
Package autofs in Ubuntu 16.04 includes SysV startup script
(/etc/init.d/autofs) and Upstart unit (/etc/init/autofs.conf), but does
not include systemd service file. As a result, systemd starts autofs as
part of its LSB (sysv) processing, which makes it difficult to ensure
I am also affected by this issue. In my case both network.target and
network-online.target are reached too early, which results in sssd and
autofs to start before network interfaces are up; autofs then fails to
obtain mount maps and does not attempt to retry; it is necessary to
restart autofs
1 - 100 of 116 matches
Mail list logo
