Re: need sd card backup on r-pi-3b
On Sunday 24 September 2017 00:28:34 Alan Corey wrote:
> > 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#
traceroute is not installed, but arp is: (and says the same this in a
different language)
root@rock64Sheldon:/etc/init.d# traceroute shentel.net
-bash: traceroute: command not found
root@rock64Sheldon:/etc/init.d# arp -a
voipmonitor.wci.com (204.11.201.10) at <incomplete> on eth0
*router.coyote.den (192.168.71.1) at 4c:e6:76:ad:34:0a [ether] on eth0
propjet.latt.net (204.2.134.164) at <incomplete> on eth0
time-a.timefreq.bldrdoc.gov (132.163.4.101) at <incomplete> on eth0
mdnworldwide.com (66.135.44.92) at <incomplete> on eth0
eterna.binary.net (216.229.0.49) at <incomplete> on eth0
pacific.latt.net (204.2.134.163) at <incomplete> on eth0
? (204.111.6.122) at <incomplete> on eth0
soft-sea-01.servers.octoshape.net (50.22.155.163) at <incomplete> on eth0
awesome.bytestacker.com (198.58.110.84) at <incomplete> on eth0
time-c.nist.gov (129.6.15.30) at <incomplete> on eth0
ntp.your.org (204.9.54.119) at <incomplete> on eth0
time-b.nist.gov (129.6.15.29) at <incomplete> on eth0
time-a.nist.gov (129.6.15.28) at <incomplete> on eth0
2.time.dbsinet.com (199.223.248.100) at <incomplete> on eth0
ha81.smatwebdesign.com (198.58.105.63) at <incomplete> on eth0
155-94-238-29-host.hostbrew.com (155.94.238.29) at <incomplete> on eth0
*coyote.coyote.den (192.168.71.3) at 00:1f:c6:62:fc:bb [ether] on eth0
119.189.154.104.bc.googleusercontent.com (104.154.189.119) at
<incomplete> on eth0
hydrogen.constant.com (108.61.73.243) at <incomplete> on eth0
time-b.timefreq.bldrdoc.gov (132.163.4.102) at <incomplete> on eth0
? (208.76.53.137) at <incomplete> on eth0
frigg.fancube.com (154.16.245.246) at <incomplete> on eth0
four0.fairy.mattnordhoff.net (66.228.59.187) at <incomplete> on eth0
root@rock64Sheldon:/etc/init.d#
And except for the local (*marked) machines, is "incomplete".
I just powerdown reset the router, no change.
I just noted the time was wrong, so I set /etc/timezone to
America/New_York and restarted ntp. No diff so I commented the
unreachable pool
s out and enabled it to listen on the local lan. DD-WRT is set to
broadcast it, but thats made no diff either. At 2:41 local, it says:
root@rock64Sheldon:/etc/init.d# date
Sun Sep 24 06:41:34 UTC 2017
Which is UTC I think, its too late in the evening, so I'm headed back to
the sack. Maybe it will fix itself in the night? Thanks Alan.
> 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>
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: