# [DIAGNOSED + WORKAROUND] 7.3.0: emhttpd ENOFLASH4 — flash rejected, GUID = (null) on legacy whole-device FAT (superfloppy) USBs

**TL;DR** — If you upgraded 7.2.6 → 7.3.0 and your boot USB is suddenly rejected (`emhttpd: import flash device: (sda) ... Error: (/dev/sda) not known`, license shows `(null)`, GUI returns HTTP 500, array won't start), the cause is almost certainly that your USB has the legacy "superfloppy" layout — a FAT filesystem written directly to `/dev/sda` with no partition table — which 7.2.x and earlier accepted but **7.3.0 rejects**. The fix is to re-flash the same USB with a proper MBR + single FAT32 partition layout using the current Unraid USB Creator, then restore your `/config` from backup. **Same USB, same license, same GUID — it just needs the partition table.** Full procedure below.

If this saves anyone the panic I had, mission accomplished.

---

## Symptoms (what 7.3.0 looks like when it rejects your flash)

After the standard in-GUI Update OS to 7.3.0 stable and reboot:

- Kernel boots, USB enumerates fine (`lsusb`, `dmesg` happy, `sda` present)

- `emhttpd` starts, fails to classify the flash device:

  ```

  emhttpd: import flash device: (sda)

  emhttpd: Error: shcmd ... mount /boot ... not known

  emhttpd: shcmd ... ENOFLASH4

  ```

- `/var/local/emhttp/var.ini` is created but every classifier-derived value is `(null)`:

  ```

  flashGUID="(null)"

  flashVendor="(null)"

  flashProduct="(null)"

  regGUID="(null)"

  regTy="(null)"

  ```

- WebUI loads the static login page (HTTP 302), but every authenticated request returns **HTTP 500** because `emhttpd` never created `/var/run/php-fpm.sock`

- Array never starts, no pools imported, Docker daemon never started, no containers

- SSH still works (root login is independent of `emhttpd`), which is your lifeline

The `Plus.key`, `super.dat`, and the rest of `/boot/config/` are **not corrupted** — only the boot images (`bzimage`, `bzroot`, `bzfirmware`, `bzmodules`, `memtest`) were swapped by the upgrade.

## Root cause

7.3.0's flash classifier is stricter and **requires a proper MBR with a single primary FAT partition**. It rejects the legacy whole-device FAT (a.k.a. "superfloppy") layout that older Unraid releases were happy with.

You can see the difference yourself. Old, rejected layout (this is what triggers the failure):

```

$ blkid /dev/sda

/dev/sda: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="XXXX-XXXX" BLOCK_SIZE="512" TYPE="vfat"

# ↑ filesystem is on the raw disk, no PTUUID/PTTYPE, no /dev/sda1

$ fdisk -l /dev/sda

Disk /dev/sda: 29.11 GiB, 31260704768 bytes, 61056064 sectors

Disklabel type: dos

# the partition entries fdisk shows are garbage — random bytes in the MBR area

# being mis-interpreted; sector counts overflow the physical disk size

```

New, accepted layout (what every modern Unraid USB Creator produces):

```

$ blkid /dev/sda /dev/sda1

/dev/sda: PTUUID="xxxxxxxx" PTTYPE="dos"

/dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="XXXX-XXXX" TYPE="vfat" PARTUUID="..."

# ↑ proper partition table on /dev/sda, FAT filesystem on /dev/sda1

$ fdisk -l /dev/sda

Device     Boot Start      End  Sectors  Size Id Type

/dev/sda1  *     2048 61054975 61052928 29.1G  c W95 FAT32 (LBA)

```

Many older USBs prepared with the original `make_bootable` (especially SanDisk Cruzer Force and similar long-serving sticks) shipped/were-flashed in superfloppy mode. They booted fine for years on Unraid 6 and 7.0–7.2 because the classifier accepted both layouts. 7.3.0 no longer does.

## Proof it's purely the partition layout (not the kernel, not the license, not the USB hardware)

Same physical SanDisk Cruzer Force, same `/boot/config/` (restored byte-for-byte from backup), same `Plus.key` (md5 unchanged), same machine, same kernel cmdline. The **only** thing that changed between "7.3.0 rejects" and "7.3.0 accepts" was the partition layout (superfloppy → MBR + sda1). After re-flashing the layout, 7.3.0 booted, `emhttpd` immediately classified the USB, computed the correct flashGUID, license validated as Plus, array started, all 6 ZFS pools imported, all 23 containers came up.

Important: the `flashGUID` is derived from the USB controller's vendor/product/serial descriptors, which are unchanged by reformatting. **Your existing license stays bound to the same USB.** No Replace Key, no re-registration, no involvement from sales/support.

## The fix (procedure I followed — 30 minutes downtime, no key transfer required)

> ⚠️ Read the whole thing before starting. **Take a full byte-level backup of the USB first** — if anything goes wrong, you can `dd` it back and you're exactly where you started.

### What you need

- A working Linux machine to take a backup over SSH (or just plug the USB in directly)

- A Windows or macOS machine to run the official Unraid USB Creator

- Your most recent `/boot/config/` backup (the in-GUI **Tools → Backup/Flash** zip works, or a tarball you take manually). If you don't have one, take it now from 7.2.6 before doing anything else.

### Step 1 — Roll back to 7.2.6 (so you can use the GUI to take a clean backup)

If you're stuck at the failing 7.3.0 boot but `/boot/previous/` exists (Unraid keeps the prior version's boot files there during an upgrade), copy these from `/boot/previous/` over `/boot/` via SSH and reboot:

```

bzimage    bzimage.sha256

bzroot     bzroot.sha256

bzroot-gui bzroot-gui.sha256

bzfirmware bzfirmware.sha256

bzmodules  bzmodules.sha256

memtest    memtest.sha256

```

Don't touch `/boot/config/`, `/boot/syslinux/syslinux.cfg`, `Plus.key`, `super.dat`, or anything else. Reboot — you should be back on 7.2.6 with everything working.

### Step 2 — Take backups from working 7.2.6

From the GUI: **Tools → Backup/Flash → Backup**. Save the resulting zip somewhere off the USB.

If you want a belt-and-braces byte-level backup of the USB itself (recommended), pull it from another machine over SSH:

```bash

# from a Linux box, USB in the Tower as /dev/sda — DO NOT run this on the Tower itself

ssh root@tower 'dd if=/dev/sda bs=4M status=progress 2>/tmp/dd.log | gzip -1 -c' \

  > sandisk-backup.img.gz

```

(The `2>/tmp/dd.log` matters — if you let `dd`'s stderr into the pipe, gzip will ingest the progress messages as data and your backup will be silently corrupted. Don't ask me how I know.)

### Step 3 — Pull the USB and reformat it with the official Creator

1. Stop the array, shut down the Tower cleanly (Main → Stop, then Tools → Shutdown)

2. Pull the USB and put it into your Windows/macOS machine

