This PR should be scoped to the e2e test workflows. The grub-installer/bootdev
override added in f0718d0 is a change to the shipped Debian installer, and it is
very likely a no-op for the test it was added for: the e2e harness is UEFI-only,
where GRUB installs to the ESP and bootdev is the BIOS/i386-pc question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The preseed sets grub-installer/bootdev to "default", which also marks the
question as seen. grub-installer then takes this path:

    db_fget grub-installer/bootdev seen
    if [ "$RET" = true ] && db_get grub-installer/bootdev && [ "$RET" ]; then
            if [ "$RET" = "default" ]; then
                    bootdev=$default_bootdev

$default_bootdev is the first grub-mkdevicemap entry -- (hd0), the installer
USB itself. The safeguard against installing onto the installation media only
runs in the *:grub-pc branch, so nothing protects a UEFI install.

The EFI install still succeeds, because grub-install writes to the ESP on the
real disk, but the step then exits 1 reading the ISO9660 partition table:

    grub-installer: info: Installing grub on '/dev/sda'
    grub-installer: info: grub-install ran successfully
    main-menu: (process:10646): Can't read partition table from /dev/sda
    main-menu: WARNING **: Configuring 'grub-installer' failed with error code 1

Reuse the non-USB disk list already computed for partman. Verified by a local
QEMU UEFI USB install of the Debian 13.5.0 unattended ISO, which now completes
the installer in ~4 minutes instead of stalling on the failure dialog.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

A failed run only tailed the serial logs, which hold three lines of EFI stub
output because d-i draws its UI on VT1 and streams its syslog to VT4, and the
first-boot test runs on a virtual terminal via openvt. Both real failures found
so far were invisible in the artifacts.

Screendump every console instead, and dump the guest's install logs, docker
state and connectivity over SSH, which is always up by the time a first-boot
wait times out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The connectivity check was ping-only, so any network that filters ICMP failed
it. error_exit then blocks on `read` forever, .firstboot is never removed, and
the machine sits on "Check installation source. Press enter to continue".

That is not just CI: corporate, hotel and cloud networks filter ICMP too, and a
real DAppNode behind one dies the same way on its first boot. GitHub runners hit
it because Azure drops ICMP egress -- the ping_group_range sysctl in the e2e
workflows lets QEMU open the socket but cannot make the echo come back.

Fall back to an HTTPS probe, then to a bare TCP connect for the case where
neither curl nor wget is installed yet.

Verified on a local QEMU UEFI USB install of the Ubuntu 24.04.3 unattended ISO
with `iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP` applied in
the guest before the test ran: ping fails, the check passes, and the run
completes instead of stalling for the full 30 minute timeout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>