Original Reporter account deactivated.
** Tags added: gutsy needs-upstream-testing
** Changed in: linux (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Could this one-liner be included in the next security update?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/157425
Title:
Using dd to dupliate an entire drive with bs=128K gives read error at
I've patched the latest kernel from Hardy with this one-liner, and tried on my
server. Seems to be working and no other problems so far.
If anybody would like to test it, you can enable my testing PPA
(https://launchpad.net/~cemc/+archive/ppa) and install the patched kernel from
there.
--
You
I've just ran into this problem with my Samsung 1TB drive. I managed to
reproduce the problem following this:
http://www.gossamer-threads.com/lists/linux/kernel/985985?page=last
dd if=/dev/sdc bs=512 count=1 skip=268435455 /dev/null
Two years have passed since this bugreport was reported, I
[ 9839.496000] ata1.00: cmd c8/00:f8:08:ff:ff/00:00:00:00:00/ef tag 0
^--^
Get this one with Hardy too:
ata1.00: cmd ca/00:e0:20:ff:ff/00:00:00:00:00/ef tag 0 dma 114688 out
It's the libata LBA28/LBA48 off-by-one bug:
fixed in
James Collier wrote:
Thank you for taking the time to report this bug and helping to make
Ubuntu better. You reported this bug a while ago and there hasn't been
any activity in it recently. We were wondering is this still an issue
for you? Can you try with latest Ubuntu release? Thanks in
Thank you for taking the time to report this bug and helping to make
Ubuntu better. You reported this bug a while ago and there hasn't been
any activity in it recently. We were wondering is this still an issue
for you? Can you try with latest Ubuntu release? Thanks in advance.
** Changed in:
Interesting.. I wouldn't have expected an issue until block 33554432 (32
bits of 1k chunks taken 128 at a time). Just to confirm, the two
blocksizes tried are 128 kilobytes and 512 bytes, rather than 512
kilobytes, correct?
--
Using dd to dupliate an entire drive with bs=128K gives read error
Yes, 128 kilobytes, vs 512 bytes.
128K fails at 137GB every time, regardless of destination.
512 bytes was successful copying both to /dev/null during testing and to
the second disk attached to USB2 when I was replacing the drive.
137GB seems suspicious to me due to its proximity to the 28 bit
