Bug#501134: RAW-pictures break down after copied on a crypted raid5

2012-05-08 Thread Daniel Starzmann
The bug seems to be fixed in the current Debian 6.0 'squeeze' with the
2.6.32-5-amd64 kernel.
I'm running it on new hardware but with a similar configuration
(luks-crypted raid 5) and couldn't reproduce the described problem.

Thanks for answering!! - better late, than never ;-)

Daniel


2012/4/23 Ben Hutchings b...@decadent.org.uk

 On Sat, 2008-10-04 at 17:01 +0200, daniel starzmann wrote:
  Package:  linux-image-2.6.24-etchnhalf.1-486
  Version:  ?
 
 
  Hello,
  I have an extra-ordinary problem or perhaps an Kernel bug:

 I'm very sorry that we haven't responded to your bug report.  It is
 clearly a serious bug, but your report seems to have been missed due to
 changes in package names.

  My Server:
  * Debian Etch (Kernel: Etch-n-half), Samba 3.0.24
  * 500gb harddisk with a system and a data partition. Both are crypted
  with Luks (cipher:serpent-cbc-essiv:sha256)
  * Raid 5 crypted with Luks (cipher:  serpent-cbc-essiv:sha256)
  * All partitions have the ext3 filesystem
 
  Client1: Notebook (Windows XP and Fedora)
  Client2: Desktop (Fedora)
  I did all tests from both clients
 
  My problem:
  I tried to copy RAW pictures (*.cr2 files) from a client to the raid5
  partition with the following 4 different ways.
 
  1. I exported the raid partition with samba and copied the pictures with
  Windows XP and the Windows Explorer
  2. I copied the pictures through an smb-mount with Fedora with the
  cp-command
  3. I copied the pictures with the scp-command (first initiiated from
  the client and then from the server)
  4. I copied the pictures with the rsync-command (first initiiated from
  the client and then from the server)

 Thank you for the thorough testing.

  I checked the files after I had copied them with md5sum and I saw that
  the values where different to the values of the original files.
  The pictures where broken. They had lila stribes and where cutted in the
  half.
  I tried the same 4 methods and copied the pictures on the 500gb data
  partition and there where no failures or md5sum differences.
  Then I copied the pictures in an ssh shell with an normal cp-command
  from the local-partition to the raid5-partition. The md5sum values where
  the same, so this worked well.

 It might just be that in this case the files were read back from the
 cache (memory) instead of from the disk.

  So in my opinion the problem has to do with the crypted raid5.
  I tried to reproduce this failures with other files but i had this
  problem only with RAW (*.cr2 Canon) picture files.

 Perhaps related to the size of the files?

  I tried to repair my system with these 3 Methods:
  1. fsck.ext3 -y /dev/mapper/md0_crypt
  2. fsck.ext3 -c -p  /dev/mapper/md0_crypt
  3. server rebooted a few times
  I couldn't find out any failure messages in the log-files or at the
  booting.
 
 
  After many hours I found this out:
  With Kernel 2.6.24-etchnhalf.1-686, Kernel 2.6.24-etchnhalf.1-486 and
  Kernel 2.6.26-bpo.1-486 I could reproduce my Image-copy-problem.
  As I booted the older Kernel 2.6.18-6-486 I where able to copy the
  pictures with any of the methods above and the md5sum values where OK.
  Because of this I think its an Kernel problem.
 [...]

 That certainly seems to be the case.  Do you know whether a later
 version (e.g. Linux 2.6.32 in Debian 6.0 'squeeze') fixed this bug?

 Ben.

 --
 Ben Hutchings
 For every action, there is an equal and opposite criticism. - Harrison


Bug#501134: RAW-pictures break down after copied on a crypted raid5

2008-10-04 Thread daniel starzmann
Package:  linux-image-2.6.24-etchnhalf.1-486  
Version:  ?


Hello,
I have an extra-ordinary problem or perhaps an Kernel bug:

