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

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

On Saturday 23 September 2017 13:28:51 Mark Morgan Lloyd wrote:

> On 23/09/17 16:45, Gene Heskett wrote:
> > 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?
> I know all that, and I've spent a lot of time talking to these things
> directly, measuring times, checking pattern-sensitivity and so on.
> And I'd remind you that while we're using similar hardware, you're
> having problems, I'm not. What does that suggest to you? :-)
> >> 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.
> Yes, for example by the script that Raspbian runs on its first
> startup.
> Don't fool around, just make sure that the valid data on the source
> card is substantially smaller- and I mean 100s of Mb, not a few Kb-
> than the destination card.
> But my suspicion is that you're doing something wrong like trying to
> copy one partition when you should be copying all partitions. But
> since you won't give us an example of the command you're using we
> can't be certain either way on that.

I did, but it was for dd. I have sincefound piclone will run ok, if 
itsthe first thing after a reboot. Dirty the memory with something else 
and its dead.  So I now have the terrabyte hd cloned from the base of 
the card. If I ever get it to boot from it, expand the filesystem to a 

Next problem, I installed the minimal stretch to a 32GB card, and if 
don't think it resized that 230 mb image, but I'm logged into it, so df 
gives me:
rock64@rock64:~$ df
Filesystem     1K-blocks   Used Available Use% Mounted on
udev             2007908      0   2007908   0% /dev
tmpfs             401960   5512    396448   2% /run
/dev/mmcblk1p7  30574584 931612  28360464   4% /
tmpfs            2009784      0   2009784   0% /dev/shm
tmpfs               5120      4      5116   1% /run/lock
tmpfs            2009784      0   2009784   0% /sys/fs/cgroup
/dev/mmcblk1p6    102182  41636     60546  41% /boot/efi
tmpfs             401956      0    401956   0% /run/user/1000

So no, its not needing expansion, the whole card is there.

I've carved up a /etc/network/interfaces.d/eth0 file with the usual 
entries, looks like this:
rock64@rock64:~$ cat /etc/network/interfaces.d/eth0
#allow-hotplug eth0
auto eth0
iface eth0 inet static
address 192.168.NN.2
gateway 192.168.NN.1

ditto, I made a real /etc/resolv.conf, looks like this:
rock64@rock64:~$ cat /etc/resolv.conf
domain	coyote.den
nameserver 192.168.NN.1
search hosts dns

Both are made immutable so n-m can't putz with them if it is running. 
According to ps, it is not. If its gone from stretch, I'll need a 6 pack 
to celebrate that properly. :)

So my local network is working as expected.  BUT:
root@rock64:/etc# ping -c1 yahoo.com
PING yahoo.com ( 56(84) bytes of data.
From ( icmp_seq=1 Destination Host Unreachable

Note that the dns request did resolve.

But my dns requests are probably being answered by dnsmasq in the router.  
I cannot find anything in the routers copious settings (it's DD-WRT) 
that would prevent a connection, but it refuses to pass. I've tried 
several ipv4 addresses in that 192,168.nn block. No other machines, 5 
more, on this local net are being denied network access.

Ideas? I'm nearly out of hair. But its been slowly thinning for 82+ years 
too so I can't blame it on this too loudly.

Thanks Mark.

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: