Hi, I bumped into this issue as well. Upgrading from jessie to strech the networking service that calls `ifup -a` fails because the interface is already configured.
I think this commit is to blame: https://salsa.debian.org/debian/ifupdown/commit/87ca29628d452d7eaa124a943ffb2382743f19e0 What if you have an initramfs script that configures the interface, e.g., during iSCSI boot? In our case an initramfs script, brings up the interfaces and does udhcpc to eventually obtain boot critical metadata from a metadata server, i.e., necessary for iSCSI discovery. Does ifupdown really require that an interface is down to be able to function properly? This seems to be severely limiting. Trying out things, I see that it "works" if the interface is set to inet dhcp, but this seems to be a random but fortunate side-effect of dhclient handling and suppressing the RTNETLINK answers: File exists error. Should somehow the networking.service systemd unit change, or is this supposed to be an ifupdown bug? Thanks, dimara On Wed, 13 Dec 2017 21:25:55 +0100 Ralf Jung <p...@ralfj.de> wrote: > Hi, > > >> The relevant bits of the /etc/network/interfaces.d/* looks as follows: > > [...] > >> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote > >> 185.X.X.X ttl 255 > > [...] > > > > The problem with jessie was that it ignored any errors from > > pre/post-up/down commands. This was fixed in stretch. If you want > > ifupdown to ignore any errors from your pre-up command, just append "|| > > true" to it, like: > > > > pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote > > 185.X.X.X ttl 255 || true > > > > However, this begs the question: why does this fail at all? > > Actually, I am wondering even more why it tries to execute this again > even though the interface is already up. > > > I tried the > > exact same iface stanza on a stretch machine, and doing repeated ifup and > > ifdowns just works as it should. > > ifup should be idempotent, right? Did you try "ifup && ifup"? > > We also have another stretch machine on which this works. So I am a bit > lost about why on one machine, "ifup" tries to bring up an already up > interface. > > >> add tunnel "gre0" failed: File exists > > > > I don't know why it prints "gre0" here, I think that's a bug in ip. > > I see the same behavior. > > > I do > > see it when I manually try to do the ip tunnel add command multiple > > times without ip tunnel del inbetween. > > > >> With exactly the same setup (literally -- this is all automatically > >> deployed), I > >> do not get any errors on our jessie systems. Also the stretch system with > >> a > >> slightly older kernel (4.9.0-3) is not affected. The broken machine has > >> 4.9.0-4-amd64. > > > > Hm, that is also weird. Maybe there is something that causes this tunnel > > to be brought up before ifup tries to do the same? > > Does ifup have state? So, could it be that on one machine it up'ed the > tunnel successfully and that's why it dos not try again, because it > remembers it already did that? > I thought it does not have any state beyond just the kernel network stack. > > ; Ralf > >
signature.asc
Description: Digital signature
