Bug#971371: Try disabling power management.
Your kernel stack trace looks similar to mine with an RX480 under a recent 5.8.x kernel. I solved that oops in the power management routines by turning power management off. Append "amdgpu.runpm=0 amdgpu.bapm=0 amdgpu.dpm=0 amdgpu.aspm=0" to your kernel boot parameters. In addition, you might also try to add "amdgpu.dc=0" which disables some new DisplayCore code for AMD GPU. -- Fruhwirth Clemens http://clemens.endorphin.org
Bug#512546: just binary patch it..
Binary patch PCI-IDs: dd bs=1 count=73332 if=e1000e.ko > head dd bs=1 skip=73334 if=e1000e.ko > tail echo -ne \\0336\\0020 > middle cat head middle tail > e1000e.ko Works only with the 105756 sized binary from Lenny i386 release CDs. You have to modprobe e1000e.ko manually, of course. I like Debian because it puts stability before features. But the difference between regular software features and hardware support is that there is no option of downgrading/keeping the older version. So go ahead and add the PCI-IDs; for hardware there is nothing noble about choosing "unsupported" over "not fully tested, please consider this experimental" .. and btw the drivers survived the Debian installation pretty well with this hack. -- Fruhwirth Clemens http://clemens.endorphin.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#460409: [Pkg-cryptsetup-devel] Bug#460409: [dm-crypt] Re: [EMAIL PROTECTED]: Bug#460409: cryptsetup: Cannot add Key to LUKS partition]
At Thu, 24 Jan 2008 17:09:19 +0100, Clemens Fruhwirth wrote: > Today, I'm busy, but tomorrow I can rework the sanity checking for the > luksAddKey issue. Feel free to merge your man page patch! Then I might roll > another pre.. Ok, I pushed all changes to SVN. Would you like to try? -- Fruhwirth Clemens - http://clemens.endorphin.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460409: [Pkg-cryptsetup-devel] Bug#460409: [dm-crypt] Re: [EMAIL PROTECTED]: Bug#460409: cryptsetup: Cannot add Key to LUKS partition]
At Wed, 23 Jan 2008 16:51:45 +0100, Jonas Meurer wrote: > btw, do you have pending changes which are not in the svn repository yet > (like the patch regarding slots from u.kuehn)? and what about releasing > cryptsetup 1.0.6? Yes, and his merged patch was sitting on my disk for about 1 month. I just commited it to SVN. Today, I'm busy, but tomorrow I can rework the sanity checking for the luksAddKey issue. Feel free to merge your man page patch! Then I might roll another pre.. -- Fruhwirth Clemens - http://clemens.endorphin.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460409: [dm-crypt] Re: [EMAIL PROTECTED]: [Pkg-cryptsetup-devel] Bug#460409: cryptsetup: Cannot add Key to LUKS partition]
At Mon, 21 Jan 2008 19:17:36 +0100, Jonas Meurer wrote: > > On 21/01/2008 Clemens Fruhwirth wrote: > > Jonas Meurer wrote: > > > > My main intention was to prevent multiple luksOpen'd devices, as this > > (in my opinion) is usually not neccessary and most likely an > > error. But using luksAddKey on an opened partition seems reasonable. > > so do you plan to fix this in future releases? Yes. What about "luksFormat/luksOpen requires exclusive access, everything else doesn't"? Btw. we really want exclusive access for luksOpen. As I just tried, it's possible to luksOpen a device multiple times, for instance as foo1 and foo2, and mount both identical mappings simultaneously. One gets nice corruptions when accessing both file system that both believe that they have exclusive access to the underlying device but in reality share a device. -- Fruhwirth Clemens - http://clemens.endorphin.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Wed, 3 Jan 2007 20:37:22 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > Well, it seems to fix the problem and according to the thread on lkml > the lack of flush_anon_page() on ARM is associated with some > corruption. At least FUSE doesn't work on ARM without those patches, > so it seems likely that luksOpen is also affected. So, can we close the bug against cryptsetup in this case? Maybe someone else can verify that? -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Wed, 3 Jan 2007 20:14:42 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > * Clemens Fruhwirth <[EMAIL PROTECTED]> [2007-01-03 17:59]: > > After a bit of debugging on Gordon's slug, I found out that we have > > some kind of read race/read corruption when reading the encrypted > > master key from a key slot. > ... > > As far as I understand page caching comes after dm-crypt, so maybe we > > have some kind of cache corruption here? > > Do you think this is related to http://lkml.org/lkml/2006/12/21/157 I'm sorry, I have no idea. > I just applied the two patches from that thread and successfully ran > 'cryptsetup luksClose' on ARM. "cryptsetup luksClose" is just an alias for "cryptsetup remove". This should never fail. What's with luksOpen after the patches? > Would the lack of __flush_anon_page() on ARM explain the corruption > you've observed? Again, I'm not familiar with this. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Tue, 2 Jan 2007 19:04:41 +0100,
Martin Michlmayr <[EMAIL PROTECTED]> wrote:
>
> * Clemens Fruhwirth <[EMAIL PROTECTED]> [2007-01-02 18:00]:
> > Does luksDump report the same things on both architecture?
>
> Yes.
After a bit of debugging on Gordon's slug, I found out that we have
some kind of read race/read corruption when reading the encrypted
master key from a key slot.
If you get into luks/keyencryption.c:LUKS_decrypt_from_storage and replace
return LUKS_endec_template(dst,dstLength,hdr,key,keyLength, device,
sector, backend, read_blockwise, O_RDONLY);
by something like
int r=LUKS_endec_template(dst,dstLength,hdr,key,keyLength, device,
sector, backend, read_blockwise, O_RDONLY);
while(dstLength) {
hexprint(dst, 32);
dstLength-=32;
dst+=32;
printf("\n");
}
return r;
you get the whole decrypted content dumped to stdout. Just to give you
a brief idea of how master key decryption from a key slot works:
cryptsetup derives a user key, sets up a temporary dm-crypt mapping
with that user key, and starts to read encrypted content from the
underlying device via the temporary dm-crypt mapping.
The problem: The decrypted content is _different_ for two identical
runs. When you use the debugging sniplet from above you can see, the
corruptions seem to be displaced copies of other content parts. For
instance, when every character below is a 32 byte block then we would
see:
a b c d e f
a b c d c f
I have no idea why 32 byte block in particular. There seem to be no
regular pattern in the corruption, for instance every x'th block, but
there is a regular pattern in which block is duplicated at the point
of the corruption, namely the previous 16th block. (Notice 16*32byte =
512 byte = sector size. Welcome to linux number mysticism).
As far as I understand page caching comes after dm-crypt, so maybe we
have some kind of cache corruption here?
On more things: The situation stabilizes under strace. Using strace
usually lets you open the LUKS partition.
--
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Tue, 2 Jan 2007 19:04:41 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > * Clemens Fruhwirth <[EMAIL PROTECTED]> [2007-01-02 18:00]: > > Does luksDump report the same things on both architecture? > > Yes. Strange. Can I somehow gain access to your test box? I'm not entirely out of guesses, but it's not efficient to communicate them. PGP key is on subkeys.pgp.net pub 1024D/31092E4E 2003-02-09 Key fingerprint = 0039 316D D85C 1FB3 4A39 10A2 5BBB 2BF4 3109 2E4E uid Fruhwirth Clemens <[EMAIL PROTECTED]> -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Sat, 30 Dec 2006 14:13:42 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > * Clemens Fruhwirth <[EMAIL PROTECTED]> [2006-12-30 11:50]: > > > Is there anything else I should try? > > > foobar:~# cryptsetup luksOpen /dev/sda5 x > > > Enter LUKS passphrase: > > > device-mapper: table: 254:0: crypt: Device lookup failed > > Strange. I haven't changed cryptsetup but now I don't get this > message anymore. I simply get: > > foobar:~# cryptsetup luksOpen /dev/sdb2 x > Enter LUKS passphrase: > Enter LUKS passphrase: > Enter LUKS passphrase: > Command failed: No key available with this passphrase. > > But I'm sure I've typed the passphrase correctly, and it works on my > x86 box (on which I created the LUKS partition). Does luksDump report the same things on both architecture? -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Fri, 29 Dec 2006 21:24:34 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > * Clemens Fruhwirth <[EMAIL PROTECTED]> [2006-12-29 11:52]: > > Please try the version from subversion > > http://luks.endorphin.org/svn/cryptsetup > > With 1.0.4 plus the attached 2 patches from SVN I no longer get any > corruption but I also cannot access my encrypted data. That's good :) > Is there anything else I should try? > foobar:~# cryptsetup luksOpen /dev/sda5 x > Enter LUKS passphrase: > device-mapper: table: 254:0: crypt: Device lookup failed > device-mapper: ioctl: error adding target to table > device-mapper: ioctl: device doesn't appear to be in the dev hash table. > Failed to setup dm-crypt key mapping. > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify > that /dev/sda5 contains at least 133 sectors. > Failed to read from key storage Are you sure we don't see any device mapper problems here? You might just go over to a box where LUKS works (when the LUKS partition does not contain anything security relevant to you), and do dmsetup table mappingname > dm-table-file open it up, and find the 7th entry that says something like x:y (major:minor device number of your underlaying device). Replace this by your correct device path on the arm box, copy that file over to arm and set it up as dmsetup create mappingname dm-table-file If that does not work, we are seeing a dm-crypt layer problem here. > Enter LUKS passphrase: I just commited a patch that prevents password retrying with I/O errors. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403426: kernel corrupts LUKS partition header on arm
At Wed, 20 Dec 2006 17:15:29 +0100, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > We're seeing corruption of LUKS partition headers on ARM. I've > confirmed this on two different ARM platforms (IXP4xx and IOP32x) and > with 2.6.17 and 2.6.18. > > Basically, when you create a LUKS partition on a PC and then connect > it to an ARM box and open it, you get an "automatic header conversion > from 0.99 to 0.991 triggered" message and afterwards the LUKS > partition header is corrupted. Please try the version from subversion http://luks.endorphin.org/svn/cryptsetup I just kicked this conversion routine as it is for pre-1.0 releases and guess there is no single deployment that will ever need it. This won't change the bug itself, but it won't corrupt your partition anymore. It just fails. > > Its done something like overwrite the second sector of the header with > > the first one. I had a look at the cryptsetup code, and the conversion > > message is triggered by it finding the wrong state code for the > > passphrase slot - so the data has been overwritten by the time its got > > there. That looks right. A good amount of staring out of the window, drew my attention to (read|write|write_lseek)_blockwise in util.c. Reading from a file description opened with O_DIRECT requires blockwise reading into an aligned memory segments. That's the reason for all the magic in these routines. Looking at read_blockwise, r=read(fd,buf,size) might just return a short read, that is rhttp://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355156: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore
Jonas Meurer <[EMAIL PROTECTED]> wrote: > > However, we fixed the bug. The problem was that I restricted the length > > (number of sectors) of a temporary dm-crypt mapping. However for devices > > with non-512 sector size like DVDs, the length as well as the start must > > be aligned to (device_sector_size/512). I will wrap up an rc3 as soon as > > I have had time to take care of your error message proposals. > > great. would you like to send me the patch for this 'readonly' bug > anyway? i plan to upload a new package within the next days, as i fixed > some minor bugs and added support for openssl encrypted keyfiles. it > would be great to have a fix for this bug as well. Can you send me the patches? It's quite likely that they will contain something useful for upstream too. What is the purpose of encrypted openssl keyfiles? -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355156: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore
Jonas Meurer <[EMAIL PROTECTED]> wrote: > i've tried to reproduce this bug, and indeed luksOpen fails for me with > a similar error message. i tried also plain dm-crypt, and discovered > that 'cryptsetup create' doesn't fail. the created device is mountable > and contains all the data which i put into the encrypted iso image. > > in other words, the bug must be related to luks, it's not reproducible > when using plain dm-crypt. > > just wanted to let you know, in case that you are not already aware of it. Execuse me for being not highly "verbose" on this issue. I mailed Bastian in private a tarball with a fix. I haven't Cc'ed bugs.debian.org as I was not sure whether the bug tracking system handles attachments correctly. (Does it?) However, we fixed the bug. The problem was that I restricted the length (number of sectors) of a temporary dm-crypt mapping. However for devices with non-512 sector size like DVDs, the length as well as the start must be aligned to (device_sector_size/512). I will wrap up an rc3 as soon as I have had time to take care of your error message proposals. Thanks for your help. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355156: [EMAIL PROTECTED]: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore]
Jonas Meurer <[EMAIL PROTECTED]> wrote: > after upgrading cryptsetup I was not able to use luksOpen on a > DVD image file. Downgrading to 2:1.0.1-16 makes it work again, > so something in the upgrade broke things. > Here is the command line log with the old 1.0.1 version: > $ cryptsetup --readonly luksOpen /dev/hdc _image > Enter LUKS passphrase: > key slot 0 unlocked. > $ > .. and the new version: > $ cryptsetup --readonly luksOpen /dev/hdc _image > Enter LUKS passphrase: > Aufruf fehlgeschlagen: No key available with this passphrase. Do you have the image still on disk? Can you try to open it via the loopback driver? losetup /dev/loopX image cryptsetup --readonly /dev/loopX _image Does this fail? I don't see any failing writes in the strace. I don't think you have a borken image as 1.0.1 seems to succeed. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334406: reduce priority of common-lisp-control's asdf repository
Package: common-lisp-controler Version: 4.15 asdf-install on Gentoo does not work. Gentoo packages asdf-install in cl-asdf, and installs the package into common-lisp-controller's asdf repository in /usr/share/common-lisp. SBCL comes with its own implementation of asdf-install and must not use the portable version from the common-lisp-repository. In the CLC dumping process, CLC installs itself as the first ranking asdf repository by pushing the /usr/share/common-lisp/systems path onto asdf:*central-repository*. For SBCL, this is clearly wrong as SBCL's own repository should never be lower in priority to CLC's repository. My fix is to append rather than prepand the CLC asdf repository to asdf:*central-repository*, lowering the CLC priority. This might cause other glitches, but imho this is a better behaviour. Properly test this patch with other CL implementations before merging MAIN. --- common-lisp-controller.lisp 2005-10-17 19:27:23.0 +0200 +++ /tmp/common-lisp-controller.lisp2005-10-17 19:27:11.0 +0200 @@ -40,6 +40,8 @@ (defvar *implementation-name* nil "The name of the implementation, used to name the directory in /var/cache/common-lisp-controller") +(define-modify-macro appendf (&rest lists) append) + (defun init-common-lisp-controller (fasl-root &key (source-root "/usr/share/common-lisp/") @@ -109,14 +111,16 @@ (setq cl:*features* (delete :sbcl-hooks-require cl:*features*)) ;; register the systems root: - (push *systems-root* - (symbol-value (intern (symbol-name :*central-registry*) - (find-package :asdf + (appendf + (symbol-value (intern (symbol-name :*central-registry*) + (find-package :asdf))) + (list *systems-root*)) - (push '(merge-pathnames ".clc/systems/" - (user-homedir-pathname)) + (appendf (symbol-value (intern (symbol-name :*central-registry*) - (find-package :asdf)) + (find-package :asdf))) +(list '(merge-pathnames ".clc/systems/" + (user-homedir-pathname)) (values)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
