Display + network drop simultaneously at boot on Dell OptiPlex 3070 suspected power issue?

sebbie

New Member
Sep 11, 2026
1
0
1
My Proxmox host was running fine for 18+ days uptime, then became unresponsive while I was actively using it via SSH.

Journal logs confirm this was a clean Power key pressed short → Powering off event — I manually power-cycled it after the connection dropped, assuming a crash. Since then, it will not boot normally without both the display and the Ethernet link dying at the exact same moment.

Symptoms:
  • Boots normally through GRUB, kernel load, filesystem check (all clean, no errors)
  • Reaches pve login: prompt
  • At that exact point: display signal drops entirely (monitor shows "No Signal") AND the Ethernet port's link light changes/drops, network becomes unreachable
  • This happens consistently across:
    • Normal boot
    • Boot from a separate Rescue USB (different OS entirely, same symptom)
    • nomodeset boot flag (no change)
  • Booting with init=/bin/bash (skipping systemd, so no VM/container autostart, minimal services) — system stays completely stable, display and network both work fine, SSH accessible

What I've ruled out:
  • Filesystem/disk: clean fsck every boot, journalctl shows no panics/errors/OOM kills before the original shutdown
  • Software/config: same failure occurs from a totally separate rescue OS on USB, not just the installed Proxmox
  • Cable/port: confirmed ethtool shows "Link detected: yes" and correct negotiation when interface is manually brought up in the minimal shell
My working theory:
Since it's stable under a minimal boot (low, steady load) but fails at the exact moment VMs/containers auto-start, network comes fully online, and display finishes its handoff (all together = a power draw spike), I suspect the 65W power adapter (or possibly onboard power regulation) can't sustain output under that specific load transition. Tested adapter unloaded with a multimeter: reads 19.5V correctly at rest, but I don't have a safe way to test it under load with a standard barrel connector.

Any help or advice would be appreciated.
 
The clean "Power key pressed short" line in the journal is the part I would trust the most here. An 18+ day uptime box does not usually press its own power button, so either something actually did, or the button registered a phantom press. Worth checking the button physically (does it feel sticky or click too easily?) and looking at the BIOS event log (F12 at boot) to see if it recorded the same event.

On the failure itself, your init=/bin/bash result is the most useful clue, but I would push it one step further before blaming the adapter. init=/bin/bash skips systemd entirely, so it cannot tell you whether VM autostart is the trigger or whether it is simply "any real userspace load". Boot the installed system with systemd.unit=multi-user.target appended on the kernel command line (edit the grub entry at boot). That gives you full userspace with no VM autostart. If it survives that, the load-spike theory gets stronger and you can start the pve services one by one (pvestatd, pvedaemon, pveproxy, then the VMs) to find the exact trigger. If it dies even there, the power transition theory weakens and I would look at RAM or the board instead.

Two cheap power-related tests: swap in a 90W Dell adapter if you can borrow one (the 3070 micro accepts it), and put a wall power meter between the adapter and the outlet so "I suspect the adapter" becomes an actual number.

Also enable persistent journald (Storage=persistent in /etc/systemd/journald.conf) so the next crash leaves a readable last page of logs after you power-cycle, and run the Dell ePSA diagnostics from F12. Memory errors that only appear under real load are exactly the kind of thing ePSA catches.