Re: need sd card backup on r-pi-3b
"Destination Host Unreachable" doesn't mean it didn't resolve, it can
mean a cable's unplugged or your netmask isn't right or in this case
it's not getting outside your LAN for whatever reason. Try pinging an
outside IP like 8.8.8.8 (a public Google DNS server). Ping and dns
lookup are 2 different things.
On 9/23/17, Gene Heskett <gheskett@shentel.net> wrote:
> 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>
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: