Bug#929098: linux-image-4.19.0-5-amd64: No graphics with Radeon Vega 1.0

Hi, I can confirm this bug. The systems boots with 'nomodeset'. 0c:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c1) It works fine with linux-image-4.19.0-4-amd64 (4.19.28-2) and linux-image-5.0.0-trunk-amd64 (5.0.2-1~exp1)

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

On Sat, Jun 23, 2018 at 6:50 PM, Guilhem Moulin wrote: > In fact it's not related to the ‘decrypt_gnupg’ keyscript, the > “size=256” wrongly translates to `cryptsetup --size=256`, which sets the > size of the device to 256 512-bytes sectors instead of setting the key > size. This makes more sense

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

Hi, Sorry, the body was missing in the original message. I've been using the following line in crypttab to unlock the root volume in initrd and it's been working till version 2:2.0.2-1 included: /etc/crypttab root/dev/device /path/to/key.gpg cipher=aes-xts-plain64,size=256,hash=plain,i

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

Package: cryptsetup Version: 2:2.0.2-1 Severity: important /tmp/reportbug-cryptsetup-20180623-4415-imdw6ns_ -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'testing'), (700, 'stable'), (600, 'experimental'

Bug#736274: Data corruption on dm-crypt volumes over USB 3 (xhci-hcd)

On Tue, Jan 21, 2014 at 11:06 PM, Ben Hutchings wrote: > So far as I am aware, the write failure is properly reported (except > that the operation is retried and the failure logged many times, which > is also a known bug) and previously written data are readable. If > that is the case, I don't be

Bug#736274: Data corruption on dm-crypt volumes over USB 3 (xhci-hcd)

Package: linux-image-3.12-1-amd64 Version: 3.12.8-1 Severity: grave When you create a dm-crypt volume on an external drive attached to an USB 3 port, every write operation on it will corrupt its data and cause the drive to reset. I've tried three different SATA to USB 2 adapters and one SATA to U

Bug#584576: closed by Ari Pollak (Re: Bug#584576: Pidgin randomly crashes)

Disabling direct connections in the MSN account preferences solves the problem. It seems that it only occurs when both sides are behind NAT (and without port forwarding). HTH. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact

Bug#584576: closed by Ari Pollak (Re: Bug#584576: Pidgin randomly crashes)

It was not the specific contact, but the using of custom smileys. Pidgin will crash almost every time a custom smiley is received. This doesn't explain why it's crashing also with no dialog windows opened, maybe the same code is related to the management of contact icons or custom smileys in the ni

Bug#584576: closed by Ari Pollak (Re: Bug#584576: Pidgin randomly crashes)

On Sat, Jun 12, 2010 at 1:20 AM, Ari Pollak wrote: > Could you start pidgin -d and save the output somewhere, and try to > reproduce the crash? Can I assume this doesn't happen if you don't log > in to MSN? Yes, it seems to be related to the MSN protocol but, strangely, only to a particular conta

Bug#584576: closed by Ari Pollak (Re: Bug#584576: Pidgin randomly crashes)

This bug still affects me. In the meantime I collected some other backtraces. GNU gdb (GDB) 7.1-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. T

Bug#584576: Pidgin randomly crashes

On Fri, Jun 4, 2010 at 9:01 PM, Ari Pollak wrote: > Could you get another backtrace, but before running gdb, run this: export > MALLOC_CHECK_=2 > > And immediately after you enter gdb, run this: > handle SIGPIPE nostop noprint Here it is, it took a while to crash again, this time with a conversat

Bug#584576: Pidgin randomly crashes

On Fri, Jun 4, 2010 at 8:45 PM, Ari Pollak wrote: > The first backtrace looks like your system ran out of memory. Is this > possible? It would be strange: # free total used free sharedbuffers cached Mem: 40552843399136 656148 0 1911

Bug#584576: Pidgin randomly crashes

Package: pidgin Version: 2.7.1-1 Severity: important Pidgin randomly crashes without doing anything particular or anything at all. I left only two accounts enabled (msn and jabber), with no windows opened other than the main one and without using it and after a while it simply crashed again. I've