Source: https://mayphus.org/local-media-ubuntu-install/
Title: Reconstructing an unattended Ubuntu install from local media
Metadata: {"date":"2026-10-08T00:00:00Z","kind":"article","language":"en","locale":"en","route":"/local-media-ubuntu-install/","slug":"local-media-ubuntu-install","tags":["linux","systems","installation","virtualization"],"type":"article"}

A modified Ubuntu installation image completed an unattended installation in an isolated virtual machine. With the installation image removed, the resulting disk booted and printed verification evidence before powering off. The successful installation took 638 seconds under software emulation.

This was a new reconstruction of a remembered approach. It did not recover the original installation recipe, reproduce the original mini-PC hardware, or measure historical deployment speed.

## Why local media made sense

I remember preparing a batch of mini-PCs with Ubuntu using multiple SD cards. The obstacle, as I now recall it, was that the machines' built-in PXE firmware did not support the USB Ethernet adapter being used. iPXE was considered, but getting it started would require additional setup and SD boot media. If I had to insert local media anyway, modifying the Ubuntu installation image directly seemed more useful than using that media only to start a network installer.

That is a recollection of the decision, not evidence of an unsuccessful iPXE test. It also does not mean that iPXE cannot use USB Ethernet: the [iPXE project's build-target documentation](https://ipxe.org/appnote/buildtargets) explicitly describes USB network drivers and separately describes boot-media formats. Compatibility with the unidentified historical adapter remains unknown.

I now recall using [Cubic](https://launchpad.net/cubic) to customize the historical installation image. That tool identification comes from my recollection; its exact version and the underlying commands have not been recovered. The new reconstruction below uses xorriso directly, which should not be read back into the historical workflow.

The remembered workflow used unattended installation and was not driven by cloud-init. The exact Ubuntu release, deployment date, machine count, installer family, boot options, and answer file are unknown. Local boot media avoided a preboot network fetch; it does not establish that all historical installation and later provisioning happened offline.

## A concrete reconstruction

For the new test I selected Ubuntu 20.04.1's legacy AMD64 server image from [Canonical's release archive](https://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/). The downloaded image matched the official SHA-256 checksum, and the checksum file's detached signature validated against the preinstalled Ubuntu CD Image signing key. This authenticates the test input; it does not identify the historical release.

The reconstruction embedded a preseed answer file for debian-installer and changed the ISOLINUX default entry to start unattended installation. The original kernel and initial ramdisk were retained, xorriso replayed the original boot metadata when rebuilding the image, and the internal file checksums were updated. The measured path used legacy BIOS through SeaBIOS. The UEFI entry was retained but neither adapted for unattended use nor tested.

No cloud-init configuration drove the process. That is a statement about the automation mechanism, not a claim that cloud-init packages were absent from the installed system. [Debian's preconfiguration documentation](https://www.debian.org/releases/stable/amd64/apbs04.en.html) explains the general mechanism; its current instructions were not treated as authoritative for every behavior of this older Ubuntu installer.

The VM used QEMU software emulation, two virtual CPUs, 3 GiB of RAM, a fresh 12 GiB virtual disk, and read-only installation media. It had no network adapter, host directory shares, physical disks, or USB passthrough. Guest networking, online mirrors, time synchronization, and package upgrades were disabled. No new host package was installed for the experiment.

## The prompts that broke unattended installation

The first account configuration disabled both root login and normal-user creation. The installer still asked for a user's full name. Inspection of the account-setup code inside the authenticated image explained why: disabling root login forced normal-user creation.

Another attempt enabled root login but supplied a locked-root password value. This installer treated that value as a reason to request a root password, so it also stopped at a prompt. The final configuration instead supplied a generated test account and kept root login disabled. Account values and credentials are omitted here.

The failed prompts were not answered manually and then counted as unattended success. The successful run began again with a fresh disposable disk and the corrected image.

There was an execution mistake too. Interrupting the first runner did not initially terminate its QEMU child, and a retry briefly overlapped the original VM. That violated the intended one-VM limit. Both experiment-owned processes were stopped and their disks checked. The runner was corrected to terminate its child explicitly on a stop request or timeout. The final installation, installed-disk boot, and USB probe then ran sequentially. Neither overlapping guest had networking or physical-device access.

## What completed successfully

The final installation received no interactive input. Its serial log recorded partitioning, filesystem creation, system installation, package configuration, bootloader installation, and shutdown. The measured duration was 638.102 seconds—about ten minutes and 38 seconds for this one emulated run. It is not a mini-PC benchmark or a claim about batch throughput.

A separate invocation attached only the installed disk, with no ISO or network adapter. Ubuntu 20.04.1 booted with Linux 5.4.0-42-generic. The root filesystem was ext4 and mounted read-write; only the loopback network interface was present. The system printed a reconstruction marker and confirmed that the installer log had been saved, then powered off. That invocation took about 21 seconds, and the virtual-disk integrity check found no image errors.

This was an instrumented boot. During installation, a verification script and systemd service had been placed in the target system. The service printed the evidence and requested poweroff; it did not disable itself, so it would repeat on later boots while enabled. No offline modification of the installed disk was needed between installation and this test.

The result proves installation and this instrumented boot, not a finished production image or sustained service health. The immediate shutdown produced udev worker messages whose cause was not independently isolated. No load test, blockchain node, or production application was deployed.

## A smaller USB boot probe

After the installed guest exited, a separate diskless probe presented the same hybrid image through an emulated USB mass-storage device. It had no installation target or network adapter. The installer kernel reached its initial userspace handoff in approximately three seconds, and the probe was stopped there.

That establishes a virtual USB-storage boot path only. A full installation through this USB attachment was not tested. It says nothing conclusive about a physical SD slot, SD reader, firmware, USB Ethernet adapter, or the previously identified CR160 model. No matching physical machine was tested.

## What I can carry forward

The useful result is narrow: this particular modified legacy image performed an unattended installation with no guest network, followed by a successful instrumented disk boot. It makes the remembered local-media approach plausible without turning the reconstruction into a recovered historical recipe.

Ubuntu 20.04 is a legacy release whose standard security maintenance ended in May 2025; continued coverage depends on the applicable extended-maintenance arrangement. [Canonical's release-cycle documentation](https://ubuntu.com/about/release-cycle) describes those boundaries. The authenticated old image and deliberately skipped upgrades do not make this test installation current or suitable for deployment. This is an experiment log, not a recommendation to deploy that unpatched image.

The repeatable lesson was to inspect the actual installer when assumptions failed, distinguish an installation from a verified boot, and preserve the failures alongside the successful run. The original hardware compatibility, historical configuration, and deployment performance remain unverified.