[pve-devel] applied: [PATCH ifupdown2] debian: postinst: ensure /etc/iproute2/rt_tables.d exists

[Thomas Lamprecht]

Am 09.07.25 um 08:40 schrieb Friedrich Weber:
> On 08/07/2025 19:01, Thomas Lamprecht wrote:
>> Am 08.07.25 um 18:43 schrieb Friedrich Weber:
>>> When upgrading to Debian Trixie, iproute2 is also upgraded. Its
>>> postinst deletes /etc/iproute2/rt_tables.d if it is currently empty
>>> (or only contains a README file) [1]. After that, ifreload -a will
>>> always print a warning:
>>>
>>>> error: [Errno 2] No such file or directory: '/etc/iproute2/rt_tables.d/ifupdown2_vrf_map.conf'
>>>
>>> because it cannot create the file if the parent directory does not
>>> exist.
>>>
>>> To avoid that, create the directory in ifupdown2's postinst if it
>>> does not exist yet.
>>>
>>> Commit b115f7f ("add /etc/iproute2/rt_tables.d/ to managed
>>> directories") already added the directory to ifupdown2.dirs, but this
>>> does not seem to be effective, due to the following sequence of events
>>> on upgrade:
>>>
>>> 1) iproute2 is unpacked
>>> 2) ifupdown2 is unpacked. The directory still exists, so the
>>>    ifupdown2.dirs entry does not have an effect
>>> 3) ifroute2 is set up, and its postinst empties and removes the
>>
>> s/if/ip/ (can be fixed up on applying).
> 
> Thanks for catching that. If nothing else comes up, I won't send a v2
> though.

applied it and obviously forgot to fix this up, meh, if I at least wouldn't
have noticed it earlier I could better save face ;-)


> Yeah, I started working on a Python patch first, but as this file is
> opened at several different places [1], I realized testing such a patch
> thoroughly (to hit all call sites) would be more difficult for me, and
> it really is more of an edge case, so the postinst patch also seemed OK
> to me. I can send this postinst patch upstream too to raise the issue,
> then we can see whether they'd rather go with a Python patch.
> 
> [1]
> https://github.com/CumulusNetworks/ifupdown2/blob/master/ifupdown2/addons/vrf.py
Yes, this would be a bigger change, if upstream would be more active I'd
favor it, but this way I do not think it will help us.

Btw., after missing the fixup for the typo today I question also this
approach again, after all configure scripts have no strict ordering on
their own – but Debian policy got us covered here [0], as ifupdown2
declares a dependency on iproute2, so the following policy section
applies:

"The Depends field should also be used if the postinst or prerm scripts
require the depended-on package to be unpacked or configured in order to
run. In the case of postinst configure, the depended-on packages will be
unpacked and configured first"

So your solution here is sound: applied, thanks!

[0]: https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends