[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 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>


Reply to: