[Bug 1846821] Re: Qt print dialog has wrong default page size
Ł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 voice my differing opinion on the importance of this bug. While this is perhaps not a high-impact bug in the meaning that it does not impact system stability or security, it is nonetheless one of the "infuriating little bugs" that significantly degrade user experience. For the user who does not remember to dig into prefs to change paper size before every print job, the bug results in the necessity of printing everything twice, as the first copy (A4 on Letter) has top and bottom lines clipped and missing, rendering the printout unusable. This bug, coupled with similar ones and the general instability of KDE desktop, makes Kubuntu 18.04 unsuitable as a desktop OS for everyday use, in my opinion. Because of that I am very grateful that this bug is getting fixed. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846821 Title: Qt print dialog has wrong default page size To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1846821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846821] Re: Qt print dialog has wrong default page size
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 the bug. Thank you very much for your work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846821 Title: Qt print dialog has wrong default page size To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1846821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846821] [NEW] Qt print dialog has wrong default page size
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. After changing manually, Letter-size pages print correctly, but the setting does not stick. The issue also affects other print settings, e.g. margins, though the aforementioned patch does not deal with these. A similar issue regarding the duplex setting was reported as Launchpad bug 1776173, and subsequently fixed, but other print settings continue to cause problems. Behavior expected: Print dialog would default to Letter paper size, which is set in all available system and KDE preferences, and that was selected for previous prints. Behavior observed: Print dialog always defaults to A4, and page size needs to be changed manually before every print. Software versions: lsb_release: Ubuntu 18.04.3 LTS libqt5core5a: 5.9.5+dfsg-0ubuntu2.3 Kernel: 5.0.0-25-generic ** Affects: qtbase-opensource-src (Ubuntu) Importance: Undecided Status: New ** Tags: bionic ** Summary changed: - Qt print dialog does not remember page size + Qt print dialog has wrong default page size -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846821 Title: Qt print dialog has wrong default page size To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1846821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 was failing at nearly every boot, now I observed only one failure in 50 tries. I believe that this improvement comes from "autofs.service" being added to "Before" line in sssd.service file (a change introduced in sssd-1.13.4-1ubuntu1.4). When I removed this modification, autofs tended to start before sssd, and failed much more often with an error "setautomntent: lookup(sss): setautomntent: Connection refused". On the other hand, with the modification in place, the very occasional failures were accompanied with an error "setautomntent: lookup(sss): setautomntent: No such file or directory", which results from network interface coming online after sssd and autofs have already started. However, the topic of this bug is a race between sssd and autofs, and not the race between sssd and autofs on one side, and network initialization on the other (bug 1588915), even though effects are similar. Thus I would vote to consider this bug fixed. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 responders are up. On Trusty I observed both issues, and on Xenial only issue #1 (contrary to my previous comment #20, I did observe this issue in further tests). As I understand, the new version of the package deals with issue #2. Since I never experienced this issue on Xenial, despite numerous tests intended to reproduce it, and the issue #1 remains unfixed, I can only say that changes introduced in sssd-1.13.4-1ubuntu1.3 have no effect in the configuration that I used for my Xenial test system. However, I a weary from changing the tag to verification-failed, as a fix to "what ain't broke" is neither a success nor a failure. This does not mean that the fixes are not valid, and in fact I think they may have positive effect in Trusty. As I understand, the fixed package for Trusty has not yet been released. I did not test the package in Yakkety, as I do not use non-LTS Ubuntu versions. I would be grateful if Yakkety users could test the package. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614282] Re: autofs does not recover from failure to read maps on startup
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 by problems with network interface initialization on startup: bug 1588915, comment #12 (https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1588915/comments/12 ). Both of these bug reports deal with several issues that are difficult to untangle. Regarding the issue of missing autofs.service file, it a subject of bug 1614248. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614282 Title: autofs does not recover from failure to read maps on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614282/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614248] Re: Package autofs does not include autofs.service file
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 respective packages also lack systemd service files, similarly to package autofs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614248 Title: Package autofs does not include autofs.service file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614248] Re: Package autofs does not include autofs.service file
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 this would draw someone's attention. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614248 Title: Package autofs does not include autofs.service file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566508 Title: autofs races with sssd on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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.launchpad.net/bugs/1566508 Title: autofs races with sssd on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
> 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 to Upstart, and then (quite recently) to systemd. Switch to Upstart was difficult and there were many problems similar to this one, but before they were all ironed out, another switch to systemd occurred. The result is a total mess. As an example, systemd service unit is currently missing from autofs package, and so while for sssd the switch was from Upstart to systemd, for autofs it was actually Upstart -> SysV. And this is not the only issue. Ubuntu 14.04, on the other hand, was released before the Upstart -> systemd switch. Here the problem is that Upstart's event-driven model is fundamentally flawed, and unable to express startup dependencies in a general case (as opposed to installation-specific setup). This is the reason why Upstart-related problems were not entirely fixed before the switch to systemd: because they could not be fixed within Upstart framework. I have never used OpenSUSE, but I believe that it did not switch its init system to Upstart, but rather directly from SysV to systemd. And it did so much earlier than Ubuntu. Because of that it had a headstart and much less mess to clean up, having to deal with only one switch. No wonder then that its startup works better. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614789] [NEW] zfs.target should not require zfs-share.service
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 used, or when it is configured without the use of the zfs utility. The user may therefore choose to mask this service. However, doing so has an unexpected and confusing effect, preventing zfs from starting on boot at all. This is because zfs.target is the only zfs-related unit that is wanted by multi-user.target, and if one of its required services is masked, zfs.target is skipped, together with zfs-mount.service. A solution is to replace "Requires=zfs-share.service" with "Wants=zfs- share.service". Steps to reproduce: systemctl mask zfs-share.service reboot Expected results: Module zfs is loaded zfs-mount.service is active and ZFS filesystems are mounted ZFS filesystems are not shared Observed results: Module zfs is not loaded ZFS filesystems are not mounted zpool status produces an error: "The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them." $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy zfsutils-linux zfsutils-linux: Installed: 0.6.5.6-0ubuntu10 ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New ** Package changed: autofs (Ubuntu) => zfs-linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614789 Title: zfs.target should not require zfs-share.service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1614789/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 observed neither, while Victor Tapia reported only observing #2 on Xenial (comment #13). Regarding the apparent fix for #1 in Xenial, I believe that it is accidental, and the proper fix is subject of bug 1614248. Regarding #2 in Xenial, I can only say that I tried very hard to reproduce it, and I could not. In this bug we also discuss another issue that was not subject of the original bug report: 3. sssd trying to connect to its providers (e.g. LDAP) before network is ready. On Trusty, I observed it only very rarely, but in Xenial this issue occurred on every boot. Victor Tapia reports observing this problem on both Trusty and Xenial. I do not think that creating a new autofs or sssd bug for this issue would be a good idea, because this problem is not caused directly by autofs or sssd, but rather is a result of ifupdown bug 1588915 (at least this is so on Xenial). However this bug would be no reason of concern if autofs were able to recover from an initial map read failure. There are two issues here, both covered by bug 1614282: 4. autofs does not appear to read cached automount maps from sssd. 5. autofs does not mount shares even when it is finally able to read maps from sssd, after network is up and sssd has been able to receive maps from its provider (e.g. LDAP). Regarding #4, the problem may lie with sssd rather than autofs. I am not sure if this issue is related to problem mentioned by Jakub Hrozek in comment #9. However, Jakub's patch will fix #4 (possibly), but not #5; we also want autofs to mount shares, when possible, even when there were no maps in cache on startup. As to Victor's comment #3, I observed the problem with indirect maps. All maps, including the master map, come from the LDAP server, so perhaps it's the master map that is not updated automatically, rendering everything unusable. Unfortunately, my tests with sending HUP to automount daemon did not produce results as described in the manpage (yet another bug?). In any case, the logic that manpage describes as "change on the fly" should not apply to the situation when there is no master map whatsoever due to an earlier error (as is our case). Links to related bugs: Bug 1588915 ifup does not block for interface to be up with static addresses Bug 1614248 Package autofs does not include autofs.service file Bug 1614282 autofs does not recover from failure to read maps on startup Bug 1584818 autofs fails to read sss [duplicate, but difficult to say what of; most likely referring to issue #3] -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614282] [NEW] autofs does not recover from failure to read maps on startup
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-box because of bug 1588915), sssd is unable to obtain automount maps from the LDAP server, nor any other data, and serves information from its cache. Autofs does not appear to retrieve cached automount maps from sssd, which can be verified with automount -m not showing any maps. This is accompanied by an error in syslog: "setautomntent: lookup(sss): setautomntent: No such file or directory". It goes without saying that shares are not mounted either. When network is finally up, sssd is able to connect to the LDAP server, and autofs retrieves automount maps (automount -m now displays maps as expected). However autofs does not attempt to mount shares specified by these maps. Attempting to access these shares does not help; it is necessary to manually restart autofs service. Steps to reproduce: 1. Start the machine with network interfaces not configured (e.g. cables unplugged). 2. Verify that sssd works and serves data (e.g. getent passwd, etc). 3. Check that autofs does not see maps and has not mounted shares: automount -m, ls /shares/... (Possibly) expected result: autofs obtains cached maps and mounts shares as specified. 4. Plug network cable and configure the interface: ifup eth0 5. Verify that autofs now sees maps: automount -m 6. Check that shares specified in maps are still unmounted: ls /shares/... Expected result: shares will now be mounted. 7. Restart autofs: systemctl restart autofs 8. Verify that shares are now mounted. This is as expected, but step #7 shouldn't be necessary. $ lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $ apt-cache policy autofs sssd-ldap libpam-sss libnss-sss sssd-tools autofs: Installed: 5.1.1-1ubuntu3 sssd-ldap: Installed: 1.13.4-1ubuntu1 libpam-sss: Installed: 1.13.4-1ubuntu1 libnss-sss: Installed: 1.13.4-1ubuntu1 sssd-tools: Installed: 1.13.4-1ubuntu1 [Note: Package sssd is not installed, because it is a virtually empty package that pulls a numbed of unneeded dependencies.] ** Affects: autofs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614282 Title: autofs does not recover from failure to read maps on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614282/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1614248] [NEW] Package autofs does not include autofs.service file
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 that autofs is started after services that it requires for proper functioning. In particular, unit autogenerated by systemd-sysv-generator for autofs does not include dependency on sssd.service. It appears that on the installation that I tested, systemd starts LSB services well after sssd is started, so the issue does not cause any visible problems, but this startup sequence is accidental. Given the number of other issues related to autofs startup in Xenial, requiring users to get their hands dirty just to have autofs run properly after boot, I think it would be advantageous to fix this simple oversight. (See bug 1566508, bug 1584818, bug 1588915) I attach an example service file for autofs that fixes this problem. In addition to sssd.service, this unit could also list nslcd.service, slapd.service and ypbind.service/nis.service in its After= line. However, these service files are also missing from their respective packages, and I am not even sure how NIS client service file would be called. $lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 $apt-cache policy autofs autofs: Installed: 5.1.1-1ubuntu3 Candidate: 5.1.1-1ubuntu3 ** Affects: autofs (Ubuntu) Importance: Undecided Status: New ** Attachment added: "autofs.service" https://bugs.launchpad.net/bugs/1614248/+attachment/4722917/+files/autofs.service -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614248 Title: Package autofs does not include autofs.service file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584818] Re: autofs fails to read sss
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 gracefully, and eventually connects to the LDAP server when network comes up. However autofs gives up after first failed attempt, and must be restarted manually to to properly mount NFS shares. Please see discussions for bug 1566508 and bug 1588915 (these are separate issues related to system startup that affect autofs, among other things). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584818 Title: autofs fails to read sss To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1584818/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1588915] Re: ifup does not block for interface to be up with static addresses
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 manually after network has started fully. Similarly as the bug reporter, I run Ubuntu 16.04 server, and I use static addresses only, configured in /etc/network/interfaces. The root cause is ifup exiting with success before network interfaces start operating. However, ifup behaved the same way in Ubuntu 14.04, and there it did not cause the problem. Apparently Upstart and its network- related units were able to deal with this issue correctly. In contrast, systemd configuration files packaged in ifupdown Xenial package are causing the "async" behavior of ifup to surface and create problems. During system boot there are two attempts to start physical network interfaces by ifup: in ifup@.service (one service per interface) and in networking.service. All these services start in parallel and call ifup in parallel, but ifup uses a lock to prevent its concurrent execution (per interface), effectively serializing ifup@.service(s) and networking.service. In my tests, ifup@ services always win this race. This actually works fine if all interfaces are configured successfully. If not, networking.service performs a second attempt after ifup@.service failed, which may be problematic (see below). Targets network.target and network-online.target are reached when networking.service finishes. This happens after interfaces are configured by ifup. Interfaces became operable significantly later. The problem may be worked around in a particular configuration in several ways: 1. We can make ifup wait for the interface to come up, for example by including a loop in post-up command in /etc/network/interfaces, checking /sys/class/net/$INTERFACE/operstate. This would require using some timeout, after which the command would fail, to deal with situations such as a disconnected cable. In such a case, the delay would be twice as long as the specified timeout, because that timeout will have to be reached in both ifup@.service and networking service. If we do not configure any virtual interfaces, we can deal with this by disabling networking.service. 2. We can modify ifup@.service to wait for the interface to come up, similarly as above. It will also be necessary to change the type of this service from "simple" to "oneshot", to make it wait for its ExecStart command before exiting. 3. We can also modify networking.service to wait in a similar manner. 4. We can introduce an additional service which will wait for all or some interfaces to come up, and will delay network.target and network- online.target until it is done. It would be advantageous to wait on all interfaces in parallel, and I am not sure if that would be easy to implement in one service. 5. An active waiting in a loop is obviously not the most beautiful solution, so perhaps a cleaner way could be found? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1588915 Title: ifup does not block for interface to be up with static addresses To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1588915/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 report that I was unable to reproduce this bug. When autofs was configured to start after sssd, and sssd started after network was up, autofs mounted all shares as expected and no error messages were logged. On the other hand, if both sssd and autofs started before network was up, shares would not be mounted, and syslog would contain an error message "setautomntent: lookup(sss): setautomntent: No such file or directory". If autofs was started before sssd, the error message would be "setautomntent: lookup(sss): setautomntent: Connection refused". Ensuring that network interfaces were up before systemd reached network.target and network-online.target was a pain in the neck and an exercise of frustration. But this is material for another bug report. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 Ubuntu. https://bugs.launchpad.net/bugs/1566508 Title: autofs races with sssd on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 individual bugs, none of them actually in autofs code. Similarly a fever is not an illness, but it is usually a symptom of one. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 than the one causing the "no mounts in table" error. I experienced both problems in Trusty/upstart, but so far only the "setautomntent" bug in Xenial/Systemd/autofs-with-SysV. According to my tests, the "setautomntent" bug is caused by sssd starting before network is ready, while "no mounts in table" results from sssd reaching ready state before its responders are up. However, Xenial startup is a total mess, and I am still trying to figure out what is really happening, so I may be wrong in the details. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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/QKU5H4VUCIZ43LBJTRPPK3XWL6CTQNQ4/ -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
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 returns before interface is up.
2. ifup@.service finishes before interface is up. This is for two reasons:
because the service calls ifup, and because the service has wrong type (simple
instead of oneshot). As a result, network-online.target is reached at a wrong
time.
3. sssd.service does not wait for network-online.target.
4. autofs reverted in Xenial to a SysV-style script and does not have a
systemd-style service file. Thus it is difficult to request that it is started
after sssd. However, fixing #2 causes systemd to run SysV scripts much later,
providing a relief for problems #4 and #5.
5. The issue being subject of this bug report is very likely still present,
though I was unable to reproduce it exactly. Unfixed issue #2 caused auto fs to
fail with a different error message ("setautomntent: lookup(sss):
setautomntent: No such file or directory"), while fixed issue #2 hid the bug.
The workaround involving waiting for sssd to start listening on
/var/lib/sss/pipes/autofs can still be used for extra safety. I will test this
further.
I will work more on these problems and submit bug reports for them if
they haven't been reported yet.
--
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 manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1585568] Re: slapd startup fails with "connections_destroy: nothing to destroy"
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 names, passwords or any other confidential information. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1585568 Title: slapd startup fails with "connections_destroy: nothing to destroy" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1585568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 worthwhile to make this effort for the release that goes out of support in two months, and has been already superseded by a LTS release. I apologize for a delay in replying to the verification request. This was caused by an unpleasant surprise encountered while testing the new packages. I attempted to recreate the test environment to mimic the setup in which I originally encountered this bug, but I did so slightly differently - and discovered another OpenLDAP bug that had basically the same symptoms. It was not immediately clear whether this situation was some unfixed edge case of the bug reported here, or if it was an entirely separate bug. Further analysis showed that it was the latter, the root cause is entirely different and similarities are coincidental. For reference, report for the new bug can be found at http://www.openldap.org/its/index.cgi?findid=8427 Testing methodology and environment: Tests were done with both fixed and unfixed versions of affected packages, i.e. 2.4.42+dfsg-2ubuntu3 and 2.4.42+dfsg-2ubuntu3.1. Note that symptoms of this bug are intermittent, and several iterations may be needed for them to surface. 1. Configure two LDAP servers in dual master replication setup using slapd.conf config file as shown below. 2. Provide the servers with TLS certificates that are correct but use 1024-bit public key. (Note: SECURE256 requires 4096-bit RSA key) 3. Set tls_reqcert to allow in slapd.conf. 4. Start slapd on both servers. 5. Stop and restart slapd on server A. 6. Server B will write errors to syslog: slapd: do_syncrep2: rid=001 (-1) Can't contact LDAP server slapd: do_syncrepl: rid=001 rc -1 retrying (9 retries left) Result when using fixed packages: After predefined time server B will retry replication, and we won't see any further error messages. Result when using unfixed packages: Server B produces the following messages in a loop: slapd: do_syncrepl: rid=001 rc -1 retrying (8 retries left) slapd: slap_client_connect: URI=ldaps://10.0.0.1 DN="cn=root,dc=test" ldap_sasl_bind_s failed (-1) The relevant parts of slapd.conf: (for server A at 10.0.0.1) loglevel1 serverID001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile/etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pem TLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=allow keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 ** Tags removed: verification-needed ** Tags added: verification-done -- 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 the results. Because of that I need more time to come up with reliable results; I hope to be ready next week. Thanks for your patience. -- 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 syncrepl unusable, but syncrepl would persistently fail or persistently work correctly, sometimes for long stretches of testing iterations. While trying to set a test environment using virtual machines, I was unable to reproduce the syncrepl failures at all. Because of that, in my original bug report to OpenLDAP project, I did not describe steps to reproduce the problem, but instead provided a debugging patch that reliably demonstrated the use-after-free issue. This patch replaced the offending free with an assignment of a special value to the variable that was to be freed. The value of that variable was then examined in places where it was accessed. However, while this approach demonstrates the bug well, it requires a rebuild of the code, and cannot be used to test the fixed package. I would like to add that I went the "debug-it-yourself" route precisely because the symptoms were too unpredictable and too "mysterious" to hope for the usual bug report to succeed (by "usual bug report" I mean complaining about symptoms, listing steps to reproduce, etc). To sum up, I can list steps I took during my testing, but these will be of limited use when reproducibility is concerned. I can also provide the debug patch with explanations. Please advise on what would be the best course of action. -- 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1525699] Re: Error message "/sbin/plymouthd: not found" is shown on booting
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: /scripts/init-premount/plymouth: line 38: /sbin/plymouthd: not found /scripts/init-premount/plymouth: line 38: /bin/plymouth: not found [fsck displays its output here] /scripts/init-bottom/plymouth: line 18: /bin/plymouth: not found -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1525699 Title: Error message "/sbin/plymouthd: not found" is shown on booting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1525699/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 Ubuntu. https://bugs.launchpad.net/bugs/1557248 Title: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566491] Re: phpldapadmin fails to enable php7.0 module
> 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 since beta1 on several machines, and found it to be much more reliable than 14.04 LTS (as it is now, two years old). Since we are only a couple of weeks away from the release, I much prefer to deal with an occasional configuration glitch than to again lock horns with Upstart. Anyway, the issue was not much of a problem for me; I submitted this bug report mainly for other users who might be looking for a workaround. Thanks a lot! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566491 Title: phpldapadmin fails to enable php7.0 module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566491/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566491] Re: phpldapadmin fails to enable php7.0 module
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. On my machines php5 was installed as a dependency of phpldapadmin. The issue came to light as a result of a mundane update: # apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libapache2-mod-php5 php5-cli php5-common php5-json php5-ldap Use 'apt autoremove' to remove them. The following NEW packages will be installed: libapache2-mod-php libapache2-mod-php7.0 liblua5.2-0 lua-lpeg php-common php-ldap php7.0-cli php7.0-common php7.0-json php7.0-ldap php7.0-opcache php7.0-readline The following packages will be upgraded: binutils bsdutils dbus ethtool gcc-5-base geoip-database libblkid1 libdbus-1-3 libdevmapper1.02.1 libfdisk1 libglib2.0-0 libglib2.0-data libmount1 libpython2.7-minimal libpython2.7-stdlib libpython3.5-minimal libpython3.5-stdlib libsmartcols1 libstdc++6 libsystemd0 libudev1 libuuid1 mount nmap phpldapadmin python2.7 python2.7-minimal python3.5 python3.5-minimal sudo systemd systemd-sysv udev util-linux uuid-runtime 35 upgraded, 12 newly installed, 0 to remove and 0 not upgraded. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566491 Title: phpldapadmin fails to enable php7.0 module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566491/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566491] Re: phpldapadmin fails to enable php7.0 module
** 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 and display a page indicating that php is not enabled. Workaround: a2enmod php7.0 $ apt-cache policy phpldapadmin phpldapadmin: - Installed: 1.2.2-5.2ubuntu1 + Installed: 1.2.2-5.2ubuntu1 $ lsb_release -rd Description:Ubuntu Xenial Xerus (development branch) Release:16.04 $ uname -a Linux 4.4.0-16-generic #32-Ubuntu SMP Thu Mar 24 22:38:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566491 Title: phpldapadmin fails to enable php7.0 module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566491/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566481] Re: phpldapadmin missing dependency php7.0-xml
** 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 warning about missing XML support. Workaround: apt-get install php7.0-xml $ apt-cache policy phpldapadmin phpldapadmin: Installed: 1.2.2-5.2ubuntu1 $ lsb_release -rd Description:Ubuntu Xenial Xerus (development branch) Release:16.04 $ uname -a Linux 4.4.0-16-generic #32-Ubuntu SMP Thu Mar 24 22:38:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566481 Title: phpldapadmin missing dependency php7.0-xml To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566481/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
** 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 Title: autofs races with sssd on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] [NEW] autofs races with sssd on startup
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 autofs may be started before sssd, or after sssd is started but before its autofs support is ready. If this happens, one can restart autofs and it will work fine. This bug affects other users: * Bug 40189 "autofs needs to be restarted to pick up some shares" - a very old bug with invalid status, but see last comment #46, complaining about Ubuntu trusty: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/40189/comments/46 * Link to SSSD-users mailing list, also complaining about Ubuntu trusty: https://lists.fedorahosted.org/pipermail/sssd-users/2015-July/003166.html $ lsb_release -rd Description:Ubuntu 14.04.4 LTS Release:14.04 $ apt-cache policy autofs sssd autofs: Installed: 5.0.7-3ubuntu3.2 sssd: Installed: 1.11.5-1ubuntu3 $ uname -a Linux 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Workaround: Edit /etc/init/autofs as shown in attached files (both full file and diff provided). Unfortunately, this modification will work only in this particular configuration, thus it is not a good candidate for a patch. Explanation: We have to deal with two problems here: 1. Autofs starts on runlevel [2345], and in effect its startup order in relation to sssd is random. We fix this by changing start stanza to "start on started sssd". 2. Unfortunately this is not enough, because sssd emits started event too early, before its autofs support is ready. To work around this, we add a loop to pre-start script that waits for sssd to start listening on /var/lib/sss/pipes/autofs. ** Affects: autofs (Ubuntu) Importance: Undecided Status: New ** Attachment added: "autofs.conf" https://bugs.launchpad.net/bugs/1566508/+attachment/4625147/+files/autofs.conf -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1564121] Re: Update to PHP7.0 dependencies
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 your comments in new bug reports, not in this one. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1564121 Title: Update to PHP7.0 dependencies To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1564121/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566491] [NEW] phpldapadmin fails to enable php7.0 module
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 php7.0 $ apt-cache policy phpldapadmin phpldapadmin: Installed: 1.2.2-5.2ubuntu1 $ lsb_release -rd Description:Ubuntu Xenial Xerus (development branch) Release:16.04 $ uname -a Linux 4.4.0-16-generic #32-Ubuntu SMP Thu Mar 24 22:38:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ** Affects: phpldapadmin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566491 Title: phpldapadmin fails to enable php7.0 module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566491/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566481] Re: phpldapadmin missing dependency php7.0-xml
** 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 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-cache policy phpldapadmin phpldapadmin: - Installed: 1.2.2-5.2ubuntu1 + Installed: 1.2.2-5.2ubuntu1 $ lsb_release -rd Description:Ubuntu Xenial Xerus (development branch) Release:16.04 $ uname -a Linux 4.4.0-16-generic #32-Ubuntu SMP Thu Mar 24 22:38:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566481 Title: phpldapadmin missing dependency php7.0-xml To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566481/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566481] [NEW] phpldapadmin missing dependency php7.0-xml
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-cache policy phpldapadmin phpldapadmin: Installed: 1.2.2-5.2ubuntu1 $ lsb_release -rd Description:Ubuntu Xenial Xerus (development branch) Release:16.04 $ uname -a Linux 4.4.0-16-generic #32-Ubuntu SMP Thu Mar 24 22:38:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ** Affects: phpldapadmin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566481 Title: phpldapadmin missing dependency php7.0-xml To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1566481/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 Title: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1547927] Re: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
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 Title: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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: Backport a fix for use-after-free in GnuTLS-related code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547927] Re: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
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. https://bugs.launchpad.net/bugs/1547927 Title: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
** 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
** 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 (wily), but I can make them for other Ubuntu releases, if you would like that. I briefly tested the amd64 libldap, ldap-utils and slapd packages, they installed fine and appear to work. I did not test any of the i386 debs. If you would like to install and test these packages, please run the following commands: sudo apt-add-repository ppa:maciej-puzio/openldap sudo apt-get update sudo apt-get upgrade Of course, please install them on a test machine, and not on the production server. -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 (wily), but I can make them for other Ubuntu releases, if you would like that. I briefly tested the amd64 libldap, ldap-utils and slapd packages, they installed fine and appear to work. I did not test any of the i386 debs. If you would like to install and test these packages, please run the following commands: sudo apt-add-repository ppa:maciej-puzio/openldap sudo apt-get update sudo apt-get upgrade Of course, please install them on a test machine, and not on the production server. -- 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557248] Re: OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1547927] Re: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
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 being used. This bug has been fixed upstream by the OpenLDAP team, but the fix has not yet been backported to Ubuntu. Bug 1557248 https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248 The problem you describe may be caused by this bug, or by an unrelated problem. However, in any case Ubuntu libldap packages currently in wily and xenial do not handle "require cert" option correctly. With this in mind, may I ask that you vote for bug 1557248 in order for it to get noticed by Ubuntu maintainers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547927 Title: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547927] Re: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
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 being used. This bug has been fixed upstream by the OpenLDAP team, but the fix has not yet been backported to Ubuntu. Bug 1557248 https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248 The problem you describe may be caused by this bug, or by an unrelated problem. However, in any case Ubuntu libldap packages currently in wily and xenial do not handle "require cert" option correctly. With this in mind, may I ask that you vote for bug 1557248 in order for it to get noticed by Ubuntu maintainers. -- 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/1547927 Title: LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1537762] Re: syncrepl does not work when using tls
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.launchpad.net/bugs/1537762 Title: syncrepl does not work when using tls To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1537762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1537762] Re: syncrepl does not work when using tls
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 Ubuntu. https://bugs.launchpad.net/bugs/1537762 Title: syncrepl does not work when using tls To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1537762/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] [NEW] OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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=openldap.git;a=commitdiff;h=283f3ae1713df449cc170965b311b19157f7b7ea Modifications to file: libraries/libldap/tls_g.c This problem affects openldap 2.4.41 (in Ubuntu wily), 2.4.42 (in Ubuntu xenial), as well as in 2.4.44 (current upstream stable version). More details are availble on OpenLDAP project bug tracker at: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8385 Thank you ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1557248] [NEW] OpenLDAP: Backport a fix for use-after-free in GnuTLS-related code
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=openldap.git;a=commitdiff;h=283f3ae1713df449cc170965b311b19157f7b7ea Modifications to file: libraries/libldap/tls_g.c This problem affects openldap 2.4.41 (in Ubuntu wily), 2.4.42 (in Ubuntu xenial), as well as in 2.4.44 (current upstream stable version). More details are availble on OpenLDAP project bug tracker at: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8385 Thank you ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- 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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 831487] Re: Dependency on package unattended-upgrades on Ubuntu Server
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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/831487 Title: Dependency on package unattended-upgrades on Ubuntu Server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1371564] Re: statd incompatible with /var as a separate filesystem
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/init/statd.conf 2015-06-02 16:24:42.029659358 -0500 @@ -12,7 +12,7 @@ # TYPE=nfs is handled in the statd-mounting job. # start on (started portmap ON_BOOT= - or (virtual-filesystems and started portmap ON_BOOT=y)) + or (virtual-filesystems and mounted MOUNTPOINT=/var and started portmap ON_BOOT=y)) stop on stopping portmap expect fork -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1371564 Title: statd incompatible with /var as a separate filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1371564/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var or other nfs mount races with rpc.statd
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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/525154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1350480] Re: [REGRESSION] Kernel update renders Intel NUC (i5-3427) unbootable with USB devices plugged in
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.e. Precise. I already tested the patch (modified to keep find_trb_seg) with the upstream (kernel.org) stable 3.2 kernel, and can confirm it fixes the regression. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1350480 Title: [REGRESSION] Kernel update renders Intel NUC (i5-3427) unbootable with USB devices plugged in To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1350480/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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: http://thread.gmane.org/gmane.linux.kernel.stable/103514 By the way, I checked the upstream 3.2.y kernel (3.2.62), and unfortunately the patch has not yet been backported to it. -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1330530 Title: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1333229] Re: USB 3.0 regression after upgrading to 3.2.0-64 kernel
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://bugs.launchpad.net/bugs/1333229 Title: USB 3.0 regression after upgrading to 3.2.0-64 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 tested this patch and can confirm that it fixes the regression in kernel 3.2.x. Newer kernels have not been affected by the regression, as it is masked by another code change that has not been backported to 3.2. Here is the link for the discussion: http://thread.gmane.org/gmane.linux.usb.general/110685 As I understand it, we are now waiting for Julius' patch to be pulled to the mainline kernel. -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1333229] Re: USB 3.0 regression after upgrading to 3.2.0-64 kernel
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.net/bugs/1333229 Title: USB 3.0 regression after upgrading to 3.2.0-64 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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.gmane.org/gmane.linux.usb.general/110685 http://www.spinics.net/lists/linux-usb/msg109949.html -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 not there at all (all branches except 3.2), or remains unfixed (3.2). Thus I have no target for the bisection. On somewhat happier news, I have spent last few days debugging the kernel, and I got some results. Specifically, I have a patch that fixes regression on 3.2.0-64 running on a particular hardware. The patch is rather ugly, and will probably cause problems on other hardware, but at least it shows some direction. I will gladly discuss this matter, but I will need a little more attention shown by Ubuntu maintainers. Each of my posts corresponds to many hours of my work, and while I am grateful for any attention, its current level does not permit a constructive dialogue. I am very sorry to say this, and I mean no offense, but I will put more effort into writing here only when I see a chance that someone will read it. ** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed ** Tags removed: kernel-fixed-upstream-3.16-rc1 needs-reverse-bisect -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1333229] Re: USB 3.0 regression after upgrading to 3.2.0-64 kernel
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 come after a ~15 second delay, and this repeats in a loop for 18 minutes. Some other errors may also be thrown, usually related to udev or various timeouts. However, with the USB3 SD reader that I tested, the errors came only once during boot, with only ~15 second total delay, and the boot then proceeded successfully, although the device subsequently did not work. This matches your observations. This all suggests that we are experiencing the same root problem.. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1333229 Title: USB 3.0 regression after upgrading to 3.2.0-64 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
** 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1333229] Re: USB 3.0 regression after upgrading to 3.2.0-64 kernel
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1333229 Title: USB 3.0 regression after upgrading to 3.2.0-64 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1333229] Re: USB 3.0 regression after upgrading to 3.2.0-64 kernel
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, long delay, dropped to boot console, etc.)? 3. Does any of the problematic devices work after you give it sufficient time (in my testing, most devices would work after being plugged in for 18 minutes). 4. Do the error messages differ among problematic devices? Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1333229 Title: USB 3.0 regression after upgrading to 3.2.0-64 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 mainline kernel v3.16-rc1, where it does not cause problems. My guess is that this commit revealed a bug hidden somewhere else, in a code that was modified since kernel 3.2. -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 fact that the the code in question is modified by two commits. Since I was not able to verify the result of bisection, I am not posting it, to avoid confusion. Next week I will further debug the code, and post here when I get conclusive results. -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: [Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 not change the status to incomplete, and do not request same steps or actions as for bug 1330530. Instead, please mark this bug as a duplicate of 1330530. This will focus everybody's attention on the problem and minimize confusion. Thank you. ** 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 USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 try to forward bisect commits from 3.2.58 (last good) to 3.2.59 (first bad). Just for reference, here are results of my testing. Bad means that bug was reproducible in the given kernel, good that it was not. 3.2.58 good 3.2.59 bad 3.2.60 bad 3.4.89 good 3.4.90 good 3.4.91 good 3.4.92 good 3.4.93 good 3.4.94 good 3.10.44 good 3.11.10.11 good 3.13.22 good 3.13.11 good 3.13.11.1 good 3.13.11.2 good 3.13.11.3 good 3.14.8 good 3.15-rc1 good 3.15-rc2 good 3.15-rc3 good 3.15-rc4 good 3.15-rc5 good 3.15-rc6 good 3.15-rc7 good 3.15-rc8 good 3.15 good 3.15.1 good 3.16-rc1 good -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: [Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 tested so far: Good kernels: 3.2.0-63, 3.16.0-031600rc1 Bad kernels: 3.2.0-64, 3.2.60-030260 I also tested this issue on three additional machines, and the results were the same. So I have now five different hardware configurations (including one from bug 1330530) that are affected by this problem and show very similar symptoms. In fact, I was not able to find a computer that would not replicate this regression. If we also take into account Bard Hemmer's hardware, we can reasonably conclude that the issue is not related to motherboard/chipset/CPU/BIOS. It is however related to HighPoint RocketU 1144C add-in adapter that I used in all my tests. I would like to note that symptoms are similar on various hardware, but not identical. The errors are generally similar (xhci, udev, modprobe), but it appears that timing differences cause the issue to occur at different parts of the boot process, depending on the hardware. So far I have seen: 1. Dropping to initramfs shell in the middle of the boot (Gave up waiting for root device. ... ALERT! [boot drive] does not exist! Dropping to shell!) 2. An error loop preventing system to boot (as described in this report). In this case I am not sure whether this is an infinite loop, or if the system would boot after a long delay. 3. Boot is delayed by 18 minutes, during which time numerous errors are thrown. After 18 minutes, OS boots fine. 4. System boots to text console, rather than the graphical login screen. It is possible to log on to the console. Within seconds, xhci and/or udev errors start appearing in the syslog. After two minutes, screen goes blank, and the console seems unresponsive for another 16 minutes. Following that, the graphical login screen appears, and from this point system behaves fine. 5. As in 4, but after two minutes in the text console, incomplete graphical login screen appears. Password box is missing and the background is not fully loaded. After another 16 minutes, login screen loads missing parts, and system behaves OK. In this case it is possible to switch between text and graphical consoles during these 16 minutes, but the graphical console becomes a purple empty screen after the switch. It is also worth noting that symptoms are highly dependent on the external device(s) attached to RocketU's ports. Here is a summary: 1. No device connected to RocletU adapter - no problems during boot 2. USB3 flash drives (tested two models) - no problems during boot 3. Areca ARC-5040 enclosure - bug is triggered 4. WD MyPassport 2TB US 3.0 drive - bug is triggered 5. Transcend USB 3.0 SD card reader (TS-RDF5K) - bug is triggered with different symptoms: only a small delay (~15 seconds) and small number of xhci errors occur during boot, but the device does not work when OS is fully booted. All the above devices work fine with good kernels. Note that I tested three RocketU controllers and five Areca enclosures, to rule out the possibility of a hardware problem on these devices. With a variety of hardware reliably triggering the bug on bad kernels, while working fine with good kernels, I think it is fully substantiated to consider this regression as not hardware-dependent (apart from the RocketU controller). I am changing tags as Christopher requested in comment #13, but I would like to ask that this bug is marked as duplicate of bug 1330530. That would allow me to debug the issue on my test machines, which would be substantially easier than doing it on production servers. I would prefer not to touch these servers until the fix is released and verified on test computers. ** Tags added: kernel-fixed-upstream kernel-fixed-upstream-3.16 -- 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 USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: [Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
** 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-64 fails to boot with USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: [Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
** 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 USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3 controller
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# WDBY8L0020BBL). This drive is causing the same problems as Areca ARC-5040 (with kernels 3.2.0-64 and 3.2.60). No problems with kernel 3.16.0-031600rc1. Thus I have two USB3 devices that trigger the bug. As of now, the only constant element required for the bug to appear is HighPoint RocketU 1144C USB3 controller. -- 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: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] [NEW] Regression: Kernel 3.2.0-64 problems with USB3 controller
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 (1328984) was encountered on machines that are production servers, I attempted to replicate in on another machine that could be entirely devoted to testing this issue. I equipped this computer with the same USB3 hardware as the servers, that is the HighPoint RocketU 1144C USB 3.0 controller and Areca ARC-5040 USB 3.0 RAID enclosure connected to it. I was able to replicate the problem with ease, provided that all three following conditions were met: 1. System booted kernel 3.2.0-64, 2. HighPoint RocketU 1144C controller was installed, 3. Areca ARC-5040 was connected to that controller. The problem did not appear if I booted an older kernel (e.g. 3.2.0-63), or if Areca enclosure was not attached, or if it was attached using another interface (USB2 or eSATA). The problem was also absent if I replaced the Areca enclosure with another USB3 device (a flash drive). The test machine's motherboard did not have a built-in USB3 controller, but I performed an additional test on yet another computer, equipped with a NEC USB3 controller. That test was done with kernel 3.2.0-64 and the Areca enclosure, and did not replicate the problem. Thus I assume that it is the combination of the RocketU controller and a specific USB3 device that triggers kernel regression. In the original bug report (1328984) Bard Hemmer reported that he encountered a similar trouble with Western Digital My Passport 2TB USB 3.0 external drive. I happen to own this exact model, and I intend to test it as soon as possible. Symptoms: The symptoms on the test machine are somewhat different than those occurring on the production servers. The error loop during boot contains the following messages: [ 34.084469] usb 8-1: reset SuperSpeed USB device number 2 using xhci_hcd [ 34.101825] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint called with disabled ep 88042102e000 [ 34.101918] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint called with disabled ep 88042102e040 This continues for about 18 minutes, after which the filesystem on the Areca drive is mounted, and boot process continues successfully, as if nothing had happened. Afterwards the affected drive works seemingly fine, although I experienced some system instability, causing a total system freeze. At this point I am not sure if this instability is related to the problem at hand. Similar effects happen if Areca enclosure is hot-plugged to the working system. In such a case OS boots fine (as the enclosure is absent during boot). After plugging the Areca, the drive is unavailable for 18 minutes, during which time numerous errors as above are logged. After 18 minutes elapse, drive is mounted and behaves normally. Hardware: Dell Vostro 430 CPU: Intel Core i7-860 RAM: 16GB DDR3 unbuffered non-ECC Add-on card: HighPoint RocketU 1144C 4-Port USB 3.0 PCIe 2.0 x4 HBA Software: Ubuntu 3.2.0-64.97-generic 3.2.59 x86_64 Note about apport collection: Due to problems described in bug 1328984, relevant to this setup as well, I am unable to run apport tools to submit system information. For this reason, I am attaching a file generated by apport-cli -f -p linux --save filename.apport ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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: Regression: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: Regression: Kernel 3.2.0-64 problems with USB3 controller
** 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/1330530 Title: Regression: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: Regression: Kernel 3.2.0-64 problems with USB3 controller
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 this bug report, and were occurring in older kernels as well. As this bug has been replicated on various hardware, affects more than one user, and requested system information has been provided, I am changing status to 'confirmed'. When the nature of this problem is better understood, this bug may possibly be marked as a duplicate of bug 1328984. ** 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: Regression: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: [Dell PowerEdge R510] Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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, these are production servers, and I need to schedule a maintenance window in order to take one of them offline. I am required to give an advance notification to users, so this is not something that can be done on a very short notice, or very often (once per week is max I can do). For this reason, may I ask if there are any other conceivable tests that I could run? It would speed things up considerably if I could use the maintenance window to do as many tests as possible, rather than do one at a time. -- 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 USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1330530] Re: Regression: Kernel 3.2.0-64 problems with USB3 controller
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 -a Linux ubuntu 3.16.0-031600rc1-generic #201406160035 SMP Mon Jun 16 04:36:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux -- 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: Regression: Kernel 3.2.0-64 problems with USB3 controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 reproduced, but symptoms are somewhat different, and I worry about confusion which may result from mixing discussion about two hardware configurations. On the other hand, I am reluctant to start a new bug report, as this appears to be a single bug.) ** Attachment added: Result of apport-cli https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+attachment/4130995/+files/bug1328984.apport -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 tomorrow. In the meantime, I managed to replicate the regression on a different hardware (still using HighPoint RocketU 1144C and Areca ARC-5040). Should I include my observations, error logs and apport-collected data from that machine in this bug report, or should I create a new bug? -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 created .apport file using ubuntu-bug does not work, because ubuntu-bug ignores file specified in -c or --crash-file parameter, and proceeds to gather system information from the machine on which it is running. As this is a wrong machine, I had no choice but to cancel the submission. 3. In addition, ubuntu-bug generates the following error: No packages found matching linux. ERROR: hook /usr/share/apport/general-hooks/cloud_archive.py crashed At this point debugging apport is not my priority. I would be grateful if you indicate an alternative way to proceed. -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
** 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1328984] Re: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card
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 reproducible. 2. Two affected machines are servers located behind a corporate proxy. Apport-collect does not allow transmission through a proxy. As instructed, I am changing the status to 'Confirmed'. ** 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: Regression: Kernel 3.2.0-64 fails to boot with USB3 controller card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 831487] Re: Dependency on package unattended-upgrades on Ubuntu Server
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 choice would be a suggest or recommend dependency, or none at all. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/831487 Title: Dependency on package unattended-upgrades on Ubuntu Server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1169030] Re: CVE 2013-1915: local files disclosure or resource exhaustion via XML External Entity attack
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 this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1169030 Title: CVE 2013-1915: local files disclosure or resource exhaustion via XML External Entity attack To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-security/+bug/1169030/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1161134] Re: Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI
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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1161134 Title: Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1161134/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1161134] [NEW] Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI
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 kernel 3.2.0-39, as of this writing the newest kernel for Ubuntu 12.04 LTS. The new logic attempts to read SMBIOS entry point structure, failing back to DMI entry point structure if SMBIOS structure is not present. However, if SMBIOS structure is present but invalid (as happens on older machines), the new logic fails to properly handle such a case (please see attached patch for details). As a result DMI information is read incorrectly, and ACPI is disabled. Workarounds: 1. Revert to kernel 3.2.0-38, or: 2. Pass acpi=force as kernel boot parameter. # uname -a Linux time 3.2.0-39-generic-pae #62-Ubuntu SMP Wed Feb 27 22:25:11 UTC 2013 i686 i686 i386 GNU/Linux # lsb_release -rd Description:Ubuntu 12.04.2 LTS Release:12.04 Additional notes: As benign as this issue may seem, it resulted in a routine kernel update disabling one of my servers. This machine, being past its prime, was relegated to a nightly backup duty. The machine would wake up at 3am every night, perform a backup, then set an alarm for 3:00 next day (using /sys/class/rtc/rtc0/wakealarm) and power off. After a routine update from kernel 3.2.0-38 to 3.2.0-39 the machine ceased to function: it would remain powered but shut down, and would not perform nightly backups. An investigation revealed that the machine reported its SMBIOS structure as being 32 bytes long, while SMBIOS specification requires that value to be 31. Apart from this extra byte the structure was perfectly valid, but this was enough to make validation in dmi_scan.c fail. This resulted in a string of events that disabled the machine: the code assumed that SMBIOS structure was invalid, then proceeded to read the DMI structure, but failed to do so because of the bug described here. Not having the DMI BIOS year, ACPI was disabled, and the wake alarm was not set when requested. As a result the machine did not wake up when it was supposed to, and failed to perform its main function. Patch has been tested on three machines, including the affected one. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: acpi dmi kernel smbios ** Patch added: Patch to dmi_scan.c https://bugs.launchpad.net/bugs/1161134/+attachment/3601908/+files/dmi_scan.c.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1161134 Title: Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1161134/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1161134] Re: Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI
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 information (e.g. http(s)_proxy variables) was able to go around this error. Changing status to 'Confirmed', as no assistance in diagnosing the problem is needed and the solution in form of a kernel patch has already been included in the bug report. ** 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/1161134 Title: Regression: Kernel 3.2.0-39 misreads DMI on some machines, disables ACPI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1161134/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1158746] Re: fails to suspend
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 bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1158746] Re: fails to suspend
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, thus it likely is an unrelated bug. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 520386] Re: libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge
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 interface is through the drop-down list, which is empty (due to the netcf bug). This means that virt-manager must be installed on the kvm host, together with 100+ packages that it pulls for UI support. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/520386 Title: libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
