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
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
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
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
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),
** 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, which
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
--
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,
** 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
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
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
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
different
... 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
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
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]
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
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
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
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
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
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
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
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
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.
humour
$ /usr/sbin/hald --version
HAL package version: 9000
I'm sorry Dave, I'm afraid I can't do
27 matches
Mail list logo