3. Download the **Unraid USB Creator** from `unraid.net/download` (current release — make sure it's the new one, not the old `Unraid.USB.Creator` / `make_bootable.bat` from 2017)

4. Choose: **OS Version: 7.3.0**, **Server Name:** (your existing name), **Network Mode:** DHCP (or whatever you had), keep "format the USB device" enabled, write

5. After it finishes, on Windows it'll prompt you to run `make_bootable.bat` — **do that** (it installs the syslinux MBR for legacy BIOS boot)

6. The drive letter will change (Windows treats the new partition layout as a new volume). That's expected and harmless.

### Step 4 — Restore your `/config` and customizations

The Creator wrote a fresh, default `/config/` directory (with a generic `network.cfg`, `go`, `ident.cfg`, etc). You need to overwrite it with your real config from the backup.

From your `/boot/config/` backup:

- **Delete** the auto-generated `\config\` on the new USB

- **Copy** your backup's `config/` directory onto the USB so it lives at `\config\` (with all subfolders: `plugins/`, `pools/`, `shares/`, `ssh/`, `modprobe.d/`, etc — and the files `Plus.key`, `super.dat`, `network.cfg`, `ident.cfg`, `go`, `disk.cfg`, etc)

- If you had anything in `/boot/extra/` (extra packages installed at boot — e.g. Pulseway), restore that to `\extra\` too

If you had a customized `syslinux.cfg` (custom kernel args, default GUI mode, etc):

- Take the **new 7.3.0 `syslinux/syslinux.cfg`** the Creator wrote as your base (in case Limetech changed something)

- Add your custom kernel args back to the `Unraid OS` and `Unraid OS GUI Mode` `append` lines (e.g. `pcie_aspm=off pcie_port_pm=off`)

- If you had `menu default` on a non-default label, re-add it

- Make the same edits to **both** `\syslinux\syslinux.cfg` (BIOS) and `\EFI\boot\syslinux.cfg` (UEFI)

- Do **not** copy your old `syslinux/*.c32` binaries over the new ones — keep the new 7.3.0 ones

Verify before unplugging:

- `\config\Plus.key` exists and md5 matches your backup

- `\config\super.dat` exists

- `\config\go` is your customized one (not the 1-line default)

- `\config\plugins\` is populated with your plugins

- `\config\pools\` (if you had one) is populated

Safely eject the USB.

### Step 5 — Boot

Put the USB back in the Tower, power on. Within ~3 minutes you should see:

- Console gets to a login prompt

- WebUI is up at `https://<tower-ip>` (HTTP 302 to the login page)

- License shows correctly (Tools → Registration)

- Array starts (it'll likely run a parity check because the previous shutdown wasn't graceful — this is normal, let it complete)

- Containers come back

Verify via SSH (handy one-liner):

```

cat /etc/unraid-version

grep -E '^(flashGUID|flashVendor|flashProduct|regGUID|regTy|mdState|fsState)=' \

  /var/local/emhttp/var.ini

fdisk -l /dev/sda | head -15

```

You should see `version="7.3.0"`, a non-`(null)` `flashGUID`, `regTy="Plus"` (or Pro/Trial), and `Disklabel type: dos` with a single `/dev/sda1` of type `W95 FAT32 (LBA)`.

## What I checked / ruled out before landing on the partition-layout theory

- **Not the kernel cmdline** — `syslinux.cfg` was unchanged

- **Not internal-boot vs flash-boot** — never opted into Internal Boot or TPM

- **Not the license file** — `Plus.key` md5 unchanged before/after, works fine on 7.2.6 post-rollback and post-fix

- **Not the `go` script** — `go` runs after `emhttpd`, so it can't cause `ENOFLASH4`

- **Not a reverse-proxy issue** — the 500s come from `php-fpm.sock` not existing, which is downstream of `emhttpd` failing

- **Not a hardware fault** — USB enumerates fine, reads/writes normally, healthy SMART

- **Not a USB descriptor / VID:PID issue** — same descriptors before and after, same flashGUID computed both before the upgrade (on 7.2.6) and after the fix (on 7.3.0)

## Asks for Limetech (if anyone from staff reads this)

The fact that the upgrade silently bricks the boot of users with the older USB layout is rough. Two suggestions, either would be a meaningful improvement:

1. **Pre-flight check in the in-GUI Update OS flow:** detect superfloppy layout before applying the upgrade, warn the user, and link to a "how to migrate to MBR layout" doc. The upgrade should not proceed without acknowledgement.

2. **Loosen the 7.3.x classifier** to accept the legacy whole-device FAT layout the way 7.2.x did, even if only as a deprecated fallback for one more minor release cycle.

If neither is feasible, at minimum a release-note entry and a pinned thread documenting the symptom + workaround would save people a lot of time.

## Diagnostics available

I have the original failing 7.3.0 boot files preserved, full syslogs from both the failing 7.3.0 boot and the working post-fix 7.3.0 boot, and a byte-level backup of the USB in its original superfloppy layout. Happy to share any of it with staff for analysis.

## System (for reference)

- **Hardware:** Dell OptiPlex 7050 MFF, Intel i7-7700, 32 GB DDR4

- **Storage controllers:** onboard Intel + ASM1164 PCIe HBA

- **Boot USB:** SanDisk Cruzer Force 32 GB, in service ~8 years

- **License:** Plus / Lifetime (registered 2017)

- **Working version before:** 7.2.6 (kernel 6.12.x)

- **Failing version:** 7.3.0 stable (kernel 6.18.x) — *until* USB was re-partitioned, after which it works perfectly

Hope this helps somebody. 🍻

Thanks for the post, 7.3 is more strict about the flash drive layout. You can also just back up the current flash drive, recreate it using the USB tool, restore only the config folder from the backup and you are all set.

Thanks Jorge, yes correct

Thank you for your post, as I was in the same or at least similar boat as my Server has been running for a couple of years and had a single FAT32 Partition.

With your guide it was easy to fix and upgrade successfully.

This really should be checked by the Update Process itself. My server was stuck in a bootloop without any error messages on screen, making diagnosis for most users really challenging if they don't know where to look.

I also have a full Backup of the "broken" state of the Stick if any staff member wants to see it in detail.

Thank you Jorge. I had the same issue. My unraid install was mounted on a USB drive for a few years and never had any problems until this upgrade. I followed your steps and got the array back online.

I agree with Sundune's comment that the upgrade process should be doing a pre-upgrade check and letting users know that their USB stick may need to be re-formatted/updated.

Thanks again :-)