Re: RockChip (and possibly others) broken static IP
On Saturday 28 July 2018 03:40:34 Mark Morgan Lloyd wrote:
> On 27/07/18 21:15, Gene Heskett wrote:
> > On Friday 27 July 2018 12:29:34 Mark Morgan Lloyd wrote:
> >
> > 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...
> > 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.
>
> > 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.
> >> 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:
gene@rock64:~$ sudo systemctl stop dhcpd
[sudo] password for gene:
Failed to stop dhcpd.service: Unit dhcpd.service not loaded.
gene@rock64:~$ sudo systemctl stop dhcpcd
Failed to stop dhcpcd.service: Unit dhcpcd.service not loaded.
gene@rock64:~$ sudo systemctl disable dhcpcd
Failed to disable unit: No such file or directory
gene@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.
> >> 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.
>
> >> 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,
--
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: