Re: need sd card backup on r-pi-3b
> I'm out of ideas. And obviously I cannot configure this rock64 until the
> network works.
It sounds like only 1 machine doesn't work, your email got out after all.
> and 4 other wheezy machines work as expected thru this
So the rock64 has a chance of working.
You don't have something blocking certain MAC addresses, maybe by not
having added it to a table of allowed ones? Access control list for
the router maybe?
You could try an arp -a but I don't think it'll work past the router.
How about traceroute 8.8.8.8? Sounds like it's not getting past the
router for whatever reason so it'll probably map up to there and sit
there doing * * *. Reboot the router? I don't know what it is in
this case. Traceroute shows me
zero# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.43.1 (192.168.43.1) 4.728 ms 4.678 ms 4.171 ms
2 * * *
3 172.21.192.194 (172.21.192.194) 207.516 ms 226.515 ms 226.393 ms
4 107.77.252.106 (107.77.252.106) 225.585 ms 338.241 ms 340.453 ms
5 107.77.252.2 (107.77.252.2) 354.467 ms 375.499 ms 381.571 ms
6 107.77.254.116 (107.77.254.116) 381.075 ms 363.133 ms 363.692 ms
7 12.83.186.186 (12.83.186.186) 365.420 ms 363.726 ms 364.198 ms
8 12.83.185.153 (12.83.185.153) 390.378 ms 384.479 ms 392.005 ms
9 12.122.28.125 (12.122.28.125) 405.034 ms 404.243 ms 401.788 ms
10 12.122.141.221 (12.122.141.221) 423.779 ms 425.877 ms 444.198 ms
11 12.247.147.22 (12.247.147.22) 444.313 ms 447.099 ms *
12 108.170.249.161 (108.170.249.161) 448.599 ms * *
13 216.239.56.91 (216.239.56.91) 519.419 ms 108.170.228.14
(108.170.228.14) 512.205 ms 216.239.54.229 (216.239.54.229) 509.196
ms
14 209.85.254.185 (209.85.254.185) 517.461 ms
google-public-dns-a.google.com (8.8.8.8) 502.167 ms 506.646 ms
zero#
Having fun with this ZeroW, which runs on about 1 watt. And it's
about 2 inches long.
On 9/23/17, Gene Heskett <gheskett@shentel.net> wrote:
> On Saturday 23 September 2017 20:28:08 Alan Corey wrote:
>
>> "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.
>>
> Ping fails to any address beyond the router, by name or address:
> pinging the router:
> root@rock64Sheldon:~# ping router
> PING router.coyote.den (192.168.71.1) 56(84) bytes of data.
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=1 ttl=64
> time=1.60 ms
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=2 ttl=64
> time=1.01 ms
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=3 ttl=64
> time=1.00 ms
>
> This machine:
> root@rock64Sheldon:~# ping coyote.coyote.den
> PING coyote.coyote.den (192.168.71.3) 56(84) bytes of data.
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=1 ttl=64
> time=0.878 ms
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=2 ttl=64
> time=0.868 ms
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=3 ttl=64
> time=0.853 ms
>
> my ISP:
> root@rock64Sheldon:~# ping shentel.net
> PING shentel.net (204.111.6.122) 56(84) bytes of data.
> From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host Unreachable
> From 192.168.71.2 (192.168.71.2) icmp_seq=2 Destination Host Unreachable
> From 192.168.71.2 (192.168.71.2) icmp_seq=3 Destination Host Unreachable
>
> googles dns:
> root@rock64Sheldon:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> From 192.168.71.2 icmp_seq=1 Destination Host Unreachable
> From 192.168.71.2 icmp_seq=2 Destination Host Unreachable
> From 192.168.71.2 icmp_seq=3 Destination Host Unreachable
>
> I can't see anything in the router settings that would block an outside
> the lan address, and 4 other wheezy machines work as expected thru this
> router.
>
> I'm out of ideas. And obviously I cannot configure this rock64 until the
> network works.
>
> Humm, iptables is running, and I've not messed with that since 15 years
> ago, don't use it on the local lan net. Killed it and unloaded the
> modules. local ping still works, outside still dead. Restarted the
> networking, which did not restart iptables or load its modules, but the
> bahavior is unchanged.
>
> Bedtime on this side of the pond. Tomorrow is a new day.
>
> Thanks Alan.
>
>> 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>
>
>
> 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: