[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Proposed package (5.7.2-2ubuntu1.1) deployed on host; error messages no- longer appear in journal, and previously-missing Ceph metrics are appearing in our metrics visualisation system. Looks good! ** 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/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Quick testing update: * I have updated my Ceph cluster to 12.2.11-0ubuntu0.18.04.1, everything still works as expected. * Running the provided test version of collectd, 5.7.2-2ubuntu1+testpkg20190326b1 against the updated Ceph instance does seem to be successfully collecting all metrics, and not otherwise logging errors; * I have run the provided test version of collectd against a second host which also runs OSDs; this likewise appears to work correctly. Thanks! Kind regards, David -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Hi Eric, I only updated collectd on a node with just an MDS and MON, not an OSD. I'm about to update the version of Ceph on this (small) cluster to the latest current in Bionic (12.2.11-0ubuntu0.18.04.1); I'll take this opportunity to apply the collectd update test on one of the OSD hosts. Kind regards, David -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Not a problem, ask away. :) For reference, this was testing against Ceph 12.2.8-0ubuntu0.18.04.2. (Which is not the latest in Bionic; I shall likely undertake a quick upgrade later today.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
My test was against Luminous, using Ceph packages supplied in Bionic. I can look up the exact version when I'm back in the office in the morning. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Hello Eric, Thank you so much for working on this issue, it's going to help with some maintainability issues here! With the existing package, I continue to see errors as previously reported of the form: Mar 26 21:32:37 stor-a collectd[25914]: ceph plugin: cconn_handle_event(name=mon.stor-a,i=0,st=4): error 1 Mar 26 21:32:37 stor-a collectd[25914]: ceph plugin: ds ThrottleMsgrDispatchThrottlerMds.wait.avgtime was not properly initialized. Mar 26 21:32:37 stor-a collectd[25914]: ceph plugin: JSON handler failed with status -1. Mar 26 21:32:37 stor-a collectd[25914]: ceph plugin: cconn_handle_event(name=mds.stor-a,i=1,st=4): error 1 Additionally, a subset of Ceph metrics no-longer get logged. Installing the test packages provided (version 5.7.2-2ubuntu1+testpkg20190326b1), these errors no-longer occur, and (by inspection) the full set of Ceph metrics start getting logged again. (I say 'again', because I have been running a manually-compiled build of version 5.8 of collectd that I manually compiled with these fixes, which has been running happily for some considerable time.) So this looks like a good fix! Thanks again for your help. Kind regards, David -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774041] [NEW] Perl library Dpkg::Index no-longer usable with Perl taint-mode enabled
Public bug reported:
The Perl library Dpkg::Index used to be usable with taint mode (-T)
enabled.
Specifically, it worked when using package 1.18.4ubuntu1 of libdpkg-perl
in Ubuntu 16.04. This has since regressed in Ubuntu 18.04, which uses
version 1.19.0.5ubuntu2.
The following perl script demonstrates the issue:
#!/usr/bin/perl -wT
use strict;
use warnings;
use Dpkg::Index;
1;
This script completes without error when run against 1.18. Running it
against 1.19 results in the following taint error in the Dpkg::Vendor
component, one of Dpkg::Index's dependencies:
% perl -wT poc.pl
Insecure dependency in eval while running with -T switch at
/usr/share/perl5/Dpkg/Vendor.pm line 164.
Compilation failed in require at /usr/share/perl5/Dpkg/Control/Hash.pm line 25.
BEGIN failed--compilation aborted at /usr/share/perl5/Dpkg/Control/Hash.pm line
25.
Compilation failed in require at /usr/share/perl5/Dpkg/Control.pm line 47.
BEGIN failed--compilation aborted at /usr/share/perl5/Dpkg/Control.pm line 47.
Compilation failed in require at /usr/share/perl5/Dpkg/Index.pm line 26.
BEGIN failed--compilation aborted at /usr/share/perl5/Dpkg/Index.pm line 26.
Compilation failed in require at poc.pl line 6.
BEGIN failed--compilation aborted at poc.pl line 6.
This corresponds to the following code in get_vendor_object():
eval qq{
pop \@INC if \$INC[-1] eq '.';
require Dpkg::Vendor::$name;
\$obj = Dpkg::Vendor::$name->new();
};
Commenting out the 'pop' line does not prevent the "Insecure dependency"
error.
** Affects: dpkg (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/1774041
Title:
Perl library Dpkg::Index no-longer usable with Perl taint-mode enabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1774041/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774032] [NEW] Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
Public bug reported: The version of collectd shipped with Ubuntu 18.04 (Bionic) provides a ceph plugin that is incompatible with the version of Ceph shipped in the same distribution. The version of collectd is 5.7.2-2ubuntu1 The version of ceph is 12.2.4-0ubuntu1.1 This patch for collectd is required for correct interoperation with Ceph 12+: https://github.com/collectd/collectd/pull/2464 The first version of collectd to contain this patch is 5.8.0. Without this patch, errors of the following form will be logged by collectd, and many ceph-specific metrics will not be collected: May 28 09:31:56 stor-a collectd[2141]: ceph plugin: cconn_handle_event(name=osd.2,i=0,st=4): error 1 May 28 09:31:56 stor-a collectd[2141]: ceph plugin: ds Bluestore.kvFlushLat.avgtime was not properly initialized. May 28 09:31:56 stor-a collectd[2141]: ceph plugin: JSON handler failed with status -1. ** Affects: collectd (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Bionic: CollectD ceph plugin is version incompatible + Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) ** Description changed: The version of collectd shipped with Ubuntu 18.04 (Bionic) provides a ceph plugin that is incompatible with the version of Ceph shipped in the same distribution. The version of collectd is 5.7.2-2ubuntu1 The version of ceph is 12.2.4-0ubuntu1.1 This patch for collectd is required for correct interoperation with Ceph 12+: - https://github.com/collectd/collectd/pull/2464 + https://github.com/collectd/collectd/pull/2464 - The version version of collect to contain this patch is 5.8.0. + The first version of collectd to contain this patch is 5.8.0. Without this patch, errors of the following form will be logged by collectd, and many ceph-specific metrics will not be collected: May 28 09:31:56 stor-a collectd[2141]: ceph plugin: cconn_handle_event(name=osd.2,i=0,st=4): error 1 May 28 09:31:56 stor-a collectd[2141]: ceph plugin: ds Bluestore.kvFlushLat.avgtime was not properly initialized. May 28 09:31:56 stor-a collectd[2141]: ceph plugin: JSON handler failed with status -1. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743798] [NEW] Kernel sometimes panics during early boot if CPU microcode archive prepended to initramfs
Public bug reported: As part of my response to the recent Meltdown and Spectre security issues, I've started deploying the intel-microcode package (initially, version 3.20170707.1~ubuntu16.04.0, though I realise this does not include recent security-related fixes) to desktops and servers equipped with Intel CPUs. This has caused machine boots to sometimes fail, though the behaviour does not appear deterministic. The error reported by the kernel is: initramfs unpacking failed: junk in compressed archive This then immediately leads to the kernel panicing, as the initramfs is needed for mounting the local root filesystem. (Fortunately, I have set the panic=300 kernel command-line option, so physical machines that panic in this way will auto-reboot after 5 minutes, and can thus be rescued from afar via network boot.) I've seen these failures on two different varieties of desktop (one HP/Compaq, one Dell), and also on VMs hosted by VMware. I believe that this problem is a non-deterministic race-condition during the machine early boot sequence—probably in the kernel—as the same machine with the same disk contents can exhibit either working or failing behaviour on subsequent boot attempts. Unfortunately, this particular error message appears in three different places in init/initramfs.c, so it's not precisely clear what specific problem is occurring. This problem has been difficult to reproduce on hosts reliably. Machines that are affected by this issue typically present it on most boot attempts, but this cannot be relied on. Attempting to gather more information from the kernel via the 'debug' command-line option produces more data, but this is difficult to capture. Attempting to also add "console=ttyS0" on a VM that was reliably presenting this problem caused the error to stop triggering, presumably due to changed timing. The intel-microcode package works by prepending a prepared initramfs image with a CPIO archive that contains microcode files, with predictable names, for early application by the kernel. See also: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/microcode.txt Removing the intel-microcode package, and thus regenerating initramfs files without any CPIO archive prepended to them, appears to prevent this issue from triggering. My suspicion is that the kernel is failing to handle this compound archive structure in a reliable way. However, it's conceivable that this problem is not in the Linux kernel, but in the GRUB2 bootloader in use on these machines. As I understand things, it is the responsibility of the GRUB2 bootloader to read the kernel and initramfs files from disk, and execute them both together. It's thus conceivable that the defect does not lie in the kernel, but that the GRUB2 bootloader is instead failing to reliably parse the btrfs root filesystem data-structures, and thus the kernel is correctly rejecting an invalid initramfs payload being passed to it. However, given I've been successfully using GRUB2 and btrfs in this way without issue for some years with a variety of kernels and initramfs configurations, this strikes me as being less likely. I have no reason to believe that this issue is limited to this (major) version of the kernel. ** Affects: linux-hwe (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Photograph of HP/Compaq desktop machine presenting early boot panic" https://bugs.launchpad.net/bugs/1743798/+attachment/5038285/+files/WP_20180115_11_34_03_Pro.jpg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743798 Title: Kernel sometimes panics during early boot if CPU microcode archive prepended to initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1743798/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1710911] Re: apt-ftparchive does not correctly cache filesizes for packages > 4GB
** Also affects: apt (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872334 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1710911 Title: apt-ftparchive does not correctly cache filesizes for packages > 4GB To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1710911/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1710911] Re: apt-ftparchive does not correctly cache filesizes for packages > 4GB
I believe this issue also affects apt-ftparchive in Debian, so have raised a bug there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872334 ** Bug watch added: Debian Bug tracker #872334 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872334 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1710911 Title: apt-ftparchive does not correctly cache filesizes for packages > 4GB To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1710911/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1710911] Re: apt-ftparchive does not correctly cache filesizes for packages > 4GB
juliank: From what I can see, cache files generated by apt-ftparchive do
not contain versioned entries. They can also be located anywhere on a
machine's filesystem, depending on how the sysadmin chose to apply the
utility; there isn't one canonical file that can be automatically
refreshed on package upgrade.
At present, the ':st' part of a cache entry has the following structure:
enum FlagList {FlControl = (1<<0),FlMD5=(1<<1),FlContents=(1<<2),
FlSize=(1<<3), FlSHA1=(1<<4), FlSHA256=(1<<5),
FlSHA512=(1<<6), FlSource=(1<<7)
[...]
// WARNING: this struct is read/written to the DB so do not change the
// layout of the fields (see lp #1274466), only append to it
struct StatStore
{
uint32_t Flags;
uint32_t mtime;
uint64_t FileSize;
uint8_t MD5[16];
uint8_t SHA1[20];
uint8_t SHA256[32];
uint8_t SHA512[64];
}
(From ftparchive/cachedb.h)
One of my colleagues has pointed out that my original suggestion of
checking the lower four bytes for null values will misbehave if the
corrected code is asked to record information for a file that is an
exact integer multiple of 4GB. You could stat the file on the
filesystem in this case to resolve the ambiguity.
Alternatively, you could modify the data-structure above to make it
unambiguous what kind of record is being read:
* A flag bit could be used in Flags;
* An explicit version field could be added to the end of this struct.
* The use of the cache to store package file sizes could be discontinued in
favour of always statting the file-size directly;
* The packed data-structure could be discarded completely, in favour of storing
different pieces of metadata in independent DB keys.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1710911
Title:
apt-ftparchive does not correctly cache filesizes for packages > 4GB
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1710911/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1710911] [NEW] apt-ftparchive does not correctly cache filesizes for packages > 4GB
Public bug reported: Release: 16.04 Version: 1.2.19 apt-ftparchive is a utility for, among other things, generating a Packages file from a set of .deb packages. Because generating Packages files for a large directory tree of .deb packages is expensive, it can cache the properties of .deb packages it has already inspected in a Berkeley database file. Historically, apt-ftparchive stored the size of a .deb package as a 32-bit unsigned integer in network byte-order in this cache. This field was later enlarged to 64-bits - which caused other problems; see: LP #1274466. However, even after this integer field was enlarged, apt-ftparchive continued to use the htonl() and ntohl() libc functions to convert file- sizes to and from network byte-order when reading and writing to its cache. These functions unconditionally emit 32-bit unsigned integers, which means that apt-ftparchive remained unable to correctly record the file-sizes for packages > 32bits (i.e. > 4GB). Consequently, if apt-ftparchive is asked (with caching enabled) to generate a Packages file for a .deb package larger than 4GB, it will produce a Packages file with the correct Size: field the first time, but with incorrect Size: fields subsequently. I have developed a small patch which replaces the use of the ntohl() family of functions with suitable replacements from . This produces correct output on new installations. However, caution is necessary: the existing code is incorrectly storing the 32 least significant bits of a 64-bit number in the upper 32-bits of a 64-bit field, in big-endian byte order. The application of this patch will cause new values to be stored correctly, but in a binary- incompatible way with existing caches. For example, a package of size 7162161474 bytes will today have the following sequence of bytes stored in its cache entry: \xaa\xe5\xe9\x42\x00\x00\x00\x00 (When re-read, this will produce a file-size value of 7162161474 mod 32bits, i.e. 2867194178.) With this patch applied, apt-ftparchive will correctly store this entry: \x00\x00\x00\x01\xaa\xe5\xe9\x42 However, this correct cache entry, when interpreted by the current broken code, will return a file-size of 1 byte. Worse, the existing broken entry will be interpreted by my fixed code as containing the value 12314505225791602688. It would be good to have this patch, or some derivative of it, applied to the main APT code-base. Before this can happen, however, some mechanism to detect and correct broken cache entries will be needed if we are to avoid a repeat of LP #1274466. I would suggest this could be done by checking the trailing four bytes of the 64-bit filesize field: if they are all zero, then the cache entry is broken, and should be rewritten. ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Patch added: "Fix truncation of 64-bit file-sizes caused by htonl()" https://bugs.launchpad.net/bugs/1710911/+attachment/4932874/+files/apt-ftparchive-64bit-fix.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1710911 Title: apt-ftparchive does not correctly cache filesizes for packages > 4GB To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1710911/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611816] Re: pam_cifscreds.so not supplied in package
I have successfully tested version 2:6.4-1ubuntu1.1 on Xenial, and assert that the new version of the package works for me. Thanks! ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1611816 Title: pam_cifscreds.so not supplied in package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1611816/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1597762] Re: intel-microcode initramfs-tools hooks mangle initramfs
This appears to be intended behaviour. The intel-microcode package is prepending an uncompressed CPIO archive, containing just the microcode for the local processor, in front of the existing compressed initramfs archive. This is (apparently? in some versions?) supported by the kernel as an input format to allow the microcode update to be applied early in the boot process. Attempting to unpack the resulting combined image with `cpio` will only show the contents of this first archive, and not the second one appended after it. However, if you run `lsinitramfs` on the archive, it will list the contents of both. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1597762 Title: intel-microcode initramfs-tools hooks mangle initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1557989] Re: having btrfs installed as the fs is causing a crash when trying to install the intel-microcode package
I have seen this same problem affect a VMware VM running on paravirtualized hardware. Removing the intel-microcode package and regenerating the initramfs fixed the problem. The root filesystem for these machines is btrfs. I suspect, however, that this may be a red herring; other machines with an identical configuration have worked elsewhere on a range of desktop hardware, so I suspect the problem may be isolated to a subset of machines, e.g. those with a particular CPU revision. /proc/cpuinfo on the virtualized machine I seen this problem on reads as follows: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz stepping: 4 microcode : 0x427 cpu MHz : 2200.000 cache size : 25600 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm epb fsgsbase smep dtherm ida arat pln pts bugs: bogomips: 4400.00 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1557989 Title: having btrfs installed as the fs is causing a crash when trying to install the intel-microcode package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1557989/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611816] [NEW] pam_cifscreds.so not supplied in package
Public bug reported:
The cifs-utils source package contains the pam_cifscreds.so PAM module;
however, this is not built and supplied in a resulting binary package.
This is necessary functionality for our local managed deployment.
We have worked around this issue by building our own patched version of
the package; however, this is liable to be clobbered by any future
upstream updates. Hence, it would be valuable if our modifications, or
some variant of them, could be adopted upstream.
The changes required are minimal; simply add libpam0g-dev to Build-
Depends, and add some appropriate flags to ./configure in debian/rules
to ensure the requisite library is built and installed in the correct
location.
See attached patch.
** Affects: cifs-utils (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "Suggested modifications to debian/{rules,control}"
https://bugs.launchpad.net/bugs/1611816/+attachment/4718396/+files/patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1611816
Title:
pam_cifscreds.so not supplied in package
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1611816/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1599459] [NEW] cannot bootstrap from repositories without InRelease files when --debian-installer set
Public bug reported:
Version: 1.0.78+nmu1ubuntu1
I am using debootstrap in my own minimal system bootstrapper, and am
making use of the progress information reported to FH 3 as enabled by
the --debian-installer command-line flag.
Unfortunately, using this flag causes the behaviour of debootstrap to
change, specifically in its handling of InRelease / Release files.
During normal operation, debootstrap will first attempt to fetch an
InRelease file from the repository; if this is unavailable, i.e. the
fetch fails with 404, then debootstrap will normally fall back to
fetching a Release file instead. Indeed, this is the behaviour of
debootstrap if --debian-installer is not passed on the command-line.
debootstrap uses the wgetprogress() function to fetch these URLs. It
reads:
wgetprogress () {
[ ! "$VERBOSE" ] && QSWITCH="-q"
local ret=0
if [ "$USE_DEBIANINSTALLER_INTERACTION" ] && [ "$PROGRESS_NEXT" ]; then
wget "$@" 2>&1 >/dev/null | $PKGDETAILS "WGET%" $PROGRESS_NOW
$PROGRESS_NEXT $PROGRESS_END >&3
ret=$?
else
wget $QSWITCH "$@"
ret=$?
fi
return $ret
}
When the --debian-installer command-line flag is set, the first path of
the if branch will be taken - running the output of wget through a pipe,
so that the $PKGDETAILS command can be used to parse progress
information provided by wget and report it to FH 3 in a format usable by
debian-installer.
However, if the URL passed to wget returns 404, then while the wget command
will fail, the $PKGDETAILS command, and thus the pipeline as a whole, does not,
and the wgetprocess () function thus erroneously returns success.
As a consequence, debootstrap does not fall back to fetching and using a
Release file as it should in this case, and the bootstrapping attempt as a
whole fails.
Because this is a POSIX shell-script, I don't believe there is a
straightforward mechanism to fetch the exit status of the wget command when it
is part of a pipeline. (See: http://cfajohnson.com/shell/cus-faq-2.html#Q11).
It might be possible to enhance the code invoked by $PKGDETAILS to return a
fatal exit status if it does not definitely see a successful file retrieval?
A more direct work-around is to modify this function to unconditionally
use the second code path that does not attempt to invoke wget as part of
a pipeline. However, this does mean that you lose out on intra-file
download progress reporting.
** Affects: debootstrap (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Version: 1.0.78+nmu1ubuntu1
- I am using debootstrap in my own minimal system bootstrapper, and am making
use
- of the progress information reported to FH 3 as enabled by the
- --debian-installer command-line flag.
+ I am using debootstrap in my own minimal system bootstrapper, and am
+ making use of the progress information reported to FH 3 as enabled by
+ the --debian-installer command-line flag.
- Unfortunately, using this flag causes the behaviour of debootstrap to change,
- specifically in its handling of InRelease / Release files.
+ Unfortunately, using this flag causes the behaviour of debootstrap to
+ change, specifically in its handling of InRelease / Release files.
- During normal operation, debootstrap will first attempt to fetch an InRelease
- file from the repository; if this is unavailable, i.e. the fetch fails with
- 404, then debootstrap will normally fall back to fetching a Release file
- instead. Indeed, this is the behaviour of debootstrap if --debian-installer
is
- not passed on the command-line.
+ During normal operation, debootstrap will first attempt to fetch an
+ InRelease file from the repository; if this is unavailable, i.e. the
+ fetch fails with 404, then debootstrap will normally fall back to
+ fetching a Release file instead. Indeed, this is the behaviour of
+ debootstrap if --debian-installer is not passed on the command-line.
debootstrap uses the wgetprogress() function to fetch these URLs. It
reads:
wgetprogress () {
- [ ! "$VERBOSE" ] && QSWITCH="-q"
- local ret=0
- if [ "$USE_DEBIANINSTALLER_INTERACTION" ] && [ "$PROGRESS_NEXT" ];
then
- wget "$@" 2>&1 >/dev/null | $PKGDETAILS "WGET%" $PROGRESS_NOW
$PROGRESS_NEXT $PROGRESS_END >&3
- ret=$?
- else
- wget $QSWITCH "$@"
- ret=$?
- fi
- return $ret
+ [ ! "$VERBOSE" ] && QSWITCH="-q"
+ local ret=0
+ if [ "$USE_DEBIANINSTALLER_INTERACTION" ] && [ "$PROGRESS_NEXT" ];
then
+ wget "$@" 2>&1 >/dev/null | $PKGDETAILS "WGET%" $PROGRESS_NOW
$PROGRESS_NEXT $PROGRESS_END >&3
+ ret=$?
+ else
+ wget $QSWITCH "$@"
+ ret=$?
+ fi
+ return $ret
}
- When the --debian-installer command-line flag is set, the first path of the if
-
[Bug 561210] Re: Writing big files to NFS target causes system lock up
Hi Thag, I don't know if this helps you, but I'm currently running NFS servers and clients successfully on 10.04 after having replaced the kernel with Linus's upstream 2.6.35.6. When testing with 2.6.35, enabling Forced pre-emption appeared to expose similar in-kernel deadlocking bugs which did not occur with just voluntary pre-emption enabled. Note that some earlier point releases of 2.6.35 did not *serve* NFS properly from volumes backed by XFS, and would spuriously return Stale NFS filehandle for inodes which were valid; I'd recommend using stable release .6 or later if you're running in a similar configuration. Finally, I'm sympathetic towards the Ubuntu chaps -- they're trying to roll full distribution releases every 6 months to a pre-determined schedule with (what appears to be) not enough manpower and not enough time to push patches back upstream. They're going to drop things.. -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585657] Re: Transfering large files to nfs mount causes system freeze
Using async is not a viable workaround. From `man exports`: async This option allows the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage (e.g. disc drive). Using this option usually improves performance, but at the cost that an unclean server restart (i.e. a crash) can cause data to be lost or corrupted. The fact that using 'async' results in higher performance is not a surprise as it is much more careful with data-handling. The fact that (according to the forum thread) enabling it happens not to trigger this particular bug is perhaps interesting from a debugging perspective, but not an acceptable solution to the problem for most organisations. If need to make a large file for testing, `dd if=/dev/zero of=my-large- file bs=1M count=$SIZE` will make you an arbitrarily-sized file containing all-zeroes. (Other nodes in /dev may well produce more interesting output..) -- Transfering large files to nfs mount causes system freeze https://bugs.launchpad.net/bugs/585657 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 561210] Re: Writing big files to NFS target causes system lock up
I've compiled up and retried my test transfers with Linus's current latest RC, 2.6.35-rc6, and found that this problem does not recur. -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585657] Re: Transfering large files to nfs mount causes system freeze
This appears to be a duplicate of Launchpad bug #561210. -- Transfering large files to nfs mount causes system freeze https://bugs.launchpad.net/bugs/585657 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 561210] Re: Writing big files to NFS target causes system lock up
Applying the patch referenced in the previous comment, the situation with regards to NFS deadlocking is improved -- the local terminal no- longer locks up -- but there are continued issues with processes blocking in 'D' (disk-wait) when they should not. (For example, automounted NFS volumes not involved in a transfer-in- progress which try to automatically unmount after a period of inactivity will have their 'umount' processes block in disk-wait until the transfer has completed.) -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 561210] Re: Writing big files to NFS target causes system lock up
And, indeed, if the umount process is stuck for long enough, the following kernel stack-trace is emitted: Jul 26 21:38:49 illustrious kernel: [ 838.729063] INFO: task umount.nfs:2570 blocked for more than 120 seconds. Jul 26 21:38:49 illustrious kernel: [ 838.729069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Jul 26 21:38:49 illustrious kernel: [ 838.729073] umount.nfsD 0 2570 1 0x Jul 26 21:38:49 illustrious kernel: [ 838.729080] 8801d5747d98 0086 00015bc0 00015bc0 Jul 26 21:38:49 illustrious kernel: [ 838.729087] 880210ec03c0 8801d5747fd8 00015bc0 880210ec Jul 26 21:38:49 illustrious kernel: [ 838.729092] 00015bc0 8801d5747fd8 00015bc0 880210ec03c0 Jul 26 21:38:49 illustrious kernel: [ 838.729098] Call Trace: Jul 26 21:38:49 illustrious kernel: [ 838.729110] [811650d0] ? bdi_sched_wait+0x0/0x20 Jul 26 21:38:49 illustrious kernel: [ 838.729115] [811650de] bdi_sched_wait+0xe/0x20 Jul 26 21:38:49 illustrious kernel: [ 838.729123] [8153f3af] __wait_on_bit+0x5f/0x90 Jul 26 21:38:49 illustrious kernel: [ 838.729127] [811650d0] ? bdi_sched_wait+0x0/0x20 Jul 26 21:38:49 illustrious kernel: [ 838.729132] [8153f458] out_of_line_wait_on_bit+0x78/0x90 Jul 26 21:38:49 illustrious kernel: [ 838.729140] [81085360] ? wake_bit_function+0x0/0x40 Jul 26 21:38:49 illustrious kernel: [ 838.729144] [81165094] ? bdi_queue_work+0xa4/0xe0 Jul 26 21:38:49 illustrious kernel: [ 838.729149] [8116640f] bdi_sync_writeback+0x6f/0x80 Jul 26 21:38:49 illustrious kernel: [ 838.729154] [81166440] sync_inodes_sb+0x20/0x30 Jul 26 21:38:49 illustrious kernel: [ 838.729160] [81169f12] __sync_filesystem+0x82/0x90 Jul 26 21:38:49 illustrious kernel: [ 838.729164] [81169ff9] sync_filesystems+0xd9/0x130 Jul 26 21:38:49 illustrious kernel: [ 838.729171] [8115ece1] sys_umount+0xb1/0xd0 Jul 26 21:38:49 illustrious kernel: [ 838.729178] [810131b2] system_call_fastpath+0x16/0x1b I've also identified that my test NFS mount was using UDP, and performs several times *better* in terms of IO throughput when switched to TCP operation. This lack of performance (and responsiveness) may have been masking some other issues, so I'll use TCP for future testing. -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 561210] Re: Writing big files to NFS target causes system lock up
(My test machine eventually unblocked when the 90GB NFS transfer finally finished. Still, that took a long time, and it was totally unusable until then.) Checking the current kernel sources, the kernel patches referenced in bug #585657 are clearly already applied. Reviewing recent development history, it appears this bug entry (patch at end) might also be relevant: https://bugzilla.kernel.org/show_bug.cgi?id=16056 I'm going to try testing that patch locally to see if it fixes this particular problem. ** Bug watch added: Linux Kernel Bug Tracker #16056 http://bugzilla.kernel.org/show_bug.cgi?id=16056 -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 561210] Re: Writing big files to NFS target causes system lock up
Just ran into this bug, affecting me on a new Lucid 64-bit install. Memory exhaustion is unlikely, as the machine has 8GB of RAM and a fast network link. This may be related to bug #585657. Remote SSH still works, and the NFS transfer I started a couple of hours ago is still running, slowly, though a process-listing blocks and both X and the console is completely unusable. (Which is a bit of a showstopper for rolling out a few hundred Lucid- based desktops..) -- Writing big files to NFS target causes system lock up https://bugs.launchpad.net/bugs/561210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
Indeed, still broken in Jaunty. A backport of the current Karmic package (which should be a trivial rebuild) would be most welcome. -- Avahi causing mt-daap to segfault https://bugs.launchpad.net/bugs/343069 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 380571] Re: package alsa-base 1.0.19.df sg-3ubuntu1 failed to install/upgrade: podproces pre-ins tallation script zwrócił kod błędu 2
I can confirm this error, and have identified the cause: there is a typo in the preinst script of this new package. On my (English, 64-bit) system, I see: Preparing to replace alsa-base 1.0.19.dfsg-3ubuntu1 (using .../alsa-base_1.0.20+dfsg-1ubuntu1_all.deb) ... dpkg (subprocess): unable to execute new pre-installation script: Exec format error dpkg: error processing /var/cache/apt/archives/alsa-base_1.0.20+dfsg-1ubuntu1_all.deb (--unpack): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/alsa-base_1.0.20+dfsg-1ubuntu1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Manually unpacking the deb file with `ar`, and untarring the resulting control.tar.gz, I find that the pre-inst script inside the package begins: \#!/bin/sh Which is clearly wrong. Cheers, David -- package alsa-base 1.0.19.dfsg-3ubuntu1 failed to install/upgrade: podproces pre-installation script zwrócił kod błędu 2 https://bugs.launchpad.net/bugs/380571 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 371061] Re: Assertion '(unsigned) data.input_frames_used == in_n_frames' failed at pulsecore/resampler.c:1284, function libsamplerate_resample(). Aborting.
Commenting out the line : resample-method = src-linear ... in /etc/pulse/daemon.conf, and restarting, results in crash-free pulseaudio. Cheers, David -- Assertion '(unsigned) data.input_frames_used == in_n_frames' failed at pulsecore/resampler.c:1284, function libsamplerate_resample(). Aborting. https://bugs.launchpad.net/bugs/371061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 371061] Re: Assertion '(unsigned) data.input_frames_used == in_n_frames' failed at pulsecore/resampler.c:1284, function libsamplerate_resample(). Aborting.
I am also having this problem on a machine I upgraded from Jaunty to Karmic today (Mon May 18th); log from PulseAudio - attached. The bug does not always trigger; when playing audio from Banshee, approximately one attempted track playback in 10 will succeed. This is a regression from Jaunty. This also impacts Flash playback in Firefox, and can lead to Flash crashing the browser. ** Attachment added: PulseAudio server log #2 http://launchpadlibrarian.net/26887328/pulse.log -- Assertion '(unsigned) data.input_frames_used == in_n_frames' failed at pulsecore/resampler.c:1284, function libsamplerate_resample(). Aborting. https://bugs.launchpad.net/bugs/371061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 353914] [NEW] udev rule needed to support Nokia 5800 XpressMusic (attached)
Public bug reported: Greetings, The Nokia 5800 XpressMusic isn't listed in /lib/udev/rules.d/45-libmtp8.rules, preventing its use as an MTP device. A patch against current the version of libmtp8 (0.3.0-1ubuntu3) in Jaunty is supplied which adds the necessary entires. Cheers, David ** Affects: libmtp (Ubuntu) Importance: Undecided Status: New -- udev rule needed to support Nokia 5800 XpressMusic (attached) https://bugs.launchpad.net/bugs/353914 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 353914] Re: udev rule needed to support Nokia 5800 XpressMusic (attached)
** Attachment added: Update to 45-libmtp8.rules http://launchpadlibrarian.net/24701154/45-libmtp8.rules.patch -- udev rule needed to support Nokia 5800 XpressMusic (attached) https://bugs.launchpad.net/bugs/353914 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 353914] Re: udev rule needed to support Nokia 5800 XpressMusic (attached)
Aha, this appears to already be included upstream; see: https://bugs.launchpad.net/bugs/353914 Unfortunately, even with that, early firmware revisions for the 5800 don't appear to be that good for MTP support; hopefully Orange will release Nokia's latest update soon... Cheers, David -- udev rule needed to support Nokia 5800 XpressMusic (attached) https://bugs.launchpad.net/bugs/353914 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 353914] Re: udev rule needed to support Nokia 5800 XpressMusic (attached)
Sorry, wrong clipboard, wrong link; that should have read: http://sourceforge.net/tracker/index.php?func=detailaid=2577539group_id=158745atid=809061 Cheers, David ** Bug watch added: SourceForge.net Tracker #2577539 http://sourceforge.net/support/tracker.php?aid=2577539 -- udev rule needed to support Nokia 5800 XpressMusic (attached) https://bugs.launchpad.net/bugs/353914 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 332270] Re: [jaunty] doesn't boot anymore after udev upgrade
Greetings, I also have this problem, and I think I might be able to shed some light on what's going wrong. I'm running a slightly unusual configuration -- my root filesystem on my ThinkPad is on LVM, as it my home filesystem. Only a small /boot is stored on a conventional DOS partition. When I boot the latest Jaunty with the 138-1 udev updates, the boot stalls -- with constant disk activity -- during the initial udev device discovery stage. I found that pressing CTRL-ALT-DELETE interrupts this process, but rather than rebooting the machine, causes the initial udev device settling process to abort and the boot sequence to continue. The constant disk activity is caused by the LVM udev rules constantly firing. I note from the changelog that udev introduces a new mechanism: it uses inotify to track changes to block devices; this is so that it can keep /dev/by-uuid/* and /dev/by-label/* links up to date. I hypothesize that the constant disk activity on the (root) LVM filesystem is causing the LVM udev rules to constantly fire, thus resulting in more disk activity... which never (or seldom) stops long enough for the loop to be broken. And because of this loop, the udev settling process never terminates, so the machine is unable to finish booting. Reverting the use-inotify-to-watch-LVM-volumes addition to udev would probably be a good idea until this can be sorted out. In the mean time, I'm going to see if I can find a binary package to downgrade to... Cheers, David -- [jaunty] doesn't boot anymore after udev upgrade https://bugs.launchpad.net/bugs/332270 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 316335] [NEW] lldpd fails after reboot: /var/run/lldpd created in postinst, not by initscript
Public bug reported: Binary package hint: lldpd Greetings, The lldpd package creates /var/run/lldpd -- which lldpd uses as a chroot() jail -- in the postinst script. However, /var/run on modern systems is a tmpfs which is dynamically generated at boot-time: this directory is not preserved over reboots. As a result, lldpd will fail to run after a reboot, because /var/run/lldpd does not exist. The correct fix is to create the /var/run/lldpd directory as necessary as part of the start() branch of the init.d script, rather than creating it just once in the package postinst script. (This seems to be a not-uncommon bug. Is there a lintian rule for catching this kind of error?) Cheers, David ** Affects: lldpd (Ubuntu) Importance: Undecided Status: New -- lldpd fails after reboot: /var/run/lldpd created in postinst, not by initscript https://bugs.launchpad.net/bugs/316335 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 316335] Re: lldpd fails after reboot: /var/run/lldpd created in postinst, not by initscript
** Also affects: lldpd (Debian) Importance: Undecided Status: New -- lldpd fails after reboot: /var/run/lldpd created in postinst, not by initscript https://bugs.launchpad.net/bugs/316335 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315117] [NEW] [Jaunty] Boot failure when root on LVM: watershed missing in initramfs
Public bug reported: Binary package hint: lvm2 Greetings, With the latest updates, Jaunty systems running all updates as of Jan 8th 2009 fail to boot when the root filesystem is hosted on LVM. This appears to be because the 'watershed' command, which lvm2 now relies upon in its udev rules, is not installed into the initramfs. This prevents the root lvm volume from being initialized, resulting in a drop to the initramfs shell. The fix is straightforward: update the initramfs hook scripts to install the watershed binary at initramfs-time, and regenerate initramfs images as necessary. (I'm not sure whether this is a watershed or an lvm2 bug -- trying lvm2.) Cheers, David ** Affects: lvm2 (Ubuntu) Importance: Undecided Status: New -- [Jaunty] Boot failure when root on LVM: watershed missing in initramfs https://bugs.launchpad.net/bugs/315117 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 287701] Re: [intrepid] USB mass-storage doesn't mount automatically with nokia 5610 express with 2.6.27-7 latest
This bug also affects my Nokia 6300. See also: http://bugzilla.kernel.org/show_bug.cgi?id=11768 http://ubuntuforums.org/showthread.php?t=963711 -- [intrepid] USB mass-storage doesn't mount automatically with nokia 5610 express with 2.6.27-7 latest https://bugs.launchpad.net/bugs/287701 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 270698] [NEW] [Intrepid] ./configure arguments need --localstatedir=var
Public bug reported: Binary package hint: samba4 The new samba4 packages do not function correctly; attempting to start smbd via the init script appears to succeed, but no smbd daemons are left running. This is because the smbd binary is built with --localstatedir effectively equivalent to /usr/var, which does not exist. As a result, smbd terminates almost immediately after it begins execution. This can be demonstrated by running `smbd --debug-stderr` as root: # smbd --debug-stderr smbd version 4.0.0alpha6-GIT-7e90cc1 started. Copyright Andrew Tridgell and the Samba Team 1992-2008 ERROR: can't open /usr/var/run/samba/smbd.pid: Error was No such file or directory # Adding: --localstatedir=/var ... to the configure incantation in debian/rules _should_ fix the problem, I'm trying a test build now. Cheers, David ** Affects: samba4 (Ubuntu) Importance: Undecided Status: New -- [Intrepid] ./configure arguments need --localstatedir=var https://bugs.launchpad.net/bugs/270698 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 132468] Nameservice abstraction should also include /var/run/resolvconf/resolv.conf
Public bug reported: Binary package hint: apparmor The Nameservice abstraction configuration file (/etc/apparmor.d/abstractions/nameservice) permits reads access to (amongst other paths) /etc/resolv.conf. However, on systems using resolvconf, this is a symbolic link to /etc/resolvconf/run/resolv.conf -- where /etc/resolvconf/run itself is a symlink to /var/run/resolvconf. Apparmor does not follow symlinks; as a result, apparmor'd applications which include the nameservice abstraction in their policy definition are unable to read /var/run/resolvconf/resolv.conf. This is a bug, and (for example) breaks CUPS. Adding /var/run/resolvconf/resolv.conf to /etc/apparmor.d/abstractions/nameservice corrects this problem. This should probably become the default. ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New -- Nameservice abstraction should also include /var/run/resolvconf/resolv.conf https://bugs.launchpad.net/bugs/132468 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 130728] Re: trackerd crashed with signal 5 in pango_default_break()
Yes, fixed - crash no-longer occurs. -- trackerd crashed with signal 5 in pango_default_break() https://bugs.launchpad.net/bugs/130728 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 130728] Re: trackerd crashed with signal 5 in pango_default_break()
Valgrind output attached. (Note: trackerd failed to terminate when valgrind issued a SIGILL. As a result, it got stuck in a loop. It was necessary to kill -9 the memcheck process; the log attached shows all the useful data.) ** Attachment added: Valgrind output http://launchpadlibrarian.net/8712656/trackerd-valgrind.log.21289.cut -- trackerd crashed with signal 5 in pango_default_break() https://bugs.launchpad.net/bugs/130728 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 130728] Re: trackerd crashed with signal 5 in pango_default_break()
GDB backtrace attached. (Note: STDOUT from trackerd process edited to remove private information.) ** Attachment added: GDB backtrace. http://launchpadlibrarian.net/8712664/gdb-trackerd.txt -- trackerd crashed with signal 5 in pango_default_break() https://bugs.launchpad.net/bugs/130728 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116808] Re: White boxes instead of shadows on Intel 945 (-intel driver)
Also observing here, new bug as of 0.5.0 packages on Intel GMA945. This appears like it may be a problem with gtk-window-decorator; ~/.xsession-errors is indicating the following: ***MEMORY-WARNING***: gtk-window-decorator[29262]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... (Perhaps bizarrely, there are other similar warnings for other GTK-using tools, such as gnome-terminal.) Cheers, David -- White boxes instead of shadows on Intel 945 (-intel driver) https://bugs.launchpad.net/bugs/116808 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 73698] Re: Panel applets on top panel blink in as they redrawn while running full screen app
I also observe this; however, this is when running Feisty on an Intel GMA950 chipset. This only appears to affect GL applications, such as Blender. Dragging windows containing GL output also produces artifacts. Cheers, David -- Panel applets on top panel blink in as they redrawn while running full screen app https://bugs.launchpad.net/bugs/73698 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 96695] Re: [apport] compiz.real crashed with SIGSEGV (at initialisation-time)
*** This bug is a duplicate of bug 97661 *** https://bugs.launchpad.net/bugs/97661 ** This bug has been marked a duplicate of bug 97661 Loading any Compiz-Extra plugins causes Compiz to segfault -- [apport] compiz.real crashed with SIGSEGV (at initialisation-time) https://bugs.launchpad.net/bugs/96695 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 99934] Stalls in infinite loop when creating new ElGamel subkey
Public bug reported:
Binary package hint: seahorse
Greetings,
I wish to report an infinite-loop bug in Seahorse.
Goal:
- Create new sub-keys for primary PGP identity.
Method:
- Select primary identity from main UI, select Properties.
- Select Details tab.
- Expand sub-keys section.
- Select Add
- Update dialog:
+ key type: ElGamel
+ key length: 4096 (though tried with other values.)
+ untick never expires, specify expiration date of 01/Apr/2008
- Select OK.
- Enter passphrase; select OK.
- *hang*
Failure mode:
- Seahorse UI stops respoding. Processor utilization increases substantially.
A new GPG process has been spawned; however strace suggests that neither
Seahorse nor GPG are making progress:
Seahorse strace output:
[...]
select(21, [16 20], [], NULL, {1, 0}) = 1 (in [16], left {1, 0})
select(17, [16], [], NULL, {0, 0}) = 1 (in [16], left {0, 0})
read(16, [GNUPG:] GOT_IT\n, 1024) = 16
select(21, [16 20], [], NULL, {1, 0}) = 1 (in [16], left {1, 0})
select(17, [16], [], NULL, {0, 0}) = 1 (in [16], left {0, 0})
read(16, [GNUPG:] GET_LINE keygen.algo\n, 1024) = 30
fcntl64(19, F_GETFL)= 0x801 (flags O_WRONLY|O_NONBLOCK)
fcntl64(19, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
select(21, [16 20], [19], NULL, {1, 0}) = 1 (out [19], left {1, 0})
select(20, [], [19], NULL, {0, 0}) = 1 (out [19], left {0, 0})
write(19, 3, 1) = 1
write(19, \n, 1) = 1
select(21, [16 20], [], NULL, {1, 0}) = 1 (in [16], left {1, 0})
select(17, [16], [], NULL, {0, 0}) = 1 (in [16], left {0, 0})
read(16, [GNUPG:] GOT_IT\n, 1024) = 16
select(21, [16 20], [], NULL, {1, 0}) = 1 (in [16], left {1, 0})
select(17, [16], [], NULL, {0, 0}) = 1 (in [16], left {0, 0})
read(16, [GNUPG:] GET_LINE keygen.algo\n, 1024) = 30
fcntl64(19, F_GETFL)= 0x801 (flags O_WRONLY|O_NONBLOCK)
fcntl64(19, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
select(21, [16 20], [19], NULL, {1, 0}) = 1 (out [19], left {1, 0})
select(20, [], [19], NULL, {0, 0}) = 1 (out [19], left {0, 0})
write(19, 3, 1) = 1
write(19, \n, 1) = 1
[...]
Seahorse ltrace output:
[...]
write(19, \n, 1)
= 1
g_str_equal(0x83c1650, 0x80af3d2, 0xbfb99ca8, 0xb7bc71a4, 0x8111af8)
= 1
g_strdup_vprintf(0x80ab453, 0xbfb99c78, 0, 0xb7bc4551, 0)
= 0x8463060
strlen(3)
= 1
write(19, 3, 1)
= 1
free(0x8463060)
= void
strlen(\n)
[...]
GPG strace output:
[...]
write(17, [GNUPG:] GOT_IT\n, 16) = 16
write(17, [GNUPG:] GET_LINE keygen.algo\n, 30) = 30
read(18, 3, 1)= 1
read(18, \n, 1) = 1
write(17, [GNUPG:] GOT_IT\n, 16) = 16
write(17, [GNUPG:] GET_LINE keygen.algo\n, 30) = 30
read(18, 3, 1)= 1
read(18, \n, 1) = 1
write(17, [GNUPG:] GOT_IT\n, 16) = 16
write(17, [GNUPG:] GET_LINE keygen.algo\n, 30) = 30
[...]
GPG ltrace output:
[...]
malloc(300)
= 0x8129fc8
read(18, 3, 1)
= 1
read(18, \n, 1)
= 1
fwrite([GNUPG:] , 1, 9, 0x8117050)
= 9
fputs(GOT_IT, 0x8117050)
= 1
_IO_putc('\n', 0x8117050)
= 10
fflush(0x8117050)
= 0
__strtol_internal(3, NULL, 10)
= 3
free(0x8129fc8)
= void
dcgettext(0, 0x80f7186, 5, 0, 0xbfa906a4)
= 0x80f7186
dcgettext(0, 0x80f6ed7, 5, 0, 0xbfa906a4)
= 0x80f6ed7
fflush(0xb7f584c0)
= 0
fwrite([GNUPG:] , 1, 9, 0x8117050)
= 9
fputs(GET_LINE, 0x8117050)
= 1
_IO_putc(' ', 0x8117050)
= 32
_IO_putc('k', 0x8117050)
= 107
_IO_putc('e', 0x8117050)
= 101
_IO_putc('y', 0x8117050)
= 121
_IO_putc('g', 0x8117050)
= 103
_IO_putc('e', 0x8117050)
[Bug 96695] Re: [apport] compiz.real crashed with SIGSEGV (at initialisation-time)
** Attachment added: CoreDump.gz http://librarian.launchpad.net/6988696/CoreDump.gz ** Attachment added: Dependencies.txt http://librarian.launchpad.net/6988697/Dependencies.txt ** Attachment added: ProcMaps.txt http://librarian.launchpad.net/6988698/ProcMaps.txt ** Attachment added: ProcStatus.txt http://librarian.launchpad.net/6988699/ProcStatus.txt ** Attachment added: Registers.txt http://librarian.launchpad.net/6988700/Registers.txt -- [apport] compiz.real crashed with SIGSEGV (at initialisation-time) https://launchpad.net/bugs/96695 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 96695] [apport] compiz.real crashed with SIGSEGV (at initialisation-time)
Public bug reported: Binary package hint: compiz SIG11 occurs at initialisation-time. ProblemType: Crash Architecture: i386 CrashCounter: 1 Date: Mon Mar 26 23:03:33 2007 Disassembly: 0xb3841c9e: DistroRelease: Ubuntu 7.04 ExecutablePath: /usr/bin/compiz.real Package: compiz-core 1:0.3.6-1ubuntu9 [modified: usr/bin/compiz] PackageArchitecture: i386 ProcCmdline: /usr/bin/compiz.real --no-fbo --ignore-desktop-hints --replace gconf gconf ProcCwd: /home/dwm ProcEnviron: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games SHELL=/bin/bash Signal: 11 SourcePackage: compiz Stacktrace: #0 0xb3841c9e in ?? () StacktraceTop: ?? () ThreadStacktrace: Uname: Linux excalibur 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux UserGroups: adm admin audio cdrom dialout dip floppy lpadmin plugdev scanner video ** Affects: compiz (Ubuntu) Importance: Undecided Status: Unconfirmed -- [apport] compiz.real crashed with SIGSEGV (at initialisation-time) https://launchpad.net/bugs/96695 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 90852] Re: [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem?
Daniel Holbach wrote: Thanks for your bug report. Can you get a more recent crash report for this problem (with the newest updates)? Hello Daniel, Many thanks for following up. I tried repeating the experiment using Debian's 1.5.0.3 package on another host a while ago and found that instead of crashing with SIG25 when the pack file-size reaches 2GB, it instead appears to instantly finish processing and terminate. However, the pack-file has not been constructed and installed correctly; if I re-run git-pack-objects the process repeats again. (Normally, it should notice that the available pack file is up to date and quickly terminate.) The following mailing list entry appears to acknowledge that pack files =2GB in size will fail: http://marc.info/?l=gitm=117347628506244w=2 From reading the thread, removing this limit will require a non-backwards compatible change to the pack file format. --- So, I can try to repeat the problem on my current Feisty installation and upload an updated crash report if you still think that's necessary. (The repacking operation takes a fair amount of time to execute, so it may take me a little while..) However, given the above, you might prefer to defer until upstream developers have readied a fix. Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London -- [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem? https://launchpad.net/bugs/90852 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 90852] [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem?
Public bug reported: Binary package hint: git-core I am experimenting with using git to manage large media files. Whilst running git-repack on a music repository containing FLAC files, SIG25 occurred -- signal(7) indicates that this is SIGXFSZ, or File size limit exceeded. Perhaps this is because the packfile is exceeding 2GB in size? This is a fairly serious problem because repository cloning requires the ability to construct pack files. ProblemType: Crash Architecture: i386 Date: Fri Mar 9 13:03:56 2007 Disassembly: 0xb7fd0410: DistroRelease: Ubuntu 7.04 ExecutablePath: /usr/bin/git-pack-objects Package: git-core 1:1.4.4.2-1build1 PackageArchitecture: i386 ProcCmdline: git-pack-objects --non-empty --all --unpacked --incremental --local .git/.tmp-14873-pack ProcCwd: /home/dwm/Media/Audio/Music ProcEnviron: PATH=/home/dwm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games SHELL=/bin/bash Signal: 25 SourcePackage: git-core StacktraceTop: ?? () ?? () ?? () ?? () write () from /lib/tls/i686/cmov/libc.so.6 Uname: Linux excalibur 2.6.20-4-generic #2 SMP Fri Jan 5 04:31:55 UTC 2007 i686 GNU/Linux UserGroups: adm admin audio cdrom dialout dip floppy lpadmin plugdev scanner video ** Affects: git-core (Ubuntu) Importance: Undecided Status: Unconfirmed -- [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem? https://launchpad.net/bugs/90852 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 90852] Re: [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem?
** Attachment added: CoreDump.gz http://librarian.launchpad.net/6718534/CoreDump.gz ** Attachment added: Dependencies.txt http://librarian.launchpad.net/6718535/Dependencies.txt ** Attachment added: ProcMaps.txt http://librarian.launchpad.net/6718536/ProcMaps.txt ** Attachment added: ProcStatus.txt http://librarian.launchpad.net/6718537/ProcStatus.txt ** Attachment added: Registers.txt http://librarian.launchpad.net/6718538/Registers.txt ** Attachment added: Stacktrace.txt http://librarian.launchpad.net/6718539/Stacktrace.txt ** Attachment added: ThreadStacktrace.txt http://librarian.launchpad.net/6718540/ThreadStacktrace.txt -- [apport] git-pack-objects crashed with signal 25 - 2GB file addressing problem? https://launchpad.net/bugs/90852 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 70602] Dual-core Thinkpad fails to suspend with cpu governor active
Public bug reported: Binary package hint: linux-source-2.6.17 Greetings, I have found a bug in Ubuntu 6.10 / Edgy related to software-suspend. When sending my ThinkPad R60e to sleep (eg by closing the lid), the machine will sometimes fail to suspend correctly. After some experimentation, it appears that this is a kernel bug related to cpufreq governors. If a cpufreq governor other than performance is active (eg ondemand), then the laptop will usually fail to suspend properly. In this error case, the screen goes blank but the machine never enters a suspend mode, and can still be controlled with CTRL-ALT- DELETE, SysRq, etc. (There have been some lengthy discussions on LKML discussing the broken state of cpufreq locking - see http://lkml.org/lkml/2006/8/24/232) Installing the following scripts seems to reliably correct this problem: #!/bin/sh # /etc/acpi/suspend.d/01-cpu-governor.sh echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor #!/bin/sh # /etc/acpi/resume.d/01-cpu-governor.sh echo ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo ondemand /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London ** Affects: linux-source-2.6.17 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Dual-core Thinkpad fails to suspend with cpu governor active https://launchpad.net/bugs/70602 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 59570] Wacom extended input devices not found by gtk clients running inside Xgl
Public bug reported: Binary package hint: xserver-xgl Hi, I have a wacom tablet that works as an extended input device under Xorg -- Gimp, Inkscape et al can see it correctly and process stylus pressure and tilt values that are reported by the device. (Note that I had to reconfigure the standard Configured Mouse device entry to point at a device-specific /dev node rather than /dev/input/mice for this to be the case - but that's not the problem that I'm reporting.) If I reconfigure my machine to use Xgl rather than the standard Xorg X server, extended input devices are no-longer visible to X applications -- despite the fact that the server configuration is unchanged, and both of the X server logs in the Xgl configuration indicate that the Wacom drivers are loaded and the Wacom tablet detected. The end result is that, whilst the tablet can still function as a basic pointer device, the additional tilt and pressure information is not available. Google suggests that this is a not-uncommon problem (See [0],[1]), but I didn't see a bug open to track the issue. Cheers, David [0] http://www.lanterntorch.com/free-software/292/wacom-vs-xgl/ [1] http://ubuntuforums.org/showthread.php?p=1037873 ** Affects: xserver-xgl (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Wacom extended input devices not found by gtk clients running inside Xgl https://launchpad.net/bugs/59570 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
