Re: need sd card backup on r-pi-3b
On Saturday 23 September 2017 12:26:23 Mark Morgan Lloyd wrote:
> 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.
I have 2 vivitar's, both with microsd slots. They work 100% when burning
an image file from armbian jessie so far.
> 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
>
I'll give that a shot.
> 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.
no two sd cards, even from the same maker, are exactly the same size due
to bad block replacements before they are even blister packed for sale.
This is the exact reason they ship stripped images that require you
resize them on the machine they will live in. What we dearly need is a
utility to generate the iso shrunken to only that which is actually
used. Or do we have such a critter and I don't know about it?
> 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.
Seems like something that could be scripted.
Thanks Mark.
I'm going to get some legal clothes on, and go write that starter image
to one or more of these fresh cards. bbl.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: