setup: dependency install fails on a fresh boot when apt/dpkg is locked by unattended-upgrades

[VijitSingh97]

What happened

Provisioning a fresh Ubuntu 24.04 install (miner-0, the new release test rig), sudo ./rigforge.sh setup aborted immediately at the dependency step:

[INFO] The following system dependencies are required:
   build-essential cmake libuv1-dev libssl-dev libhwloc-dev
[ERROR] rigforge aborted while installing dependencies (exit 1).

Root cause

On a fresh boot, unattended-upgrades / the apt-daily timers hold the dpkg/apt lock for the first minute or two. install_dependencies runs (rigforge.sh:366):

sudo apt-get update -qq && sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq ... 

which fails hard when the lock is held (Could not get lock /var/lib/dpkg/lock-frontend). The -qq hides the real error, so the abort message is opaque. Re-running once the lock freed succeeded immediately — confirming it's a transient lock, not a missing package/mirror issue.

This is a common, very reproducible first-boot condition, and it's exactly the kind of thing the new real-hardware release e2e (#72) is meant to catch.

Proposed fix

• Add -o DPkg::Lock::Timeout=300 to the apt-get calls so they wait for the lock instead of failing (the modern, clean approach), and/or retry with backoff.
• Don't swallow the apt error on failure — surface the last lines (mirrors what bench now does in Release: bench-based pre-release smoke check (actually build + hash before tagging) #61), so an opaque exit 1 becomes diagnosable.

Acceptance

• setup succeeds on a freshly-booted box even while unattended-upgrades holds the lock.
• On a genuine apt failure, the real error is surfaced, not hidden by -qq.

Found provisioning the miner-0 release rig (real-hardware validation of the release-gated e2e direction).