Re: i386 version for chrome
Hi.
On Sun, Oct 28, 2018 at 05:59:52AM -0400, Gene Heskett wrote:
> On Sunday 28 October 2018 02:55:09 Reco wrote:
>
> > Hi.
> >
> > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote:
> > > On Saturday 27 October 2018 14:37:38 Reco wrote:
> > > > Hi.
> > > >
> > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > > > > 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.
> > > >
> > > > In another news, you cannot have a default gateway unless it's
> > > > reachable according to existing routing table.
> > >
> That is the problem, a route -n is without a gateway assignment and has
> been missing since my first attempt to install stretch.
Ok.
> > > Its reachable, and listed in every hosts file here by both name and
> > > address.
> >
> > Not before you bring up any non-local network interface.
>
> Then why, after giving the installer all that info, and it uses that
> during the install, does it not have a gateway set after the initial
> reboot or any subsequent reboot?
Works for me every time I tried it, so I cannot answer that.
> And nothing you can do will give it a gateway, so you wind up playing
> 10,000 monkeys writing Shakespear, and a reboot for every session of
> nano trying to find the magic twanger that makes it work? I have made
> jessie work on an armhf but its been done after the initial reboot. An
> armbian install that claims its debian 9, is the only install out of 5
> or 6 from various sources including the debian-arm iso twice.
>
> For the jessie install on an r-pi-3b, this /e/n/i works:
>
> auto lo
>
> # The loopback network interface
> iface lo inet loopback
> address 127.0.0.1
> netmask 255.255.255.0
>
> auto eth0
>
> # regular network for coyote.den
> iface eth0 inet static
> address 192.168.NN.12
> netmask 255.255.255.0
> gateway 192.168.NN.1
>
> but it doesn't work if the interface address is given in address/24
> format so the netmask isn't needed.
Ever consider you're doing it the wrong way?
This will work:
iface eth0 inet static
address 192.168.NN.12
netmask 24
gateway 192.168.NN.1
> To me, thats all the evidence needed
> to point the guilty finger at something in the ifup code.
Accusing software of something may ease one's mind, but it won't make it
work. Usually, that is.
> > > > The reason is simple - a default gateway is not 'global', the
> > > > kernel must decide with interface to attach to a default gateway
> > > > route. So you bring a network interface up, add an address to it
> > > > and only then configure a default gateway.
> > >
> > > Then how does one guarantee its done in that order?
> >
> > By using ifupdown, for instance.
> >
> > > And what was changed
> > > to prevent its working in the newer way of doing things?
They have this wonderful principle at movie industry - show but do not
tell.
Please provide 'ifup -v' output that shows ifupdown misbehaviour, or it
did not happen.
> > ifupdown works for me that way since etch was testing.
> > If it does not - there's always troubleshooting in form of 'ifup -v'.
>
> As in "ifup -vvv eth0"?
-vvv is not documented, and I'm too lazy to dig into the source to see
if it does something at all.
ifdown eth0
ifup -v eth0
> What log file, on stretch, would I find that trace data in?
Stdout/stderr, as documented by ifup(8).
> Theres not anything in /v/l/syslog w/o the -v.
And there should not be anything about ifupdown, unless someone
redirects stdout/stderr of /etc/init.d/networking to syslog.
Reco
Reply to: