hi!

with trixie approaching fast, it would be nice to get a somewhat current
version of ifupdown2 in Debian. having a git repo on salsa would also be
appreciated in case you want to collaborate!

thanks,
Fabian

Hi Julien,

would it be okay for you if I imported the current version in the
archive to salsa (in a namespace of your choice?) and prepare an upload
with the update to 3.9.0 (and maybe do a bit of housekeeping)? If so,
would you like to review it before I go ahead?

I'm a DD so I can take care of uploading and any follow-up work needed.

Fabian

On 27/03/25 02:14 PM, Fabian Grünbichler wrote:

Hi,

I think this would be a good fit for the Package Salvaging process.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

Bernhard

I am not sure that is necessary (yet) - I mainly did not follow-up on
this because of the incoming freeze.

@Julien my offer above still stands, if you want me to co-maintain or
takeover maintainership on the Debian side just say so :)

Fabian

* Fabian Grünbichler [Fri Aug 01, 2025 at 09:57:07AM +0200]:

Friendly ping, given that I just had a Debian/trixie system where I
wanted to replace ifupdown with ifupdown2 (in preparation for
deploying Proxmox VE), but it even complained about:

| Unpacking ifupdown2 (3.0.0-1.3) ...
| Setting up ifupdown2 (3.0.0-1.3) ...
| Installing new version of config file /etc/default/networking ...
| find: ‘/var/lib/dhcp/’: No such file or directory
| /usr/share/ifupdown2/addons/bridge.py:3641: SyntaxWarning: invalid escape sequence '\s'
|   for protocol in re.split(',|\s*', user_config_l2protocol_tunnel):
| /usr/share/ifupdown2/ifupdown/ifupdownmain.py:1569: SyntaxWarning: invalid escape sequence '\d'
|   vlan_match = re.match("^([\d]+)-([\d]+)", ifacename)
| /usr/share/ifupdown2/ifupdown/utils.py:233: SyntaxWarning: invalid escape sequence '\w'
|   range_match = re.match("^([\w]+)\[([\d]+)-([\d]+)\]([\.\w]+)", name)
| /usr/share/ifupdown2/ifupdown/utils.py:243: SyntaxWarning: invalid escape sequence '\w'
|   range_match = re.match("^([\w\.]+)\[([\d]+)-([\d]+)\]", name)
| /usr/share/ifupdown2/lib/iproute2.py:65: SyntaxWarning: invalid escape sequence '\s'
|   VXLAN_PEER_REGEX_PATTERN = re.compile("\s+dst\s+(\d+.\d+.\d+.\d+)\s+")

And the resulting system didn't manage to come up with networking.

regards
-mika-

these are https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085641

