default gateway route not installed for bond interfaces through reboot

Bug #1573272 reported by Zachary Durst on 2016-04-21
138
This bug affects 26 people
Affects Status Importance Assigned to Milestone
vlan (Debian)
New
Unknown
vlan (Ubuntu)
Medium
Dan Streetman
Trusty
Medium
Dan Streetman
Xenial
Medium
Dan Streetman
Yakkety
Medium
Dan Streetman
Zesty
Medium
Dan Streetman
Artful
Medium
Dan Streetman

Bug Description

[Impact]

Systems using vlans, especially those using vlans on top of bond interfaces, in addition to default or other routes on the vlans, may find their vlan routes are not present at boot.

The attached debdiff patches fix the vlan package's /etc/network/if-pre-up.d/vlan script. Currently, the script will bring up a vlan's raw device if needed; but the problem is if the vlan's ifup processing happens before the raw device's ifup processing, the raw device may be taken down and back up (especially for bonds), and when the raw device is taken down, the vlan is as well, and thus loses all its routing configuration. Instead of only bringing the raw device up using ip link up, the patch changes the vlan script to do a full ifup on the raw device, so it will remain up after the vlan is configured.

[Test Case]

Set up a system using two interfaces configured into a bond interface, with a vlan on top of that bond. Add a default route and/or specific routes to the vlan interface. Then edit the system as described in comment 8, and reboot. The vlan's routes will not be present in the system.

[Regression Potential]

Any modifications to ifupdown or the scripts it uses may cause wider problems with network configuration. Specifically, this could cause problems when using vlan interfaces, as it forces every vlan's raw device interface to be fully ifup'ed before the vlan interface can finish its ifup.

[Other Info]

original description below:

Expectation: After reboot, route for default gateway specified on bonded interface is installed according to "gateway x.x.x.x" (where x.x.x.x is a valid IPv4 address) specified in /etc/network/interfaces or files sourced per /etc/network/interfaces

Actual Result: After reboot, route is not installed. Interface does work otherwise (I can ping the gateway on that subnet, for instance). 'ifdown -a' followed by 'ifup -a' (run with proper permission... so sudo) brings the gateway back until next reboot.

Package: I'm not familiar enough to be certain what is causing this, but I was seeing this in beta2 of 16.04 as well.

*username snipped*@*hostname snipped*:~$ lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04
*username snipped*@*hostname snipped*:~$ apt-cache policy ifenslave
ifenslave:
  Installed: 2.7ubuntu1
  Candidate: 2.7ubuntu1
  Version table:
 *** 2.7ubuntu1 100
        100 /var/lib/dpkg/status

*username snipped*@*hostname snipped*:~$ apt-cache policy ifupdown
ifupdown:
  Installed: 0.8.10ubuntu1
  Candidate: 0.8.10ubuntu1
  Version table:
 *** 0.8.10ubuntu1 100
        100 /var/lib/dpkg/status

      /etc/network/interfaces

----------------------------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp2s0f1
iface enp2s0f1 inet manual
bond-master bond0

auto enp2s0f0
iface enp2s0f0 inet manual
bond-master bond0

auto bond0
iface bond0 inet static
        address 10.96.96.2
        netmask 255.255.255.0
        network 10.96.96.0
        broadcast 10.96.96.255
        # dns-* options are implemented by the resolvconf package, if installed
        dns-search *snip*
        bond-mode balance-alb
        bond-slaves none
        bond-miimon 100
auto bond0.3000
iface bond0.3000 inet static
        address 172.21.33.29
        netmask 255.255.255.0
        network 172.21.33.0
        broadcast 172.21.33.255
        gateway 172.21.33.1
        dns-search *snip*
        vlan-raw-device bond0
        dns-nameservers 172.31.10.84 8.8.8.8 4.2.2.2

-----------------------------------------------------
interfaces.d is empty:

*username snipped*@*hostname snipped*:~$ ls -lisah /etc/network/interfaces.d
total 8.0K
10748247 4.0K drwxr-xr-x 2 root root 4.0K Jan 24 14:08 .
10748237 4.0K drwxr-xr-x 7 root root 4.0K Apr 21 17:32 ..

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1573272/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
tags: added: xenial
affects: ubuntu → ifupdown (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ifupdown (Ubuntu):
status: New → Confirmed
Changed in ifupdown (Ubuntu):
importance: Undecided → High
just me (nevdull) wrote :

i think this affects more than just "bond" interfaces, and more than just the gateway setting from /etc/network/interfaces. i think dns- settings are also affected as experienced on 4 of my systems. note bug #1628552

James (jamesmollison) wrote :

Able to replicate this very reliably with any bonded interface on Xenial

Default Gateway (configured in e/n/i) is never set on boot, but always set with any interface raise thereafter.

Jaakko Salo (jvsalo) wrote :

As a workaround, you can do the following (using the original report's config as an example):

# systemctl edit <email address hidden>

Add the following and save the file:

[Unit]
<email address hidden>

Then, let's add Type=oneshot to the ifup@ template so that the above After= actually has some effect:

# systemctl edit ifup@

Add the following and save the file:

[Service]
Type=oneshot

Then reboot.

The problem seems to be a race condition introduced with systemd integration. For me, the missing default route triggered around 80% of the time, but not always.

On Ubuntu 16, systemd executes the ifup@ template units in parallel in a way that is not adequately controlled. For instance, <email address hidden> and ifup@bond0 will execute in parallel. The ifup for bond0 will involve "ip link ... down", then "up" from ifenslave hooks. I believe that if the link down comes after default route from bond0.3000, the default route will be deleted. My journalctl observations support this.

Debugging tip: use systemctl edit ifup@, and add --verbose to the ifup invocations (note, there are 2 of them!). Adding the verbose option to /etc/default/networking does not work, except for lo interface.

Gaëtan Trellu (goldyfruit) wrote :

Any idea if an upstream fix will be applied on Xenial ?
It's a very annoying issue :/

Dan Streetman (ddstreet) wrote :

I set up a default xenial vm with 2 extra interfaces, and configured them with exactly the config you listed in the description, and left it in a reboot loop checking for the default gateway each time, and it hasn't seen the problem at all, after hours of rebooting. Is there a something else specific needed to be able to reproduce this problem?

Dan Streetman (ddstreet) wrote :

Ok I've reproduced this by introducing a delay by changing /lib/systemd/system/ifup@.service

-ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \
+ExecStart=/bin/sh -ec '/usr/bin/test %I == bond0 && echo found bond0 && sleep 3 ; ifup --allow=hotplug %I; ifup --allow=auto %I; \

that reproduces this by allowing bond0.3000 to complete ifup before bond0 is processed, and when bond0 is ifup'ed it clears bond0.3000's gateway due to bond0 going down and back up.

Dan Streetman (ddstreet) wrote :

This patch to the vlan pre-up script should fix this bug, can someone who can easily reproduce it please update your system and retest to verify it fixes the bug? You can just hand-edit your vlan script as shown, to replace the call to ip to instead do a full ifup on the raw device.

--- /etc/network/if-pre-up.d/vlan.orig 2017-03-16 16:50:37.972000000 +0000
+++ /etc/network/if-pre-up.d/vlan 2017-03-16 16:50:45.056000000 +0000
@@ -60,7 +60,7 @@
         exit 1
     fi
     if [ ! -e "/sys/class/net/$IFACE" ]; then
- ip link set up dev $IF_VLAN_RAW_DEVICE
+ ifup $IF_VLAN_RAW_DEVICE
         vconfig add $IF_VLAN_RAW_DEVICE $VLANID
     fi
 fi

Changed in ifupdown (Ubuntu):
assignee: nobody → Dan Streetman (ddstreet)
YannTech (yanntech) wrote :

Seems OK for me

Dan Nica (ndanl) wrote :

confirm, the patch is working for me as well.

Sander van Schie (sander-q) wrote :

The patch fixes the issue for me as well.

Andrey Omelchenko (testworks) wrote :

The patch fixes the issue for me as well. Thank you!

Dan Streetman (ddstreet) wrote :

Thanks everyone, I'll work on getting the patch upstream.

Dan Streetman (ddstreet) wrote :

Marking this as 'invalid' for ifupdown, as the problem is in the vlan package's script.

Changed in vlan (Ubuntu):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → High
status: New → In Progress
Changed in ifupdown (Ubuntu):
status: Confirmed → Invalid
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) on 2017-03-30
description: updated

The attachment "lp1573272-trusty.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Dan Streetman (ddstreet) wrote :

I created a PPA with fixed vlan packages:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1573272

tags: added: sts-sponsor
removed: bot-comment patch xenial
tags: added: patch
Dan Streetman (ddstreet) on 2017-03-30
no longer affects: ifupdown (Ubuntu)
Changed in vlan (Ubuntu):
importance: High → Medium
Changed in vlan (Debian):
status: Unknown → New
Gaëtan Trellu (goldyfruit) wrote :

The patch fixes the issue for me as well. Thanks !

Gaëtan Trellu (goldyfruit) wrote :

I don't know if it's related but since the I'm using this vlan package I have this issue:

Apr 04 17:08:30 compute001 ifup[2396]: Waiting for a slave to join bond0 (will timeout after 60s)
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for parent interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for parent interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for parent interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for parent interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: ifquery: recursion detected for parent interface bond0 in pre-up phase
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: Invalid argument
Apr 04 17:08:30 compute001 ifup[2396]: Failed to bring up bond0.
Apr 04 17:08:30 compute001 ifup[2396]: Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: Invalid argument
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: File exists
Apr 04 17:08:30 compute001 ifup[2396]: Failed to bring up bond0.53.
Apr 04 17:08:30 compute001 ifup[2396]: Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: File exists
Apr 04 17:08:30 compute001 ifup[2396]: Failed to bring up bond0.70.
Apr 04 17:08:30 compute001 ifup[2396]: Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: Invalid argument
Apr 04 17:08:30 compute001 ifup[2396]: RTNETLINK answers: File exists
Apr 04 17:08:30 compute001 ifup[2396]: Failed to bring up bond0.73.
Apr 04 17:08:30 compute001 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 17:08:30 compute001 systemd[1]: Failed to start Raise network interfaces.
-- Subject: Unit networking.service has failed

# apt show vlan
Package: vlan
Version: 1.9-3.2ubuntu1.16.04.1+hf1573272v20170330b1

# uname -r
4.10.0-14-generic

Gaëtan Trellu (goldyfruit) wrote :

Only few of them still down:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno49: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
3: eno50: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
4: ens2f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8c:dc:d4:ae:7e:b0 brd ff:ff:ff:ff:ff:ff
5: ens2f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8c:dc:d4:ae:7e:b1 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
7: bond0.53@bond0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
8: bond0.59@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
9: bond0.70@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
10: bond0.73@bond0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
11: bond0.76@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:5e:7d brd ff:ff:ff:ff:ff:ff
12: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:90:e0:70:68 brd ff:ff:ff:ff:ff:ff

# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.53 | 53 | bond0
bond0.59 | 59 | bond0
bond0.70 | 70 | bond0
bond0.73 | 73 | bond0
bond0.76 | 76 | bond0

Dan Streetman (ddstreet) wrote :

> I don't know if it's related but since the I'm using this vlan package I have this issue:

it's hard to tell just from that output, what does your interfaces file(s) look like?

Gaëtan Trellu (goldyfruit) wrote :

@Dan, I filled a bug about it, seems to be an issue with kernel 4.10: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1679823

Gaël THEROND (fl1nt) wrote :

This doesn't seems to be a kernel issue as I'm having the exact same issue with a fresh Ubunutu 16.04.2 LTS using a 4.4.0 kernel serie and a vlan 1.9.3 package on top of the bonding interface.

I can confirm that this bug is also impacting the dns resolution as even when the vlan interface is filled with the dns-nameserver information the node is not able to resolve a damn domain . It is however able to ping the nameserver.

Jared Baker (shubjero) wrote :

@Gael from what I can tell the fix has not been released based on this bug status is still 'in progress'.

I'm running Ubuntu 16.04 with vlan 1.9-3.2ubuntu1 and it still contains the 'ip link set up dev $IF_VLAN_RAW_DEVICE' on line 63 of /etc/network/if-pre-up.d/vlan . You can modify the file yourself using Dan's instructions on step 9. Works like a charm for me.

Dan Streetman (ddstreet) wrote :

Right, this isn't fixed yet. I'll try to get this into Artful asap.

Gaël THEROND (fl1nt) wrote :

Thanks a lot Dan and Jared.

As this node is intended to be used on a critical production service, I'll rather wait for the patch rolling from ubuntu repos.

In order to be sure that it will fix the issue, I've patch the script file manually and it working fine.

Dan Streetman (ddstreet) on 2017-05-22
tags: added: sts-sru-needed
removed: sts-sponsor
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :

updated release debdiffs to correct version numbers, and add debdiff for artful.

Dan Streetman (ddstreet) wrote :

Robie, you uploaded the last couple vlan pkg changes, can you review/sponsor this change also?

Robie Basak (racb) wrote :

Hi Dan,

I'm not particularly familiar with ifupdown. The reentrancy is a red flag for me. Is there an existing example of ifup being called from an if-pre-up.d script?

I think it would be best to get a review from someone more familiar with this area before upload.

Dan Streetman (ddstreet) wrote :

> The reentrancy is a red flag for me. Is there an existing example of ifup being
> called from an if-pre-up.d script?

yes, the ifenslave if-pre-up.d script does call ifup for all its slave interfaces, i.e.:

# Bring up slave if it is the target of an allow-bondX stanza.
# This is usefull to bring up slaves that need extra setup.
if [ -z "$(which ifquery)" ] || ifquery --allow \"$BOND_MASTER\" --list | grep -q $slave; then
    ifup $v --allow "$BOND_MASTER" "$slave"
fi

> I think it would be best to get a review from someone more familiar with this
> area before upload.

ok I'll ping one of the ifupdown-related coredevs.

Dan Streetman (ddstreet) wrote :

smoser, stgraber, you guys have done some ifupdown and/or vlan uploads/changes before...can either of you review and/or sponsor this into artful?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3.2ubuntu3

---------------
vlan (1.9-3.2ubuntu3) artful; urgency=medium

  * In vlan ifupdown pre-up script, instead of calling ip link up for
    raw device before creating vlan interface, do a full ifup for raw
    device. Otherwise, if raw device processes ifup after vlan device,
    the raw device may be taken down and back up, which removes all vlan
    routes and other configuration. (LP: #1573272)

 -- Dan Streetman <email address hidden> Thu, 30 Mar 2017 09:16:10 -0400

Changed in vlan (Ubuntu Artful):
status: In Progress → Fix Released
Eric Desrochers (slashd) on 2017-05-26
tags: added: sts-sru-done
removed: patch sts-sru-needed
Changed in vlan (Ubuntu Zesty):
assignee: nobody → Dan Streetman (ddstreet)
Changed in vlan (Ubuntu Yakkety):
assignee: nobody → Dan Streetman (ddstreet)
Changed in vlan (Ubuntu Xenial):
assignee: nobody → Dan Streetman (ddstreet)
Changed in vlan (Ubuntu Trusty):
assignee: nobody → Dan Streetman (ddstreet)
status: New → In Progress
Changed in vlan (Ubuntu Xenial):
status: New → In Progress
Changed in vlan (Ubuntu Yakkety):
status: New → In Progress
Changed in vlan (Ubuntu Zesty):
status: New → In Progress
Changed in vlan (Ubuntu Trusty):
importance: Undecided → Medium
Changed in vlan (Ubuntu Xenial):
importance: Undecided → Medium
Changed in vlan (Ubuntu Zesty):
importance: Undecided → Medium
Changed in vlan (Ubuntu Yakkety):
importance: Undecided → Medium

Hello Zachary, or anyone else affected,

Accepted vlan into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu2.17.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in vlan (Ubuntu Yakkety):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu2.16.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Xenial):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu1.16.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Trusty):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3ubuntu10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Dan Streetman (ddstreet) wrote :

Note, this change breaks the system configuration where an ifupdown vlan is configured, but the raw device is not configured in ifupdown. I'm working on an additional patch fix this.

Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :

Attached v2 patches for artful and SRU releases; instead of changing the vlan if-pre-up.d script to use only ifup instead of ip link up, change the script to use both; first try ifup for the vlan raw device, then if that fails (e.g. because ifupdown has no configuration for the vlan raw device) try directly bringing up the vlan raw device using the previous way, i.e. ip link set DEV up.

Changed in vlan (Ubuntu Artful):
status: Fix Released → New
Eric Desrochers (slashd) on 2017-05-29
tags: added: sts-sru-needed
removed: sts-sru-done
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3.2ubuntu4

---------------
vlan (1.9-3.2ubuntu4) artful; urgency=medium

  * Correct previous patch, to work for ifupdown configuration where a
    vlan is configured but the vlan's raw device has no ifupdown config.
    (LP: #1573272)

 -- Dan Streetman <email address hidden> Mon, 29 May 2017 18:13:27 -0400

Changed in vlan (Ubuntu Artful):
status: New → Fix Released
Stefan Bader (smb) wrote :

Manually applied the fixup delta on a host which had the issue (not having a base device configured) and it comes up with network/vlan working (just a pre-proposed hint but I am not sure I can do a timely verification with the proposed package).

Eric Desrochers (slashd) wrote :

Hi dan,

v2 debdiffs has been uploaded in the upload queue for all affected stable releases.

- Eric

Changed in vlan (Ubuntu Zesty):
status: Fix Committed → In Progress
Changed in vlan (Ubuntu Yakkety):
status: Fix Committed → In Progress
Changed in vlan (Ubuntu Trusty):
status: Fix Committed → In Progress
Changed in vlan (Ubuntu Xenial):
status: Fix Committed → In Progress
tags: added: sts-sru-done
removed: sts-sru-needed
Eric Desrochers (slashd) wrote :

and a explanation has been publicly made at the attention of all SRU members on Freenode (#ubuntu-release) to explain them the context of this new upload to overwrite/replace the actual -proposed package(s) having the regression.

tags: removed: verification-needed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu2.17.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in vlan (Ubuntu Yakkety):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu2.16.10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Xenial):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu1.16.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Trusty):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3ubuntu10.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Dan Streetman (ddstreet) wrote :

Testing on artful:

I created a virtual guest with extra interfaces to use for testing, all connected to a single host bridge, which are named ens7-12 in the guest. I added e/n/i configuration to test both for the original problem for this bug (vlan on bond loses gateway) as well as the bug introduced by the first patch (vlan without raw device ifupdown config fails), with this configuration:

auto ens7.100
iface ens7.100 inet static
 address 1.2.3.5/24
 gateway 1.2.3.1
 metric 1000
 vlan-raw-device ens7

auto ens8
iface ens8 inet manual
 bond-master bond0

auto ens9
iface ens9 inet manual
 bond-master bond0

auto bond0
iface bond0 inet static
 address 4.5.6.8/24
 gateway 4.5.6.1
 metric 2000
 bond-slaves none
 bond-mode balance-alb

auto bond0.200
iface bond0.200 inet static
 address 9.8.7.7/24
 gateway 9.8.7.1
 metric 3000
 vlan-raw-device bond0

Notes:
'ens7.100' does not have any corresponding 'ens7' configuration.
'bond0' requires the 'bond-mode' option to trigger this bug, as it takes down the interface while changing the mode; the other options that take down the interface are 'xmit_hash_policy', 'ad_select', and 'lacp_rate'.

Without the modification from comment 8, I could not reproduce the bug (as expected since it's a race condition), but with that modification I could reproduce the bug with vlan version:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu2

The bond0.200 gateway is missing:

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.160

After upgrading to vlan version:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu4

The bond0.200 gateway is present:

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
default via 9.8.7.1 dev bond0.200 metric 3000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.160

Additionally, the ens7.100 vlan is correctly configured, even without any ens7 raw device ifupdown config.

tags: added: verification-done-artful
Dan Streetman (ddstreet) wrote :

Testing on zesty, same e/n/i configuration as artful, same /lib/systemd/system/ifup@.service modification to trigger bug:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu2

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.131

bond0.200 gateway missing as expected.

After upgrading vlan to -proposed version, bond0.200 gateway is present and ens7.100 vlan is configured correctly:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu2.17.04.2

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
default via 9.8.7.1 dev bond0.200 metric 3000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.131

tags: added: verification-done-zesty
Dan Streetman (ddstreet) wrote :

Testing on yakkety, same e/n/i config and systemd ifup@.service modification:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu2

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.235

bond0.200 gw missing as expected; after upgrading to -proposed vlan:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu2.16.10.2

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
default via 9.8.7.1 dev bond0.200 metric 3000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.235

bond0.200 gw present, ens7.100 vlan present

tags: added: verification-done-yakkety
Dan Streetman (ddstreet) wrote :

Testing on xenial, same e/n/i config and ifup@.service change:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu1.16.04.1

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.11

After upgrading to -proposed vlan:

$ dpkg -l | grep vlan
ii vlan 1.9-3.2ubuntu1.16.04.3

$ ip r
default via 192.168.122.1 dev ens3
default via 1.2.3.1 dev ens7.100 metric 1000 onlink
default via 4.5.6.1 dev bond0 metric 2000 onlink
default via 9.8.7.1 dev bond0.200 metric 3000 onlink
1.2.3.0/24 dev ens7.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.11

bond0.200 gw present, ens7.100 vlan present

tags: added: verification-done-xenial
Dan Streetman (ddstreet) wrote :
Download full text (4.6 KiB)

Unfortunately, verification for this fails on trusty.

tl;dr:

The patches so far work to fix this on x/y/z/a, but trusty will need an additional patch to unconditionally call 'ip link set up', since the return code of 'ifup' on trusty can't be trusted. I'll attach that trusty debdiff.

Long explanation:

First, I will explain why the attached patches work, which requires explaining the entire process of device detection to udev processing to ifup processing.

When udev detects a network device, it matches the rule in '/lib/udev/rules.d/NN-vlan-network-interface.rules' (the NN varies by release). This rule matches the 'add' for all network device, and calls the vlan-package-provided script /lib/udev/vlan-network-interface. This script then does 'ifquery --list --allow auto' for a listing of all interfaces defined in ifupdown configuration that are set to 'auto' configuration. If it detects that the net device that udev just detected is defined as a 'vlan-raw-device' (or e.g. 'eth1' is part of the name 'eth1.100' so vlan-raw-device is assumed), then this script, called from udev, actually executes the ifupdown if-pre-up.d/vlan script; without calling ifup!

That pre-up script is what actually creates the vlan interface; then once the vlan interface is created, udev gets an add event for it, and notifies ifup to actually configure it.

So now, we get to why the patches for this bug 'work'.

In the /etc/network/if-pre-up.d/vlan script, the patch makes this change:

     if [ ! -e "/sys/class/net/$IFACE" ]; then
- ip link set up dev $IF_VLAN_RAW_DEVICE
+ # Try ifup for the raw device, if it fails then bring it up directly
+ # this is required e.g. there is no configuration for the raw device
+ ifup $IF_VLAN_RAW_DEVICE || ip link set up dev $IF_VLAN_RAW_DEVICE
         vconfig add $IF_VLAN_RAW_DEVICE $VLANID
     fi

This direct call to 'ifup' from the vlan pre-up script works ONLY when the vlan script is called from the udev script /lib/udev/vlan-network-interface. When the vlan script is later called from ifup itself as a pre-up script, the ifup call is detected as 'recursive locking' and fails (except on trusty...more on that later). However, since the vlan pre-up script was *already* run from the udev script, nothing it does during the ifup pre-up execution matters; it's all redundant actions. (Note - it's *only* redundant during a device hotplug, not manual ifup - but more on that later too). So, it works like this:

1. One of the bond's slaves is hotplugged/enumerated and detected by udev, which then runs ifup for it. During its ifup, it detects its bond-master configuration, and creates the master bond interface, and then waits in a loop until its master is detected and enslaves itself.

2. When udev detects the bond interface, it runs the vlan-network-interface script for it, and that detects that the bond is the vlan-raw-device for another interface, so it calls the if-pre-up.d/vlan script; this is done *without* the ifupdown device lock, since it's outside of an ifup call for the bond or child vlan interface.

2a. Previously, that if-pre-up.d/vlan script would call 'ip link set up' for the bond inter...

Read more...

Dan Streetman (ddstreet) wrote :

Additional debdiff for trusty, as ifup return code on trusty can't be trusted.

Dan Streetman (ddstreet) on 2017-06-05
tags: added: verification-needed-trusty
removed: verification-needed
Eric Desrochers (slashd) on 2017-06-05
Changed in vlan (Ubuntu Trusty):
status: Fix Committed → In Progress
Dan Streetman (ddstreet) on 2017-06-05
tags: added: verification-failed-trusty
removed: verification-needed-trusty
Eric Desrochers (slashd) on 2017-06-05
tags: removed: verification-done-artful
Dan Streetman (ddstreet) on 2017-06-06
tags: added: verification-done-artful
Brian Murray (brian-murray) wrote :

Hello Zachary, or anyone else affected,

Accepted vlan into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vlan/1.9-3ubuntu10.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vlan (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Dan Streetman (ddstreet) wrote :

Testing on trusty, same (except interface names, e.g. ens7 -> eth1, etc) e/n/i config as comment 61. I could not use the systemd change from comment 8, since trusty uses upstart, and I could not find the proper place in upstart code to introduce a delay to more easily reproduce the bug, but I did verify that the -proposed package results in the correct result:

$ dpkg -l | grep vlan
ii vlan 1.9-3ubuntu10.4

$ ip r
default via 192.168.122.1 dev eth0
default via 1.2.3.1 dev eth1.100 metric 1000
default via 4.5.6.1 dev bond0 metric 2000
default via 9.8.7.1 dev bond0.200 metric 3000
1.2.3.0/24 dev eth1.100 proto kernel scope link src 1.2.3.5
4.5.6.0/24 dev bond0 proto kernel scope link src 4.5.6.8
9.8.7.0/24 dev bond0.200 proto kernel scope link src 9.8.7.7
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.146

tags: added: verification-done-trusty
removed: verification-failed-trusty
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3.2ubuntu2.17.04.2

---------------
vlan (1.9-3.2ubuntu2.17.04.2) zesty; urgency=medium

  * Correct previous patch, to work for ifupdown configuration where a
    vlan is configured but the vlan's raw device has no ifupdown config.
    (LP: #1573272)

 -- Dan Streetman <email address hidden> Mon, 29 May 2017 18:13:27 -0400

Changed in vlan (Ubuntu Zesty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for vlan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3.2ubuntu2.16.10.2

---------------
vlan (1.9-3.2ubuntu2.16.10.2) yakkety; urgency=medium

  * Correct previous patch, to work for ifupdown configuration where a
    vlan is configured but the vlan's raw device has no ifupdown config.
    (LP: #1573272)

 -- Dan Streetman <email address hidden> Mon, 29 May 2017 18:13:27 -0400

Changed in vlan (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3.2ubuntu1.16.04.3

---------------
vlan (1.9-3.2ubuntu1.16.04.3) xenial; urgency=medium

  * Correct previous patch, to work for ifupdown configuration where a
    vlan is configured but the vlan's raw device has no ifupdown config.
    (LP: #1573272)

 -- Dan Streetman <email address hidden> Mon, 29 May 2017 18:13:27 -0400

Changed in vlan (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlan - 1.9-3ubuntu10.4

---------------
vlan (1.9-3ubuntu10.4) trusty; urgency=medium

  * Don't trust ifup return code, as it returns 0 on failure; call ip link
    set up after ifup to force vlan raw device up. (LP: #1573272)

 -- Dan Streetman <email address hidden> Mon, 05 Jun 2017 12:12:01 -0400

Changed in vlan (Ubuntu Trusty):
status: Fix Committed → Fix Released
Tom Verdaat (tom-verdaat) wrote :

Found this bug ticket while troubleshooting a networking issue with bonding and vlans after upgrading the vlan package. Reported it here: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1636708/comments/11

Any chance this change caused that issue?

Robie Basak (racb) wrote :

@Tom

Can you verify that downgrading to 1.9-3.2ubuntu1.16.04.2 and rebooting makes the problem disappear, and that upgrading again to 1.9-3.2ubuntu1.16.04.3 and rebooting makes the problem appear again? You can grab the older debs from https://launchpad.net/ubuntu/+source/vlan/+publishinghistory. Click on the version, then on your architecture from under Builds.

Dan Streetman (ddstreet) wrote :

@tom-verdaat, your problem sounds like a new issue separate from bug 1636708 - can you please open a new bug.

Alexey Zagarin (zagarin) wrote :

> In vlan ifupdown pre-up script, instead of calling ip link up for raw device before creating vlan interface, do a full ifup for raw device.

Doing so introduces another kind of problem. Consider the following setup:

auto eno1
iface eno1 inet dhcp

auto eno1.101
iface eno1.101 inet manual
  vlan-raw-device eno1

In this case, ifup is calling dhclient that then exits, leaving eno1 interface in a state when DHCP lease never gets renewed:

/bin/sh /lib/udev/vlan-network-interface
 \_ /bin/sh /etc/network/if-pre-up.d/vlan
     \_ ifup eno1
         \_ /bin/sh -c /sbin/dhclient -1 -v -pf /run/dhclient.eno1.pid -lf /var/lib/dhcp/dhclient.eno1.leases -I -df /var/lib/dhcp/dhclient6.eno1.leases eno1 .
             \_ /sbin/dhclient -1 -v -pf /run/dhclient.eno1.pid -lf /var/lib/dhcp/dhclient.eno1.leases -I -df /var/lib/dhcp/dhclient6.eno1.leases eno1

Dan Streetman (ddstreet) wrote :

@zagarin please see bug 1701023

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.