My Server: 
* Debian Etch (Kernel: Etch-n-half), Samba 3.0.24
* 500gb harddisk with a system and a data partition. Both are crypted
with Luks (cipher:serpent-cbc-essiv:sha256)
* Raid 5 crypted with Luks (cipher:  serpent-cbc-essiv:sha256)
* All partitions have the ext3 filesystem

Client1: Notebook (Windows XP and Fedora)
Client2: Desktop (Fedora)
I did all tests from both clients

My problem:
I tried to copy RAW pictures (*.cr2 files) from a client to the raid5
partition with the following 4 different ways.

1. I exported the raid partition with samba and copied the pictures with
Windows XP and the Windows Explorer
2. I copied the pictures through an smb-mount with Fedora with the
cp-command
3. I copied the pictures with the scp-command (first initiiated from
the client and then from the server)
4. I copied the pictures with the rsync-command (first initiiated from
the client and then from the server)

I checked the files after I had copied them with md5sum and I saw that
the values where different to the values of the original files.
The pictures where broken. They had lila stribes and where cutted in the
half.
I tried the same 4 methods and copied the pictures on the 500gb data
partition and there where no failures or md5sum differences.
Then I copied the pictures in an ssh shell with an normal cp-command
from the local-partition to the raid5-partition. The md5sum values where
the same, so this worked well.
So in my opinion the problem has to do with the crypted raid5.
I tried to reproduce this failures with other files but i had this
problem only with RAW (*.cr2 Canon) picture files.


I tried to repair my system with these 3 Methods:
1. fsck.ext3 -y /dev/mapper/md0_crypt
2. fsck.ext3 -c -p  /dev/mapper/md0_crypt
3. server rebooted a few times
I couldn't find out any failure messages in the log-files or at the
booting.


After many hours I found this out:
With Kernel 2.6.24-etchnhalf.1-686, Kernel 2.6.24-etchnhalf.1-486 and
Kernel 2.6.26-bpo.1-486 I could reproduce my Image-copy-problem. 
As I booted the older Kernel 2.6.18-6-486 I where able to copy the
pictures with any of the methods above and the md5sum values where OK.
Because of this I think its an Kernel problem.



I absolutly don't know what additional information I should post with
this E-Mail, please write me what I should add or where I should post
the extra-information.
Sorry if I addressed this E-Mail wrong, I don't know where to go with
this problem/bug. With bug-buddy I weren't able to make a Bug-Report.






Nice regards

Daniel







###
###
Server Systeminformation :

Debian Etch with different Kernels: 
2.6.24-etchnhalf.1-686, Kernel 2.6.24-etchnhalf.1-486, Kernel
2.6.26-bpo.1-486, Kernel 2.6.18-6-486

Kernel 2.6.18-6-486 installed with the Installation-setup from the
debian stable cd.
the others with apt-get install from the source: 

deb http://www.backports.org/debian etch-backports main contrib non-free


# ls -l /lib/libc.so.6
/lib/libc.so.6 - libc-2.3.6.so

# lspci -v
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?)
(rev c1)
Subsystem: ASUSTeK Computer Inc. Unknown device 80ac
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at d000 (32-bit, prefetchable) [size=128M]
Capabilities: [40] AGP version 3.0
Capabilities: [60] HyperTransport: Host or Secondary Interface

00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 0 (rev
c1)
Subsystem: nVidia Corporation Unknown device 0c17
Flags: 66MHz, fast devsel

00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev
c1)
Subsystem: nVidia Corporation Unknown device 0c17
Flags: 66MHz, fast devsel

00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev
c1)
Subsystem: nVidia Corporation Unknown device 0c17
Flags: 66MHz, fast devsel

00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev
c1)
Subsystem: nVidia Corporation Unknown device 0c17
Flags: 66MHz, fast devsel

00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev
c1)
Subsystem: nVidia Corporation Unknown device 0c17
Flags: 66MHz, fast devsel

00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
Subsystem: ASUSTeK Computer Inc. A7N8X Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [48] HyperTransport: Slave or Primary Interface

00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 0c11
Flags: 66MHz, fast devsel, IRQ 255
I/O ports at c400 [size=32]
Capabilities: [44] Power