ifupdown2 fun after upgrade

A

Andreas Pflug

Well-Known Member
Nov 13, 2019
37
2
48
I upgraded a bookworm/pve8 system to trixie/pve9 using dist-upgrade, and cleaned old packages using autoremove.
In addition, I purged all packages with state "rc", to get rid of all old stuff, my standard upgrade practice.

After reboot, there was no network. ifup ens8303 didn't work either: "Another instance of this program is already running". Well, no...
It turns out that ifupdown2 tries to lock "/run/network/.lock", but fails because there's no directory /run/network.

Unfortunately, mkdir /run/network won't survive a reboot, so I changed argv.py to use /run/network.lock as lockfile.

Which still didn't work after the next boot, although a manual "ifup -a" did the job just fine.

This was the moment when installed ifupdown (removing proxmox-ve...), and re-installed ifupdown2 and proxmox-ve. Now, I had the ifupdown package in rc-state, and a reboot works as expected.

It appears to me a little non-standard to have one package depending on left-overs of another uninstalled predecessor package...
 
I think you shouldn't adjust anything there.

Do you still have ifupdown2 installed? If so, what is the output of:
systemctl status networking
journalctl -xeu networking
ip a
ip r
 
Last edited:
daanw said:
I think you shouldn't adjust anything there.
Click to expand...
Yes, you're abolutly right. But I had no network connection at all and wanted at least to get the interface up and running again so that I could make further adjustments.

For the time being, until the next restart, this is what I’ve done:
Bash: 
mkdir /run/network
ifup -a

Previously, the interfaces didn't exist at all
1779632133930.png

The networking.service was active.

At first I wanted to reinstall ifupdown, but that would have completely uninstalled Proxmox VE (due to dependencies).

My next try was a tmpfile in /etc/tmpfiles.d/, but the the folder /run/network was created to late for the networking service.

My next test is a system.d-service
INI: 
cat > /etc/systemd/system/ifupdown2-fix.service << 'EOF'
[Unit]
Description=Create /run/network for ifupdown2
DefaultDependencies=no
Before=networking.service

[Service]
Type=oneshot
ExecStart=/bin/mkdir -p /run/network
RemainAfterExit=yes

[Install]
WantedBy=network.target
EOF

systemctl daemon-reload
systemctl enable ifupdown2-fix.service

At the moment, I have to wait until the server is no longer in use. Only then can I restart it.
 
Last edited:
  • Like
Reactions: ulf.kosack
  • Like
Reactions: daanw
ProxmoxVE doesn't use ifupdown but ifupdown2. That's the reason you have do do it via an reinstall of ifupdown2 instead of ifupdown. I wonder however how such an error is even possible shouldn't the normal update Procedure take care you don't end up with such situation?
 
Last edited:
Johannes S said:
I wonder however how such an error is even possible shouldn't the normal update Procedure take care you don't end up with such situation?
Click to expand...
In the normal situation ifupdown2 is installed and ifupdown is only removed, not purged. It's only when ifupdown is purged these files go missing.

To prevent this you need a mechanism that when a package is purged it should check if its files are also part of another package before removing them.
 
Last edited:
  • Like
Reactions: Johannes S
daanw said:
In the normal situation ifupdown2 is installed and ifupdown is only removed, not purged. It's only when ifupdown is purged these files go missing.

To prevent this you need a mechanism that when a package is purged it should check if its files are also part of another package before removing them.
Click to expand...
I have been burnt by this in the past when purging configuration from uninstalled packages (with ifupdown and grub-pc). I assumed common files were factored out in to some shared dependency but IIRC some configuration came from postinst scripts.
 
You must log in or register to reply here.
Top Bottom
Back