Ł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
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
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.
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
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
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
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
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
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
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
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.
> 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
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
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
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
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
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
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, 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
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
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 '@':
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
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
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
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
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
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 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
> 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
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.
** 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
** 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
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
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
** 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
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
$
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
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
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
Server Team, which is subscribed to openldap in 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
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
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 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
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
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
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:
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:
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
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
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.
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
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.
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.
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:
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
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
** 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,
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
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
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 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
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#
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'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
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
** 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
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
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 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
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
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
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
1 - 100 of 116 matches
Mail list logo
