RockChip (and possibly others) broken static IP

[Gene Heskett]

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.

[Gene Heskett]

Post by Gene Heskett
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.

For a local router you're probably better using a gateway in
/e/n/interfaces and then removing anything hardwired in the head or
tail file.

But as I've posted quite a few times, is ignored by stretch installs on
armhf or 64 at boot up. Something is fixing it in the next 10 or 15
minutes on an arbian install, so I do eventually get a gateway showing
in the route -n report. But that part of my post seems to be ignored.
IMO it should work AT boot time. It, the gateway assignment, is not made
till some minutes later.
2nd subject...

Post by Gene Heskett
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.

You can speed it up by using e.g. bs=128M so that dd is handling
larger chunks. Keep a note with the card so that you know you that you
don't have to back the whole 64Gb up.

How does one do that. There is quite simply nothing that will mark it
that I have found.

For starters, that does get the last copy of the drives tables located at
the end of the disk. By copying to a bigger drive, that problem is
bypassed as long as its not resized to the new size, and I have no
intention of doing that. This particular install and all its data files
can live happily ever after in 8GB.

Post by Gene Heskett
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.

Neat but I'm afraid very much off-topic.

yes absolutely. But I sometimes want to share what I'm doing to justify
my decisions about how I get it done.

Post by Gene Heskett

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

Reports this:
***@rock64:~$ sudo systemctl stop dhcpd
[sudo] password for gene:
Failed to stop dhcpd.service: Unit dhcpd.service not loaded.
***@rock64:~$ sudo systemctl stop dhcpcd
Failed to stop dhcpcd.service: Unit dhcpcd.service not loaded.
***@rock64:~$ sudo systemctl disable dhcpcd
Failed to disable unit: No such file or directory
***@rock64:~$ sudo systemctl mask dhcpcd
Unit dhcpcd.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/dhcpcd.service → /dev/null.

So it appears its not running but I'll dbl-check with htop, no, not
running. 3 copies of NM though are though.

Post by Gene Heskett

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.

I've just been looking at removing dhcpcd5 which appears to be
redundant and the cause of the original gateway problem. However on
the TinkerBoard doing that also removes tinker-config which would be
undesirable.

Post by Gene Heskett

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.

Me too, and its quite confusing.

Noted JP's previous comments that systemd should be allowed to handle
much of this stuff, but e/n/interfaces concentrates most of the
interface configuration in one place and as long as it's installed by
default it's reasonable to expect it, and its extensions, to work. And
before it's deprecated and removed I trust that somebody will document
and test its replacement, and test that all combinations of the
replacement extensions interwork correctly.

I am in violent agreement. It would be a welcome surprise to have
this /etc/network/interfaces.d/eth0 file 100% obeyed AT bootup or
networking restart time:

auto eth0
iface eth0 inet static
address 192.168.71.2/24
gateway 192.168.71.1
dns-nameserver 192.168.71.1
dns-search hosts dns

Not 10 minutes later.

Thanks Mark,