Everything moves off the old NAS: the migration and its USB boot saga
- date
- 20260903 to 20260906
- what happened
- The new central Unraid server unraid1 was meant to boot from a small USB flash drive, the standard installation method. The drive worked in the machine's USB 2.0 ports and was silently dropped by the kernel in a USB 3.0 port (error -71, unmountable), a failure the firmware boot menu never revealed because it reads the drive fine before the kernel loads. A day later the box went fully unreachable after a licence-key reboot, with the same signature on a port that had worked before.
- what it cost
- Roughly a day and a half of delay on a planned server migration, plus a full evening of hands-on diagnosis over a remote console, because the box's own network port went dark.
- what changed
- Unraid was moved to internal boot entirely, onto a mirrored ZFS pool across two internal SSDs, with the USB stick kept only as a temporary licence anchor until the licence transferred to the machine's TPM. Migration of about 31 datasets, 38 containers and the box's core services then proceeded over the following two days.
- the check now
- Any appliance-OS bring-up on unfamiliar hardware gets its boot media tested across every physical USB port and generation before a migration date is committed, because a drive that boots fine in firmware can still be silently dropped the instant the kernel loads, rather than assuming that booting once means it is stable.
A brand-new server, meant to become the central hub for an entire home infrastructure, could not reliably boot its own operating system, and the reason was almost invisible. The small USB flash drive holding the OS worked perfectly in the machine’s firmware boot menu and then vanished the instant the Linux kernel took over. That happened only on the faster USB 3.0 ports, and only some of the time.
Diagnosing this meant watching console output directly, since the machine’s own network access was down and remote log-reading was not an option. It also meant hand-navigating a UEFI shell to boot while working out what was happening. The eventual answer was not a firmware setting or a bad cable. It was a known-class incompatibility between that drive and that USB controller generation under Linux specifically, a combination that had no reason to be tested before the hardware was already committed to a migration deadline.
The permanent fix sidestepped the whole category. It stopped relying on USB boot media at all and used the server’s real internal storage, keeping the original USB drive only as a temporary anchor for a software licence until that licence could move to a hardware security chip. The transferable lesson is narrow but sharp. “It booted in the BIOS” and “it boots reliably under the target operating system” are different claims, and a migration timeline should not assume the second from the first.
Source: node0 lessons v0.1, lesson 3.13. Sanitized: checklist v0.1, 20260921; service names generalised; voice pass 20260921. Part of oznog.com/node0.