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
terrabyte.
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
netmask 255.255.255.0
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 (98.138.253.109) 56(84) bytes of data.
From 192.168.71.2 (192.168.71.2) 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: