### Creating a bug report/issue
[x] I have searched the existing open and closed issues
### Required Information
DietPi version | v8.1.2 (from official DietPi_VMware-x86_64-Bullseye.7z image)
Distro version | bullseye
Kernel version | Linux dietpi 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux
Architecture | amd64
SBC model | Virtual Machine (VMware ESXi 6.7.0)
Power supply used | N/A (VM on Apple Mac hardware host)
SD card used | N/A (ESXi VMFS thin-provisioned datastore)
### Additional Information (if applicable)
Software title | Base system / Networking (dhclient / ifupdown)
Was the software title installed freshly or updated/migrated? | Freshly installed from official VMware Bullseye image
Can this issue be replicated on a fresh installation of DietPi? | Yes, 100% reproducible on fresh install
Bug report ID | N/A (cannot upload bugreport because network is completely down)
### Steps to reproduce
1. Download `DietPi_VMware-x86_64-Bullseye.7z` from the official archive.
2. Extract and convert the virtual disk to ESXi VMFS thin-provisioned format using `vmkfstools -i`.
3. Attach the converted disk to a VM in VMware ESXi 6.7 (running on Mac hardware where the vSwitch uplink is a USB Ethernet adapter - `vusb0`).
4. Boot the VM (with Promiscuous Mode, Forged Transmits, and MAC Address Changes all set to Accept on both the vSwitch and portgroup).
### Expected behaviour
The VM should establish a link state, successfully negotiate a DHCP lease over the vSwitch, and boot to the login prompt. (Note: A DietPi Bookworm VM running on this exact same ESXi host and vSwitch works perfectly and gets an IP immediately).
### Actual behaviour
The VM boots up but hangs indefinitely during the pre-login boot phase at:
`[*** ] A start job is running for ifup for eth0 (36s / 5min 1s)`
Logging into the console shows `dhclient` broadcasting `DHCPDISCOVER on eth0 to 255.255.255.255 port 67` over and over, but receiving `0 DHCPOFFER` replies. Switching the virtual adapter type in ESXi between `vmxnet3`, `e1000`, and `e1000e` makes no difference.
### Extra details
- I specifically need Debian 11 Bullseye (kernel 5.10) for this VM due to legacy compatibility requirements for a Netatalk 4 setup, so upgrading to Bookworm isn’t an option for me.
- I also tried setting a static IP in `/etc/network/interfaces`. When I do that, the VM’s MAC address successfully registers in the ESXi host ARP table (`esxcli network ip neighbor list`), but pinging the gateway or external sites results in 100% packet loss.
- Since Bookworm (kernel 6.1) works flawlessly over this exact same USB uplink (`vusb0`) and vSwitch, but Bullseye (kernel 5.10) drops all incoming traffic regardless of virtual NIC hardware emulation, I’m wondering if there is a known issue or driver quirk with kernel 5.10 and ESXi USB uplinks?