could you share your /etc/network/interfaces[.d/*] contents? feel free
to anonymize/censor (if you do it consistently ;)).

note that if you are using DHCP, you need to install the (deprecated)
isc-dhcp-client if using ifupdown2, since that is the only client
implementation currently supported by it. it's currently only Suggested
by ifupdown2, so this is easily missed and "stock" trixie doesn't come
with it pre-installed (anymore).

I will see about preparing an NMU or starting ITS for updating and
fixing related packaging issues, and then see what we can do to improve
the dhcp client situation upstream as well.

Hi,

Sure, you can go ahead and prepare/handle the upload, i'd appreciate that! I don't have much time at the moment for upstream unfortunately.
I plan to upstream more code to our github repo soon-ish. But we could make a new upload whenever that happens.

Let me know what you need from me.

Julien


these are https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D1085641&data=05%7C02%7Cjfortin%40nvidia.com%7C4fbbf09c69d24e9bea1808de071ae0ac%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638956009192108224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qOFueSWKLUv2RFk4bFODBXD%2FSxssnIdU5ID1C5bLqR0%3D&reserved=0<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085641>

could you share your /etc/network/interfaces[.d/*] contents? feel free
to anonymize/censor (if you do it consistently ;)).

note that if you are using DHCP, you need to install the (deprecated)
isc-dhcp-client if using ifupdown2, since that is the only client
implementation currently supported by it. it's currently only Suggested
by ifupdown2, so this is easily missed and "stock" trixie doesn't come
with it pre-installed (anymore).

I will see about preparing an NMU or starting ITS for updating and
fixing related packaging issues, and then see what we can do to improve
the dhcp client situation upstream as well.

Hi!

* Fabian Grünbichler [Thu Oct 09, 2025 at 12:01:49PM +0200]:

Right, thanks for the pointer. :)

It was generated by Hetzner's installimage and looked like this
(using RFC5737- + RFC3849-style IPs instead of the actual IPs, no
files inside /etc/network/interfaces.d/):

| ### Hetzner Online GmbH installimage
|
| source /etc/network/interfaces.d/*
|
| auto lo
| iface lo inet loopback
| iface lo inet6 loopback
|
| auto enp6s0
| iface enp6s0 inet static
|   address 203.0.113.145
|   netmask 255.255.255.192
|   gateway 203.0.113.129
|   # route 203.0.113.128/26 via 203.0.113.129
|   up route add -net 203.0.113.128 netmask 255.255.255.192 gw 203.0.113.129 dev enp6s0
|
| iface enp6s0 inet6 static
|   address 2001:db8:123:3e3::2
|   netmask 64
|   gateway fe80::1

So no DHCP usage in this situation.

ACK

The system went into production usage already, but now when thinking
about what happened and looking at my docs, I recalled that when one
switches from ifupdown to ifupdown2 and then purges the ifupdown
package, the networking.service goes missing.

Demonstration in a trixie podman container:

| root@9df2c9729f5f:/# apt install systemd
| [...]
|
| root@9df2c9729f5f:/# apt install ifupdown
| Installing:
|   ifupdown
|
| Installing dependencies:
|   adduser  dhcpcd-base  iproute2  krb5-locales  libbpf1  libcap2-bin  libcom-err2  libelf1t64  libgssapi-krb5-2  libk5crypto3  libkeyutils1  libkrb5-3  libkrb5support0  libmnl0  libpam-cap  libtirpc-common  libtirpc3t64  libxtables12
|
| Suggested packages:
|   liblocale-gettext-perl  perl  cron  quota  openresolv  | resolvconf  | systemd-resolved  ppp  rdnssd  python3:any  krb5-doc  krb5-user
|
| Summary:
|   Upgrading: 0, Installing: 19, Removing: 0, Not Upgrading: 2
|   Download size: 2807 kB
|   Space needed: 10.0 MB / 27.2 GB available
|
| Continue? [Y/n]
| Get:1 http://deb.debian.org/debian trixie/main amd64 adduser all 3.152 [191 kB]
| Get:2 http://deb.debian.org/debian trixie/main amd64 dhcpcd-base amd64 1:10.1.0-11 [201 kB]
| Get:3 http://deb.debian.org/debian trixie/main amd64 libelf1t64 amd64 0.192-4 [189 kB]
| [...]
|
| root@9df2c9729f5f:/# apt install ifupdown2
| The following package was automatically installed and is no longer required:
|   dhcpcd-base
| Use 'apt autoremove' to remove it.
|
| Upgrading:
|   libssl3t64  openssl-provider-legacy
|
| Installing:
|   ifupdown2
|
| Installing dependencies:
|   ca-certificates  libffi8  libgpm2  libncursesw6  libpython3-stdlib  libpython3.13-minimal  libpython3.13-stdlib  libreadline8t64  media-types  netbase  openssl  python3  python3-minimal  python3.13  python3.13-minimal  readline-common
|
| Suggested packages:
|   isc-dhcp-client  bridge-utils  ethtool  python3-gvgen  python3-mako  gpm  python3-doc  python3-tk  python3-venv  python3.13-venv  python3.13-doc  binutils  binfmt-support  readline-doc
|
| REMOVING:
|   ifupdown
|
| Summary:
|   Upgrading: 2, Installing: 17, Removing: 1, Not Upgrading: 0
|   Download size: 10.9 MB
|   Space needed: 28.3 MB / 27.2 GB available
|
| Continue? [Y/n]
| Get:1 http://deb.debian.org/debian-security trixie-security/main amd64 openssl-provider-legacy amd64 3.5.1-1+deb13u1 [307 kB]
| Get:2 http://deb.debian.org/debian-security trixie-security/main amd64 libssl3t64 amd64 3.5.1-1+deb13u1 [2437 kB]
| [...]
|
| root@9df2c9729f5f:/# ls -la /etc/systemd/system/network-online.target.wants/networking.service /etc/systemd/system/multi-user.target.wants/networking.service
| lrwxrwxrwx 1 root root 42 Oct  9 17:24 /etc/systemd/system/multi-user.target.wants/networking.service -> /usr/lib/systemd/system/networking.service
| lrwxrwxrwx 1 root root 42 Oct  9 17:24 /etc/systemd/system/network-online.target.wants/networking.service -> /usr/lib/systemd/system/networking.service
|
| root@9df2c9729f5f:/# apt purge ifupdown
| The following package was automatically installed and is no longer required:
|   dhcpcd-base
| Use 'apt autoremove' to remove it.
|
| REMOVING:
|   ifupdown*
|
| Summary:
|   Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
|   Space needed: 0 B / 27.1 GB available
|
| Continue? [Y/n]
| (Reading database ... 8063 files and directories currently installed.)
| Purging configuration files for ifupdown (0.8.44) ...
|
| root@9df2c9729f5f:/# ls -la /etc/systemd/system/network-online.target.wants/networking.service /etc/systemd/system/multi-user.target.wants/networking.service
| ls: cannot access '/etc/systemd/system/network-online.target.wants/networking.service': No such file or directory
| ls: cannot access '/etc/systemd/system/multi-user.target.wants/networking.service': No such file or directory
| root@9df2c9729f5f:/#

And looking at my own customer documentation, I also found the
reference for this problem in the Proxmox BTS:
https://bugzilla.proxmox.com/show_bug.cgi?id=2950 :)

Great, thanks. :)

regards
-mika-

ha :)

so yeah, I think this would require coordination between

- ifupdown
- ifupdown2
- ifupdown-ng (which doesn't currently manage networking.service, so is
  only affected when being switched to, but doesn't cause the problem
  itself);

in order to avoid the disable call to systemctl in case of purge, if
another implementation providing networking.service is still around..

AFAICT, this would require quite ugly handling (effectively overriding
the systemd dh call, copying the maintainer script code it would have
generated, but adding another guard for networking.service being
around?).

in any case, switching to ifupdown2 can only be fixed in ifupdown (and
vice-versa).

Hi,

* Fabian Grünbichler [Mon Oct 13, 2025 at 11:00:52AM +0200]:

:)

ACK. FTR, I also verified it on the production system, with
ifupdown2 being present (v3.3.0-1+pmx10) and ifupdown removed, but
not yet purged. The workaround was:

  sudo dpkg --purge ifupdown
  sudo systemctl enable networking

Then it continues to work as expected.

ACK. What *might* help as a workaround could be a check within
ifupdown2's maintainer scripts for a *removed* but not yet *purged*
ifupdown package. Then it could provide a warning and instructions
how to fix this. This might help users who are not aware of this
issue, at least until it's properly handled between
ifupdown/ifupdown2 without requiring manual intervention?

regards
-mika-

https://salsa.debian.org/debian/ifupdown-ng/-/commit/fad9af1f6ec26f592ac056d5497f269c7f6d28bc

is what Daniel (the ifupdown-ng maintainer) came up with yesterday after
a short chat.

it's a bit of a hack, and relies on the fact that the Debian systemctl
wrappers don't actually call `systemctl disable foo` (which would again
disable the real service as well, and not just networking.service), but
clean up the links manually without accounting for aliasing, but it
seems to work as a stop-gap measure.

it also of course still leaves `networking.service` (now an alias)
disabled, which might mean breaking custom integration relying on that
name being used, so it's only a partial solution in any case.

we'd either need to adapt the integration/wrappers to handle multiple
owners of a unit name correctly, or override them to get a complete
fix...

Hi!

I've prepared a "modern style" git-buildpackage based repository on
salsa:

https://salsa.debian.org/fg/ifupdown2

I tried to pick improvements from upstream's packaging, and sync my
changes back where I think they make sense for upstream as well.

If this looks okay to you, I'd create the "real" repository under the
debian/ namespace on salsa, push there and upload the package.

If you want things done differently, please tell - I am of course open
for suggestions ;)

Fabian

Hi !

Is there any update regarding the new ifupdown2 upstream packaging?

I’m using version 3.3.0-1+pmx12 from the Proxmox 9 repository with
complex network setup (vrf, vrrp integration with frr , xfrm interfaces
) , and it works perfectly.

Thank you.Best regards,
csszep

Hi,

I've found

https://salsa.debian.org/fg/ifupdown2

with recent commits.  While I understand Julian's mail in this bug
report[1] as "please go ahead".  I consider it a very good point in time
for the Forky release cycle to upload now and leave enough time for
testing before the Freeze.

Kind regards
    Andreas.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100102#35

Hi!

I do not think there is any need to involve the "Salvaging Team" here,
since I already offered helping with or taking over maintenance.

While Julien gave his OK to updating to 3.9.0, he did not reply to my
last offer of modernizing and moving the packaging (which is currently
in the upstream GH repository) to salsa. Out of courtesy, I wanted to
wait for an ack for this rather big step as well (though I do have to
admit - I dropped the ball on following up after there was no reaction -
time does fly sometimes after all ;)).

@Julien - does the above sound okay? then I will do another pass of
updating that repository, push it to a non-personal part of salsa and do
the upload.

Fabian

Hi,

I am still maintaining ifupdown2. I plan to release a new version on github by August 15th, then I will do the necessary to get it uploaded to Forky.

Julien


Hi!

I do not think there is any need to involve the "Salvaging Team" here,
since I already offered helping with or taking over maintenance.

While Julien gave his OK to updating to 3.9.0, he did not reply to my
last offer of modernizing and moving the packaging (which is currently
in the upstream GH repository) to salsa. Out of courtesy, I wanted to
wait for an ack for this rather big step as well (though I do have to
admit - I dropped the ball on following up after there was no reaction -
time does fly sometimes after all ;)).

@Julien - does the above sound okay? then I will do another pass of
updating that repository, push it to a non-personal part of salsa and do
the upload.

Fabian

Hi Julien,

Am Tue, Jun 09, 2026 at 12:20:37PM +0000 schrieb Julien Fortin:

Thank you for your work on ifupdown2.  I would consider it a good idea
if the Debian maintenance would be done in Git on Salsa.  Currently we
have

https://salsa.debian.org/fg/ifupdown2

It might make sense to move this repository to the Debian team for
easier collaboration.  In any case it helps to declare Vcs fields
to the packaging repository to enable contributions via MRs.

Thanks a lot for considering
    Andreas.

Hi,

Looks like the Salsa repo is ahead of what we have on github.
I will double check what the differences are closer to Aug 15th.

I tried creating an account on Salsa but it needs to be approved by an admin.

Julien


Thank you for your work on ifupdown2.  I would consider it a good idea
if the Debian maintenance would be done in Git on Salsa.  Currently we
have

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Ffg%2Fifupdown2&data=05%7C02%7Cjfortin%40nvidia.com%7C357c54e3eb784ccf840008dec623d28b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C639166054345728680%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hF1XzISKKtLnOcMUgCaoVrNY1cAxBl3i872GmfjgnHQ%3D&reserved=0<https://salsa.debian.org/fg/ifupdown2>

It might make sense to move this repository to the Debian team for
easier collaboration.  In any case it helps to declare Vcs fields
to the packaging repository to enable contributions via MRs.

Thanks a lot for considering
    Andreas.

Hi,

Am Tue, Jun 09, 2026 at 12:58:13PM +0000 schrieb Julien Fortin:

Well, the problem is that the upstream code should not be merged with
the Debian packaging[1].  This is why packaging on Salsa should be
prefered.

As long as you simply work on the ifupdown2 upstream code there should
be no conflict at all.

Cool.  I guess Fabian will grant you push permissions to cooperate
on the packaging.

Kind regards
    Andreas.

[1] https://wiki.debian.org/UpstreamGuide#Do_not_include_a_.2Fdebian_directory