[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: need sd card backup on r-pi-3b

On 23/09/17 15:00, Gene Heskett wrote:

I've never had problems with dd provided that the USB->SDcard
adapter's OK: what command are you using?

The usual syntax:
dd  if=somefile bs=512 of=somedevice, and in the case of sd card copying,

Tell us the /exact/ command you're using.

since no 2 are alike so I usually look at the src's declared size in
dmesg and set count=that-5k so it doesn't error out copying a pny 32GB
to a Sandisk 32GB.  Etcher, which is faster, has the same problem &
pitches a fit when it can't find room to put the last 10 sectors.  I've
had poor luck with sandisk anything though. pny, samsung is good stuff.
So I bought pny last night.

The first thing I'd say is that almost all of the problems I've had stopped when I changed the card reader. I'm now using one badged Canyon which specifically has a Micro-SD slot, i.e. I'm no longer trying to use an adapter which is universally regarded as being unwise.

You don't need that bs=512 and trying a sector-by-sector copy on a device that uses far larger blocks might be unwise. I use bs=128M

Don't give dd an explicit block count, let it copy everything. That 5k in particular could be worse than useless since it doesn't correspond to a physical or logical block size.

Zeroing the target device first might help, i.e. copying from /dev/zero

If the source device has been partitioned to be full, then shrink first the top filesystem and then the top partition to make sure that what you're copying is substantially smaller than the target device. Alternatively a useful hack is to set up your source device with an extra partition at the top, e.g. FAT just in case you want to move data around between OSes, then you can delete the top filesystem and partition before using dd and be confident that you won't be doing an incomplete copy.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Reply to: