Public bug reported:
Binary package hint: g++
Latest g++ in Hardy (4:4.2.3-1ubuntu6) still exhibits this bug from
upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
When compiled with "-g -O0", C++ constructors do not have valid
information about local variables.
If debugging with gd
I can confirm this too. I've copied the original report into the
upstream bug tracker (https://savannah.gnu.org/bugs/?25566).
--
All-registers view broken
https://bugs.launchpad.net/bugs/111723
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
Intrepid does not show this behaviour. The bug only affects Hardy
(which is an LTS release, so some kind of fix needs to be backported).
--
Modal dialog can be covered by another dialog
https://bugs.launchpad.net/bugs/312448
You received this bug notification because you are a member of Ubuntu
B
Public bug reported:
The handling of dialogs on the desktop is rather unusable in Hardy Heron
with latest updates applied.
This make Ubuntu rather poor for the naive user!
For example:
Create an ASCII text file on the desktop ("test.txt"). Make it
executable. Double click on it. A dialog app
I'm attaching lspci -vvnn and the Xorg.0.log.old from may last failed
attempt to hibernate and resume. The latter has an error (EE) message
at the end - perhaps this is meaningful to someone?
** Attachment added: "Xorg.0.log.old"
http://launchpadlibrarian.net/20138437/Xorg.0.log.old
--
Ubun
** Attachment added: "lspci-vvnn"
http://launchpadlibrarian.net/20138417/lspci-vvnn
--
Ubuntu hardy does not provide suspend or hibernate on Thinkpad laptop T61 with
NVidia
https://bugs.launchpad.net/bugs/200568
You received this bug notification because you are a member of Ubuntu
Bugs, whic
I also have a T61 with NVidia Quadro NVS 140M.
I have Hardy Heron (LTS) with all updates applied.
The strange thing is that using the open-source driver, I can resume
from Hibernate but not from Suspend.
Whereas using the proprietary NVidia driver (from
System/Administration/Hardware Drivers), I
** Description changed:
+ My nightly tripwire check has been failing since I reinstalled some
+ kernel modules at the beginning of November 2008.
- My nightly tripwire check has been failing since I reinstalled some kernel
modules at the beginning of November 2008.
+ I'm running tripwire 2.3.1
Public bug reported:
My nightly tripwire check has been failing since I reinstalled some kernel
modules at the beginning of November 2008.
strace -eopen,access,lstat,lstat64 tripwire -m c
lstat("/lib/modules/2.6.24-21-generic/ubuntu/wireless/wimax-i2400m/drivers/net/wimax/i2400m/i2400m.ko",
{
screem crashes for me too, fairly randomly, with the same assertion
failure.
I also see the following messages on startup, however the crash does not
happen (if at all) until I have been editing for some time.
(screem:32117): Gtk-WARNING **: Refusing to add non-unique action 'cancel drag'
to ac
Crashes still occur in screem 0.16.1-4.2 on Ubuntu 8.04 with all updates
applied (Oct 21 2008).
--
screem crashed after a while
https://bugs.launchpad.net/bugs/202964
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailin
I can confirm this happens for me. I attach Xorg.0.log for the failed
session.
The crash happens for both the "vesa" driver and the "nv" driver.
I get a bit further using the proprietary "nvidia" driver (no crash, but
fails to contact server and reports "Error 29"). But that is probably a
diffe
... More coffee needed - I meant Feisty. Gutsy has the regression.
--
mounting Luks encrypted USB-HDD does not work reliably
https://bugs.launchpad.net/bugs/148003
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mai
Unfortunately I still occasionally get the temporary-cryptsetup mapping
left around (as shown by sudo dmsetup ls), though this is much less
frequent now. I'm afraid that race conditions are probably endemic due
to the design of udev; the way it forks processes into the background it
seems like the
Looks like it maybe related to Bug #148003.
IMHO, it's a race between udev and cryptsetup (libdevmapper).
I "fixed" it by removing /etc/udev/rules.d/65-dmsetup.rules.
This file seems to have been introduced by a recent Ubuntu patch.
Presumably there was a good reason for it, but it causes havoc
Looks like Bug #148003.
IMHO, it's a race between udev and cryptsetup (libdevmapper).
I "fixed" it by removing /etc/udev/rules.d/65-dmsetup.rules.
This file seems to have been introduced by a recent Ubuntu patch.
Presumably there was a good reason for it, but it causes havoc.
--
[gutsy] [regr
Looks like Bug #148003.
IMHO, it's a race between udev and cryptsetup (libdevmapper).
I "fixed" it by removing /etc/udev/rules.d/65-dmsetup.rules.
This file seems to have been introduced by a recent Ubuntu patch.
Presumably there was a good reason for it, but it causes havoc.
--
LUKS partition
I have fixed this problem by REMOVING
/etc/udev/rules.d/65-dmsetup.rules. Now there are no stale devices, the
password dialog appears every time I insert the stick, and the volume is
auto-mounted reliably.
Fedora (7) does not have any analogous file and does not have any
problems with LUKS-encryp
This looks to be the same bug I have been trying to analyze in Ubuntu
bug #148003. It was reported there that the existence of this stale
device node often prevents auto-mounting of encrypted USB memory sticks,
etc.
There appears to be a race condition in the processes spawned by udev.
The file /
Horrid, Horrid! Handling of removable devices in Linux SUCKS!
It's all just too complicated, with a mess of kernel, udev, hal, gnome-
volume-manager, gnome-mount, cryptsetup... Lets have a single
monolithic kernel-based routine for the whole lot!
[Sorry, I just had to let off steam there, I have
It is possible that the problem lies with cryptsetup. Even when
manually performing the steps
cryptsetup luksOpen /dev/sdb1 luks
cryptsetup luksClose luks
I still end up with some "leaked" devices. These can cause the "already
setup" error. For example I have
/org/freedesktop/Hal/devices/volu
I suspect this is also related to bug #148003...
--
Gnome-mount will only mount encrypted partitions and not drives created with
cryptsetup/luks
https://bugs.launchpad.net/bugs/117011
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
I suspect this is also related to bug #117011...
--
mounting Luks encrypted USB-HDD does not work reliably
https://bugs.launchpad.net/bugs/148003
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-b
I strongly suspect this is a HAL issue, though I cannot confirm it.
This experience makes me suspect HAL:
I recompiled HAL with debugging enabled and optimization off. Then I
used gdb to step through lshal after the problem had been triggered.
Running lshal gave "Dumping N devices from the Glob
Stefan,
I think having two UUIDs is OK; as far as I know, the system should regard the
encrypted volume and the plaintext volume as separate objects (they correspond
to different devices, linked by the device mapper).
My experience with Feisty was better than yours - this stuff worked OK for me
Instead of rebooting, you may try
sudo /etc/init.d/dbus restart
This restarts dbus and a load of daemons which are dependent on it,
including HAL. This had the same effect as a reboot for me.
$ /usr/sbin/hald --version
HAL package version: 9000
I'm sorry Dave, I'm afraid I can't do that...
-
I have the same problems. First mount after reboot is OK. Subsequent
attempts either fail to popup the passphrase dialog or take the
passphrase but do not mount the drive.
In the case where the passphrase dialog did not appear, I attempted to
mount the volume by hand using
/usr/bin/gnome-mount --
27 matches
Mail list logo