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>