Re: i386 version for chrome
On Saturday 27 October 2018 14:21:23 Steve McIntyre wrote:
> Gene Heskett wrote:
> >On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:
> >> You keep on asserting this, but it's patently not true. That's a
> >> standard feature of Debian on all architectures. I understand
> >> you've seen problems, but it just needs debugging to see how things
> >> were broken in your case. :-(
> >
> >Then give me an install that can be made to work in a hosts file
> > defined local network that can accept a gateway statement in its
> > e/n/i file. The default install does NOT accept it until the network
> > has been brought up. And the syntax for the deprecated route
> > command is too complex to remember, then everybody wants me to use
> > ip-(mumble) for that without anything that resembles a man page to
> > tell me how to use it for that. Thats the singular most obtuse man
> > pages group I've tried to make sense of in 35+ years of making
> > networks work starting even before Hayes modems were the default.
>
> Right. The ip-* man pages are atrocious, I won't argue - they're
> basically not human-readable. :-(
And who might we beat about the brow over that, I've already got the elm
club for that job carved. :)
> >The arm64 stretch install has, as e/n/i.d/eth0:
>
> Checking: is that straight Debian stretch, or some derivative?
Armbian I believe, Steve, thats what the default xfce login gui says
anyway, but a cat /etc/issue says:
gene@rock64:~$ cat /etc/issue
Debian GNU/Linux 9 \n \l,
and a uname -a:
gene@rock64:~$ uname -a
Linux rock64 4.4.124-rk3328 #24 SMP Wed Mar 28 17:15:52 CEST 2018 aarch64
GNU/Linux
> >auto eth0
> >iface eth0 inet static
> >address 192.168.NN.2/24
> >gateway 192.168.NN.1
> >dns-nameserver 192.168.NN.1
> >dns-search hosts dns
>
> I'm assuming that "NN" is a placeholder you've added, and not copied
> verbatim from the file!
Of course, I don't really want to give the farm to the first hacker that
gets thru dd-wrt (which FWIW has yet to occur in 15+ years of having it
standing guard here).
> Otherwise, that last line looks suspect. The "dns-nameserver" and
> "dns-search" lines are instructions for resolvconf when setting up
> networking. The "dns-search" line is meant to be passed straight
> through into resolv.conf to set up a DNS search path. A valid example
> from the resolvconf man page is "dns-search foo.org bar.com". What
> that means is that each time you look up something that's no
> fully-qualified (e.g. "foo"), this machine will be looking for
> "foo.hosts" then "foo.dns". That's probably not what you
> want. However, it'll be harmless if you're looking up FQDN hostnames
> all the time.
>
> >And that works, I just got it from that machine with an ssh login.
> >
> >So all the stuff that used to be in e/resolv.conf is now in that
> > file, but no one in 2 damned years of my asking questions has ever
> > mentioned that its been moved or why. To add to the confusion,
> > /etc/resolv.conf is now a link that returns a list of nameservers
> > only. But is there any documentation for all the shuffling? Not
> > thats been converted to a utf8 file I can peruse and learn from.
>
> This is down to the resolvconf package, which is often pulled in via
> Recommends: from other packages. For a simple network with simple
> needs, you shouldn't need to use it. It should work for you,
> though. It manages resolv.conf, hence wanting to move the normal
> config from that file.
>
> If you *don't* have resolvconf installed, putting the details in
> /etc/resolv.conf still works, and it's how I configure static things
> on my own network (e.g. on the gateway/router box).
>
> >Sorry Steve, but your claim that its simply not true, pulls my
> > trigger, best to duck.
>
> I understand - I've seen you're struggling, but I know this stuff
> works on lots of other machines. There's nothing broken here on
> standard Debian on any architecture that I know of. *However*,
> remotely debugging what other thing might be causing your woes is
> really difficult.
I've considered enableing dhcpd in the router, and matching the mac to
the address issued. I did have that setup years ago to service my old
lappy but that only worked around 25% of the time, and since I am no
longer playing visiting fireman at other tv stations, its now hard coded
in the hosts files which works unless the cat5 has been cut. In 15 years
of blowing in the wind that piece of cat5 is still doing 100 megabaud
over 45 feet of it to the shop building. I'm suitably amazed, as its
survived 110+ mph winds that it took $18K to fix up the rest of the
damages to the house and fencing, took out 3.5 40+ foot pines too. I
finally took out the half of the 4th one last year as it was looking
uglier by the year.
Back on topic, sorta.
The last time I tried a debian-arm as a dl and write to the sd card,
failed just like the amd64 versions, plus armbian doesn't hard code the
first user=1000, which IMNSHO is just inexcusable breakage by denying
sudo to the the user doing the install. But thats a separate horse I
think. If you feed it right, you can make it work most of the time.
I believe the phrase we're looking for here is "cast iron bitch"?
Thanks Steve.
--
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: