Łukasz, thank you very much for accepting the package into bionic-
proposed. I confirm that the updated binary package libqt5printsupport5
fixes the problem. I also updated other libqt5* packages available in
bionic-proposed, and did not notice any obvious regressions.
However, I would like to voi
I can confirm that the patch fixes the problem, i.e. Qt print dialog now
defaults to page size as set in System Settings Printers applet. To apply the
fix, it was enough to add the PPA repository, upgrade libqt5printsupport5
package, and then close and reopen applications that were affected by t
Public bug reported:
Please backport Qt patch 213677 to qtbase-opensource-src
https://codereview.qt-project.org/c/qt/qtbase/+/213677
In Qt5 applications, print dialog (Printer Properties) always defaults
to A4 paper size, even when Letter is set as a default in all system and
KDE preferences. Aft
I tested sssd-1.13.4-1ubuntu1.4 on xenial on a bare metal machine
equipped with Intel X550T, a network controller notorious for long and
somewhat random startup initialization time. I am happy to report that
autofs boot problems still occur, but at a much diminished rate. While
previously autofs wa
Here are the results on my tests of package sssd-1.13.4-1ubuntu1.3 on
Xenial.
As I noted in comment #20, this bug report involves two separate issues, both
contributing to failure of autofs to properly start on boot:
1. autofs starts before sssd.
2. autofs starts after sssd, but before sssd respo
I did brief testing of sssd-1.13.4-1ubuntu1.3 on Xenial. Autofs still
fails to properly start on boot, but I am not sure which of the numerous
issues described in this bug report contributes to the failure now. I
will do more testing after the weekend.
--
You received this bug notification becaus
Robie, thank you for your comment.
There is a number of bugs related to autofs and sssd present in Xenial. A
partial attempt to sort out this situation can be found in bug 1566508, comment
#20 (https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/comments/20 ).
However, this is compounded
I do not use Debian, but please feel free to file a bug report with
them. Regarding the autofs.service file attached above, please note that
it would benefit from inclusion of additional services in the After=
line (such as nslcd, slapd and NIS). The reason that I did not include
them is that their
Andrei, I'm glad that you found my workaround useful. I did not
experience problems that you describe (I did not test these issues on a
laptop), but I agree that they are relevant to this bug. If you could
subscribe to notifications about this bug, we would get more bug heat
points, and hopefully t
Victor, thanks a lot for the explanation. I apologize for not
volunteering to test your patch, but it fixes an issue (#2) that I am
unable to reproduce in Xenial. But I really appreciate your efforts.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscrib
Victor, would you be so kind to post a link to your patch, and also tell
us which of the numerous issues discussed in this bug report (comment
#20) are solved by the patch?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.l
> Is it a daft question to ask why it works for them and not you ?
This is a very good question. My take on it is as follows.
There are several issues here, and the majority are related to startup
configuration. Speaking of Ubuntu 16.04, the problem is that Ubuntu
first switched from SysV startup
Public bug reported:
Currently package zfsutils-linux contains systemd target file
/lib/systemd/system/zfs.target that specifies following dependencies:
Requires=zfs-mount.service
Requires=zfs-share.service
Wants=zed.service
zfs-share.service is not essential in setups where file sharing is not
Here is my attempt to sort out how many bugs are related to autofs
failing on boot.
This bug (1566508)
As noted earlier, these are actually two issues:
1. autofs starts before sssd.
2. autofs starts after sssd, but before sssd responders are up.
On Trusty, I observed #1 and #2, and on Xenial I ob
Public bug reported:
This problem is occurring on Ubuntu 16.04 system where autofs and sssd
are both installed, sssd is configured to provide automount maps, and
nsswitch.conf directs autofs to use sssd. In a situation when both sssd
and autofs start before network is up (which happens out-of-the-
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
tha
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 gracefull
Issues related to ifup and service files included in ifupdown package
are reported as bug 1588915.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1566508
Title:
autofs races with sssd on startup
To
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 manua
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 r
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 to
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 in
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 tha
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 '@':
https://lists.fedorahosted.org/archives/list/sssd-devel%40lists.fedorahosted.org/message/QKU5H4VUCIZ43LBJ
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 re
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 n
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 worthwh
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 obscuring
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 s
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 errors:
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 U
> 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 s
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.
O
** 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
** 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 warnin
** 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
T
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
autof
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 you
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 ph
** 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 dependenci
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
$ apt-ca
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
Titl
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: B
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
** 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 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
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 Ubun
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 be
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.
https://bugs
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:
http://www.openldap.org/devel/gitweb.cgi?p=openld
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 Ubun
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
+++ etc/i
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 not
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. i.
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 here
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.
https:/
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 subs
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.
https://bugs.launchpad.
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 te
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:
http://permalink.gm
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 no
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 co
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,
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 Ubuntu
** 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:
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 m
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
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 now
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 no
** 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
** 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 3.2.0-
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 te
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#
WDBY8L002
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/
uname
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 machines,
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 to
** 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.
https://bugs.launchpad.net/bugs/1
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 bug
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 r
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
cre
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 tomorr
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 reproducib
** 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 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 bette
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 thi
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 b
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 inf
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
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 cause
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
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 inte
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 whe
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 sto
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 Ubun
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 caus
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 star
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
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 th
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. I
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 n
1 - 100 of 101 matches
Mail list logo
