Following https://www.debian.org/doc/debian-policy/ap-flowcharts.html
postinst gets called as 'postinst configure' w/o second argument on
first installation, use that information instead of creating a
flag-file in preinst.
Technically this changes the semantics and the first-install parts
will not be run, in case ifupdown2 had been installed on the system,
but was subsequently removed, but not purged ('rc' in dpkg-output).
Since the functionality was added quite a while ago (released with PVE
6.2 to support ovs-setups with ifupdown2 - the potential for
regression should be limited. Originally introduced in:
849ae55de6
Fixes: 8d5303c350
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
erroring out here will not help getting a running network, therefore
just log a warning.
Tested the original reporters case (running in a debootstrap) with:
```
mmdebstrap \
--variant=minbase \
--include=/tmp/ifupdown2_3.2.0-1+pmx10_all.deb \
--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount \
bookworm \
./bookworm-amd64.tar.zst
```
ran through our install on plain debian guide:
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm
with this package in a local repository to check for regressions
adding the reference to the commit that introduced the reload on
first-install, as this got shifted around a bit and it took me too
long to see that we did not want to error out here on purpose
Fixes: 86335f3f89
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This can lead to issue when upgrading from ifupdown to ifupdown2. The
particular issue this fixes occurs in the following scenario:
* Suppose there is a legacy Debian host with ifupdown and ifenslave
installed that has a bond configured in /etc/network/interfaces.
* ifenslave installs a script /etc/network/if-pre-up.d/ifenslave.
* Now, an upgrade creates a second script
/etc/network/if-pre-up.d/ifenslave.dpkg-new. As ifupdown executes
network scripts via run-parts which ignores scripts with . in their
name, ifenslave.dpkg-new has no effect.
* If the host switches over to ifupdown2 by installing it (removing
ifupdown, keeping ifenslave) and reboots, the network will not come
up:
/etc/network/if-pre-up.d/ifenslave still exists, but is ignored
by ifupdown2's bond addon [1]
/etc/network/if-pre-up.d/ifenslave.dpkg-new is executed by ifupdown2
because it executes all scripts in /etc/network/if-pre-up.d, even if
their name contains a dot
This leads to ifreload failing on upgrades, which in turn causes
issues with the networking of upgraded hosts.
Also submitted upstream at [2]
[1] ccdc386cfa/ifupdown2/addons/bond.py (L45)
[2] https://github.com/CumulusNetworks/ifupdown2/pull/304
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Previously, PVE (7 and 8) hosts would hang at boot if both ntpsec and
ntpsec-ntpdate are installed. The root cause for the hang is an
unfortunate interaction between ntpsec, ntpsec-ntpdate and the PVE
ifupdown2 package. The hang happens because ntpsec-ntpdate installs a
hook /etc/network/if-up.d/ntpsec-ntpdate that blocks until networking
is available if ntpsec is installed. Previously, ifupdown2 would wait
for the hook to terminate, so networking would never become available,
resulting in a deadlock. See the bug report [0] for more information.
With this patch, ifupdown2 runs the hook in the background and does
not wait for it to terminate, thus resolving the deadlock.
This patch was already applied upstream [1]. Backport it to make it
available before the next upstream release.
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5009
[1] https://github.com/CumulusNetworks/ifupdown2/pull/274
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
The original patch removed the first branch of `if` condition, leaving the
`else` in which matched the `if` above.
The correct condition for this `else` is any bond mode that is not `lacp`
(4).
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
since systemd v241, like for bridge, the bond mac is setup randomly at
boot, instead inherit from first slave.
Then, on next ifreload, ifupdown2 was already fixing it, but with an
down/up of the bond (with potentials impact on the network).
This patch have been sent upstream:
https://github.com/CumulusNetworks/ifupdown2/pull/270
This patch is applying fine too for ifupdown2 for proxmox7
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
upstream: https://github.com/CumulusNetworks/ifupdown2/pull/267
if a script in /etc/network/ifup.d/ is segfaulting,
ifup is crashing with
info: executing2 /etc/network/if-up.d/postfix
debug: lo: up : running script /etc/network/if-up.d/resolved info: executing2 /etc/network/if-up.d/resolved
error: name 'traceback' is not defined
debug: saving state ..
info: exit status 1
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to fix nic like mellanox && vlan-aware-bridge
upstream pull request:
https://github.com/CumulusNetworks/ifupdown2/pull/266
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
some users need to disable some buggy features for their nic,
install ethtool by default
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
luckily lintian complained, so fix it for two plugins we add in
patches and library module from upstream.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was request by a proxmox user on ifupdown2 github issues.
https://github.com/CumulusNetworks/ifupdown2/issues/245
It was possible to do it with ifupdown1, but not ifupdown2.
The patch is already applied upstream
https://github.com/CumulusNetworks/ifupdown2/pull/246
example to define a fake ovs bridge with vlan10:
auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
auto vmbr0v10
iface vmbr0v10 inet manual
ovs_type OVSBridge
ovs_bridge vmbr0
ovs_options vmbr0 10
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
