Re: RockChip (and possibly others) broken static IP
On Friday 27 July 2018 12:29:34 Mark Morgan Lloyd wrote:
> A few days ago Gene Heskett was complaining that his RockChip-based
> board was refusing to pick up a gateway address defined statically in
> /e/n/interfaces or /e/n/interfaces.d. I just thought I'd confirm that
> I can also see that on a (RockChip-based) Tinkerboard, although I've
> not seen it on a Raspberry Pi or a PC.
>
In a way, thats good, because it helps to confirm I'm not an old fart too
dumb to get it right.
> My suspicion is that the boards that Gene and I are using have a
> "common ancestor" rather closer than the Debian masters, and that this
> has introduced questionable configuration.
Well. the gateway problem is fixed by running this one line script after
a reboot: But something has apparently deleted it as I wrote it
to /etc/network as a 2 line scrip, the first line being "#/bin/bash" and
which was there the last time, ahh, wait, that was the old sd card, now
different boot sd, now is armbian so it laying on the table next to the
rock64.
But it also did not get a gateway on boot, but 10 minutes later I found I
could ping yahoo.com, and running a sudo route -n confirmed I had a
gateway and it was correctly my router. So something as yet unk to me
did establish a gateway, although the dns address remained at 8.8.8.8
whereas it was supposed to be the router, but it works. Does finding
nameserver 8.8.8.8 in resolv.conf indict one or the other of dhcpd or
n-m?
I found the 8.8.8.8 in /etc/resolvconf/resolvconf.d/head and changed it
to point at the router, and rebooted since a service networking restart
hung and never came back from this machines login.
Going out there to it, I was confronted with a dead screen. Did a
powerdown, which although it work up the monitor, showed a blank screen
for several minutes, finally bringing up a login prompt on tty1.
Fooling around, and updating it which installed a new armbian-config
and with it I was able clean up some of it although I had to run
dpkg-reconfigure tzdata to get the displayed time=local. The installed a
few things too, and now give me a gui after login. So I may be able to
use it for something yet.
Pulled the sd card from the pi and dd'd it to a file that was just short
of 32GB, took about an hour, but its writing slower and is still
blinking away at putting that file on a 64GB sd card for a backup after
nearly 2 hours. With 64GB, and I don't care if it never gets resized as
that 32GB is way more than enough to hold this install. All the gcode
I've written for it is just a tad over 6 megabytes because I am fond of
LinuxCNC ability to handle all the usual high level languages loop
constructs. Loops are the best way to compress what could be a 30 meg
file if unrolled, but is 90 LOC on the storage media that takes 3 days
to run.
And it sharpened a table saw blade far sharper than anything I can buy,
using a dremel at about half speed, driving the cable wand bolted to the
mini-mills head casting which had a 1.5" diameter diamond disk mounted.
That blade then cut up the all the cherry I used to make an
entertainment center for the missus, and all the solid mahogany for 4
blanket chests, loosely based on one that was shown in Fine WoodWorking
about 4 or so years back, except my version has an aromatic cedar lining
for moth-proofing. One for each of my 4 surviving boys to remember me by
when I have fallen over the last time.
That blade had been run dull, but in all that I might have taken 3 thou
off the front face of each tooth, about a micron for every full turn of
the blade. Tooth style was ATBF, which I can't find to buy in recent
years. Sweet, but sharpening it was a huge time sink.
And at 2 elapsed hours, dd is still chomping away at that copy. Slow,
like watching grass grow. Later everybody.
>
> What appears to be happening is that both dhcpcd and NetworkManager
> are being started by systemd, and while NetworkManager can be relied
> on to leave interfaces mentioned in /e/n/interfaces alone it appears
> that dhcpcd is nowhere near as well-behaved.
>
> I'm unsure about the side-effects of this, but for the sake of getting
> things to a testable state dhcpcd can be disabled using something like
>
> # systemctl stop dhcpcd
> # systemctl disable dhcpcd
> # systemctl mask dhcpcd
>
> That restores things to the "classic Debian" state where
> /e/n/interfaces is obeyed, but where NetworkManager will try to handle
> any interfaces that are not explicitly listed (in particular WiFi).
>
> If one doesn't want NetworkManager, then it can be disabled in a
> similar fashion. I'd suggest not trying to uninstall it.
>
> It's possible to configure dhcpcd to ignore certain types of
> interface, but I can't see a way to tell it not to try to preempt
> /e/n/interfaces. However this is by no means the first time that I've
> found
> inconsistencies in this area.
--
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: