Future me: keep the reason beside the command. A working configuration tells me what I ended up with. It does not tell me why I changed it, or which assumption sent me in the wrong direction.
That is the useful part of the reference notes from the M720q Proxmox build. Not a command collection to memorize. A reminder to check what the evidence actually answers.
Check the constraint before planning the fix
I was trying to work out the memory layout from a blurry photo. The hardware readout showed two 8 GB modules, with both slots occupied. That changed the upgrade plan: reaching 32 GB meant replacing both modules with two 16 GB modules, not adding a stick to an empty slot.
The capacity was not the whole answer. Slot occupancy was the constraint. Keep that distinction in the notes so I do not have to rediscover it when considering an upgrade.
The installation media taught a similar lesson. I missed the privilege prompt and removed the USB before the write completed. It appeared in the boot menu but would not boot. Reflashing and waiting for explicit completion was the fix. Apparent progress was not the check I needed.
Read the signal without adding a story
The Ethernet interface was enabled but had no carrier, even with two cables. The practical decision was to stop depending on that wall connection. Keep the observation separate from a confident explanation of exactly what was wrong behind it.
The router's DHCP client list was another misleading place to look. My statically addressed server was reachable even though it was absent from that list. I was looking for evidence of connectivity in a list of leases. Those are different questions.
For later troubleshooting, remember what each check is checking. An enabled interface is not evidence of carrier. Absence from a DHCP list is not evidence that a server cannot be reached.
Read back what I actually wrote
The repository configuration mess included interrupted multiline pastes and spelling mistakes. Rewriting the broken files and inspecting their contents resolved it. Layering more edits onto damaged configuration was not helping.
The reminder here is not to collect a cleverer editing command. It is to read the file after writing it, before relying on it. The text I intended to paste is not necessarily the text on disk.
The package troubleshooting also needs its reasoning preserved. Package signing and transport encryption are separate protections. A change made while dealing with a certificate-name mismatch should not become a vague remembered rule that transport no longer matters.
When I commit a fix, put the reason in the message. What failed, what I checked, and why I chose the change are worth keeping beside the resulting configuration. That is what makes these notes useful to me later.