Re: Issue writing image to disk via dd
On Sat, Apr 23, 2011, at 21:49:39 +0900, Osamu Aoki wrote:
> What was the size of image.img in exact bytes? What happened if you
> specified exact image size via "count"? What happened if bs=1024?
The size of image.img is 31457280 bytes. I have tried several ways
below and listed in parentheses what happens when I try to boot from
the sda drive after writing via dd. The result varies depending on if
it's done from Etch or Squeeze and what operands are given to dd. I
don't know if that helps at all though.
# dd if=image.img of=/dev/sda count=31457280 bs=1
Etch: failed (OS cannot boot - inflate: invalid stored block
lengths. readin failed. elf32_loadimage: read failed)
Squeeze: failed (OS hangs after boot loader menu)
I noticed there was a discrepancy between `du -k` on FreeBSD and Debian
(30736 and 30756 respectively) so I tried both just to see:
# dd if=image.img of=/dev/sda count=30736 bs=1024
Etch: failed (OS cannot boot - inflate: invalid stored block lengths...)
Squeeze: failed (OS hangs after boot loader menu)
# dd if=image.img of=/dev/sda count=30756 bs=1024
Etch: failed (OS cannot boot - "invalid format" error)
Squeeze: failed (OS hangs after boot loader menu)
> Please try the following to see what happens.
>
> # dd if=image.img of=/dev/sda bs=1MB
Etch: failed
Squeeze: failed
> or
> # dd if=image.img of=/dev/sda bs=$((1024*1024*1024))
Etch: "dd: memory exhausted"
Squeeze: "dd: memory exhausted"
> Anyway, these suffix of DD is tricky. I do not know how stable was
> them. If this is not the reason, it may be kernel behaviour issue of
> error handling when you go over the limit of the file system.
Is there any further testing I could do on Etch or Squeeze to track
down that possible issue?
Thanks a lot for the reply,
-Mark
Reply to: