Does apt upgrade trigger netplan apply in 18.04?
0
I did apt-get update; apt upgrade on a remote server over SSH. netplan.io and some systemd packages were upgraded. I switched to a different screen window, but after just a few seconds the SSH connection stopped. All network connectivity is now lost.
This happened once before during an update of netplan.io. Then, a simple sudo ifdown (WAN-if); sudo ifup (WAN-if) on the physical console fixed the problem.
My server runs 18.04.1 LTS with blank configuration for netplan, blank configuration for systemd-networkd (which is the backend), with all interfaces statically configured in /etc/network/interfaces, and "ifupdown" installed. Reboots work just fine.
Could it be that netplan apply is only triggered on apt upgrade of netplan.io?
EDIT: These are the packages that were updated that killed the WAN interface, as copied from /var/log/apt/history.log:
Start-Date: 2019-01-15 12:43:10
Commandline: apt upgrade
Requested-By: user (1234)
Upgrade: libkrb5-3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), libgssapi-krb5-2:amd64 (1.16-2build1, 1.16-2ubuntu0.1), netplan.io:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), libcom-err2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), gnupg-utils:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-wks-client:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), python3-software-properties:amd64 (0.96.24.32.6, 0.96.24.32.7), gnupg-l10n:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libibverbs1:amd64 (17.1-1, 17.1-1ubuntu0.1), libsystemd0:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), e2fsprogs:amd64 (1.44.1-1, 1.44.1-1ubuntu1), librbd1:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), ibverbs-providers:amd64 (17.1-1, 17.1-1ubuntu0.1), gpg-wks-server:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libk5crypto3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), udev:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), librdmacm1:amd64 (17.1-1, 17.1-1ubuntu0.1), initramfs-tools-bin:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), libudev1:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), krb5-locales:amd64 (1.16-2build1, 1.16-2ubuntu0.1), nplan:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), dirmngr:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libss2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), libext2fs2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), psmisc:amd64 (23.1-1, 23.1-1ubuntu0.1), libkrb5support0:amd64 (1.16-2build1, 1.16-2ubuntu0.1), systemd-sysv:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), gpgv:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libpam-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss3:amd64 (2:3.35-2ubuntu2, 2:3.35-2ubuntu2.1), linux-firmware:amd64 (1.173.2, 1.173.3), gnupg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-agent:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), librados2:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), initramfs-tools-core:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgconf:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), initramfs-tools:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgsm:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), tzdata:amd64 (2018g-0ubuntu0.18.04, 2018i-0ubuntu0.18.04), software-properties-common:amd64 (0.96.24.32.6, 0.96.24.32.7)
End-Date: 2019-01-15 12:45:04
The WAN interface configuration:
auto eno1
#iface eno1 inet dhcp
iface eno1 inet static
address a.b.c.X
netmask 255.255.255.NNN
gateway a.b.c.Y
dns-nameservers e.f.g.h i.j.k.l
up ip addr add a.b.c.Z/BB dev eno1
The funny thing is that the LAN interface used for trunking, was unaffected (still up and running):
auto eno2
iface eno2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto vlan3
iface vlan3 inet manual
vlan-raw-device eno2
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto br3
iface br3 inet static
address a.b.m.n
netmask 255.255.255.128
up ip addr add a.b.m.n-1/25 dev br3
down ip addr del a.b.m.n-1/25 dev br3
bridge_ports vlan3
bridge_stp off
networking apt 18.04 upgrade netplan
asked Jan 16 at 16:19
perryperry
12
add a comment |
0
I did apt-get update; apt upgrade on a remote server over SSH. netplan.io and some systemd packages were upgraded. I switched to a different screen window, but after just a few seconds the SSH connection stopped. All network connectivity is now lost.
This happened once before during an update of netplan.io. Then, a simple sudo ifdown (WAN-if); sudo ifup (WAN-if) on the physical console fixed the problem.
My server runs 18.04.1 LTS with blank configuration for netplan, blank configuration for systemd-networkd (which is the backend), with all interfaces statically configured in /etc/network/interfaces, and "ifupdown" installed. Reboots work just fine.
Could it be that netplan apply is only triggered on apt upgrade of netplan.io?
EDIT: These are the packages that were updated that killed the WAN interface, as copied from /var/log/apt/history.log:
Start-Date: 2019-01-15 12:43:10
Commandline: apt upgrade
Requested-By: user (1234)
Upgrade: libkrb5-3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), libgssapi-krb5-2:amd64 (1.16-2build1, 1.16-2ubuntu0.1), netplan.io:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), libcom-err2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), gnupg-utils:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-wks-client:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), python3-software-properties:amd64 (0.96.24.32.6, 0.96.24.32.7), gnupg-l10n:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libibverbs1:amd64 (17.1-1, 17.1-1ubuntu0.1), libsystemd0:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), e2fsprogs:amd64 (1.44.1-1, 1.44.1-1ubuntu1), librbd1:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), ibverbs-providers:amd64 (17.1-1, 17.1-1ubuntu0.1), gpg-wks-server:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libk5crypto3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), udev:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), librdmacm1:amd64 (17.1-1, 17.1-1ubuntu0.1), initramfs-tools-bin:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), libudev1:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), krb5-locales:amd64 (1.16-2build1, 1.16-2ubuntu0.1), nplan:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), dirmngr:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libss2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), libext2fs2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), psmisc:amd64 (23.1-1, 23.1-1ubuntu0.1), libkrb5support0:amd64 (1.16-2build1, 1.16-2ubuntu0.1), systemd-sysv:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), gpgv:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libpam-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss3:amd64 (2:3.35-2ubuntu2, 2:3.35-2ubuntu2.1), linux-firmware:amd64 (1.173.2, 1.173.3), gnupg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-agent:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), librados2:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), initramfs-tools-core:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgconf:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), initramfs-tools:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgsm:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), tzdata:amd64 (2018g-0ubuntu0.18.04, 2018i-0ubuntu0.18.04), software-properties-common:amd64 (0.96.24.32.6, 0.96.24.32.7)
End-Date: 2019-01-15 12:45:04
The WAN interface configuration:
auto eno1
#iface eno1 inet dhcp
iface eno1 inet static
address a.b.c.X
netmask 255.255.255.NNN
gateway a.b.c.Y
dns-nameservers e.f.g.h i.j.k.l
up ip addr add a.b.c.Z/BB dev eno1
The funny thing is that the LAN interface used for trunking, was unaffected (still up and running):
auto eno2
iface eno2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto vlan3
iface vlan3 inet manual
vlan-raw-device eno2
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto br3
iface br3 inet static
address a.b.m.n
netmask 255.255.255.128
up ip addr add a.b.m.n-1/25 dev br3
down ip addr del a.b.m.n-1/25 dev br3
bridge_ports vlan3
bridge_stp off
networking apt 18.04 upgrade netplan
asked Jan 16 at 16:19
perryperry
12
It sounds like while it was running the upgrades it performed anifupdownwhich caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.
– Terrance
Jan 16 at 16:39
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago
add a comment |
0
0
0
I did apt-get update; apt upgrade on a remote server over SSH. netplan.io and some systemd packages were upgraded. I switched to a different screen window, but after just a few seconds the SSH connection stopped. All network connectivity is now lost.
This happened once before during an update of netplan.io. Then, a simple sudo ifdown (WAN-if); sudo ifup (WAN-if) on the physical console fixed the problem.
My server runs 18.04.1 LTS with blank configuration for netplan, blank configuration for systemd-networkd (which is the backend), with all interfaces statically configured in /etc/network/interfaces, and "ifupdown" installed. Reboots work just fine.
Could it be that netplan apply is only triggered on apt upgrade of netplan.io?
EDIT: These are the packages that were updated that killed the WAN interface, as copied from /var/log/apt/history.log:
Start-Date: 2019-01-15 12:43:10
Commandline: apt upgrade
Requested-By: user (1234)
Upgrade: libkrb5-3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), libgssapi-krb5-2:amd64 (1.16-2build1, 1.16-2ubuntu0.1), netplan.io:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), libcom-err2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), gnupg-utils:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-wks-client:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), python3-software-properties:amd64 (0.96.24.32.6, 0.96.24.32.7), gnupg-l10n:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libibverbs1:amd64 (17.1-1, 17.1-1ubuntu0.1), libsystemd0:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), e2fsprogs:amd64 (1.44.1-1, 1.44.1-1ubuntu1), librbd1:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), ibverbs-providers:amd64 (17.1-1, 17.1-1ubuntu0.1), gpg-wks-server:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libk5crypto3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), udev:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), librdmacm1:amd64 (17.1-1, 17.1-1ubuntu0.1), initramfs-tools-bin:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), libudev1:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), krb5-locales:amd64 (1.16-2build1, 1.16-2ubuntu0.1), nplan:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), dirmngr:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libss2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), libext2fs2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), psmisc:amd64 (23.1-1, 23.1-1ubuntu0.1), libkrb5support0:amd64 (1.16-2build1, 1.16-2ubuntu0.1), systemd-sysv:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), gpgv:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libpam-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss3:amd64 (2:3.35-2ubuntu2, 2:3.35-2ubuntu2.1), linux-firmware:amd64 (1.173.2, 1.173.3), gnupg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-agent:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), librados2:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), initramfs-tools-core:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgconf:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), initramfs-tools:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgsm:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), tzdata:amd64 (2018g-0ubuntu0.18.04, 2018i-0ubuntu0.18.04), software-properties-common:amd64 (0.96.24.32.6, 0.96.24.32.7)
End-Date: 2019-01-15 12:45:04
The WAN interface configuration:
auto eno1
#iface eno1 inet dhcp
iface eno1 inet static
address a.b.c.X
netmask 255.255.255.NNN
gateway a.b.c.Y
dns-nameservers e.f.g.h i.j.k.l
up ip addr add a.b.c.Z/BB dev eno1
The funny thing is that the LAN interface used for trunking, was unaffected (still up and running):
auto eno2
iface eno2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto vlan3
iface vlan3 inet manual
vlan-raw-device eno2
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto br3
iface br3 inet static
address a.b.m.n
netmask 255.255.255.128
up ip addr add a.b.m.n-1/25 dev br3
down ip addr del a.b.m.n-1/25 dev br3
bridge_ports vlan3
bridge_stp off
networking apt 18.04 upgrade netplan
asked Jan 16 at 16:19
perryperry
12
I did apt-get update; apt upgrade on a remote server over SSH. netplan.io and some systemd packages were upgraded. I switched to a different screen window, but after just a few seconds the SSH connection stopped. All network connectivity is now lost.
This happened once before during an update of netplan.io. Then, a simple sudo ifdown (WAN-if); sudo ifup (WAN-if) on the physical console fixed the problem.
My server runs 18.04.1 LTS with blank configuration for netplan, blank configuration for systemd-networkd (which is the backend), with all interfaces statically configured in /etc/network/interfaces, and "ifupdown" installed. Reboots work just fine.
Could it be that netplan apply is only triggered on apt upgrade of netplan.io?
EDIT: These are the packages that were updated that killed the WAN interface, as copied from /var/log/apt/history.log:
Start-Date: 2019-01-15 12:43:10
Commandline: apt upgrade
Requested-By: user (1234)
Upgrade: libkrb5-3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), libgssapi-krb5-2:amd64 (1.16-2build1, 1.16-2ubuntu0.1), netplan.io:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), libcom-err2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), gnupg-utils:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-wks-client:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), python3-software-properties:amd64 (0.96.24.32.6, 0.96.24.32.7), gnupg-l10n:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libibverbs1:amd64 (17.1-1, 17.1-1ubuntu0.1), libsystemd0:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), e2fsprogs:amd64 (1.44.1-1, 1.44.1-1ubuntu1), librbd1:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), ibverbs-providers:amd64 (17.1-1, 17.1-1ubuntu0.1), gpg-wks-server:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libk5crypto3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), udev:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), librdmacm1:amd64 (17.1-1, 17.1-1ubuntu0.1), initramfs-tools-bin:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), libudev1:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), krb5-locales:amd64 (1.16-2build1, 1.16-2ubuntu0.1), nplan:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), dirmngr:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libss2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), libext2fs2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), psmisc:amd64 (23.1-1, 23.1-1ubuntu0.1), libkrb5support0:amd64 (1.16-2build1, 1.16-2ubuntu0.1), systemd-sysv:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), gpgv:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libpam-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss3:amd64 (2:3.35-2ubuntu2, 2:3.35-2ubuntu2.1), linux-firmware:amd64 (1.173.2, 1.173.3), gnupg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-agent:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), librados2:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), initramfs-tools-core:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgconf:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), initramfs-tools:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgsm:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), tzdata:amd64 (2018g-0ubuntu0.18.04, 2018i-0ubuntu0.18.04), software-properties-common:amd64 (0.96.24.32.6, 0.96.24.32.7)
End-Date: 2019-01-15 12:45:04
The WAN interface configuration:
auto eno1
#iface eno1 inet dhcp
iface eno1 inet static
address a.b.c.X
netmask 255.255.255.NNN
gateway a.b.c.Y
dns-nameservers e.f.g.h i.j.k.l
up ip addr add a.b.c.Z/BB dev eno1
The funny thing is that the LAN interface used for trunking, was unaffected (still up and running):
auto eno2
iface eno2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto vlan3
iface vlan3 inet manual
vlan-raw-device eno2
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto br3
iface br3 inet static
address a.b.m.n
netmask 255.255.255.128
up ip addr add a.b.m.n-1/25 dev br3
down ip addr del a.b.m.n-1/25 dev br3
bridge_ports vlan3
bridge_stp off
networking apt 18.04 upgrade netplan
networking apt 18.04 upgrade netplan
asked Jan 16 at 16:19
perryperry
12
asked Jan 16 at 16:19
perryperry
12
edited 21 hours ago
perry
asked Jan 16 at 16:19
perryperry
12
asked Jan 16 at 16:19
perryperry
12
asked Jan 16 at 16:19
perryperry
12
12
It sounds like while it was running the upgrades it performed anifupdownwhich caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.
– Terrance
Jan 16 at 16:39
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago
add a comment |
It sounds like while it was running the upgrades it performed anifupdownwhich caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.
– Terrance
Jan 16 at 16:39
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago
It sounds like while it was running the upgrades it performed an
ifupdown which caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.– Terrance
Jan 16 at 16:39
It sounds like while it was running the upgrades it performed an
ifupdown which caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.– Terrance
Jan 16 at 16:39
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110323%2fdoes-apt-upgrade-trigger-netplan-apply-in-18-04%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110323%2fdoes-apt-upgrade-trigger-netplan-apply-in-18-04%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It sounds like while it was running the upgrades it performed an
ifupdownwhich caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc.– Terrance
Jan 16 at 16:39
ifupdown could be a possible explanation as well. The first time this happened, it happened exactly as netplan.io was upgraded and configured, because that's where the output stopped.
– perry
2 days ago
A comment in /etc/network/interfaces caused raise network interfaces to fail: 'iface br4 inet static # COMMENT'. After removing, raise network interfaces doesn't fail. The command was 'systemctl restart networking', and the output in journalctl -xe was 'ifup[30436]: /etc/network/interfaces:98: extra parameter for the iface line not understood and ignored: #' and 'systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE' and 'systemd[1]: networking.service: Failed with result 'exit-code'.' and 'systemd[1]: Failed to start Raise network interfaces.'
– perry
20 hours ago
It seems a little over the top that a comment on one bridge should cause a totally different interface to lose its configuration, but as I found dozens and dozens of log errors about interfaces:98 for just one run of restart networking, and the end result was FAILED, I just assume that the process stopped half-way through and that the WAN interface inconsistent state happened because it was the first interface to be reconfigured.
– perry
20 hours ago
Sounds like that is your answer. You should write that up separately and select it as the accepted answer. When running the updates remotely like that, when you lose the connection because of the cycle of the interface it will stop the whole upgrade process at that time as the session will end. Many times in my first dealings with remote server administration, myself and the other guys I had worked with had to run back to the office and bring it back up and start over.
– Terrance
14 hours ago