Race condition in network setup

After `mxgrub --reboot` (kexec) fluffybutt’s `net04` was not yet available.

https://github.molgen.mpg.de/mariux64/mxtools/blob/a8fb0141c51686e5f7d1702f47a198b8b6a2c450/etc/systemd/system/network.service#L7-L12

Claude Opus 4.8’s analysis makes sense to me, but need to check next week:

```
● Root cause confirmed. This is a startup race, and kexec just exposes it.

  What's happening

  net04 is your ixgbe NIC at PCI 0000:51:00.0. ixgbe is a loadable module (not built-in), coldplug-loaded by udev asynchronously. Meanwhile network.service only orders itself After=sysinit.target — it has no 
  dependency on the network device existing:

  ExecStart=/sbin/ip addr add ${MX_IPADDR}/20 ... dev ${MX_NETDEV}   # MX_NETDEV=net04

  So it fires ip … dev net04 blindly. In this boot the ixgbe probe completed a full second after network.service had already run and failed.

  Why kexec breaks it but a cold reboot doesn't

  It's a timing race that a cold boot happens to win and kexec loses:

  - Cold reboot: BIOS POST + PCI option-ROM init take many seconds before userspace even starts, so by the time systemd reaches network.service the ixgbe hardware is long since probed and net04 exists.
  - kexec: skips all firmware/POST, so systemd reaches network.service within ~2 s of the kernel starting — but the ixgbe SFP+/PHY probe still needs the same ~1 s of wall-clock time. Userspace simply outruns the
  driver.

  Your PCI-enumeration parallelisation / boot-time work makes userspace even faster, which widens the gap and makes this more likely, not less.

  Fix — make network.service wait for the device

  The unit is missing an ordering dependency. Two clean options (I can't apply either — no admin on fluffybutt — but here are the drop-ins):

  Option A — poll for the device (host-agnostic, my recommendation). Works regardless of what MX_NETDEV resolves to per host:
  # /etc/systemd/system/network.service.d/wait-netdev.conf
  [Service]
  ExecStartPre=/bin/sh -c 'for i in $(seq 1 100); do ip link show "$MX_NETDEV" >/dev/null 2>&1 && exit 0; sleep 0.1; done; echo "timeout waiting for $MX_NETDEV" >&2; exit 1'

  Option B — order after the systemd .device unit. More "correct" systemd, but net04 is per-host so it needs a generated drop-in:
  [Unit]
  Wants=sys-subsystem-net-devices-net04.device
  After=sys-subsystem-net-devices-net04.device

  I'd steer toward A since it lives in one drop-in that works fleet-wide and reads MX_NETDEV from the existing EnvironmentFile. The underlying smell is that this custom mxnetctl/network.service assumes its NIC is
  present at sysinit.target — worth raising with whoever owns the MPIMG network unit, since any fast-booting host (kexec, or future boot-time cuts) will trip it.

  Want me to double-check the cold-reboot ordering to nail the "cold boot wins" claim? If you can point me at a journalctl -b from a normal reboot (readable path), I'll compare the
  kernel-start→network.service→ixgbe-probe deltas directly.
```