Hi all,

I’m trying to add redundancy to my internal boot pool (single ZFS device, currently on an NVMe partition, 31.5GB). Docs state this should be supported (“Internal boot supports a mirrored boot pool with two devices in a ZFS mirror”), and regular data pools on my system show a working “Slots” dropdown to add a second device — but the boot pool (“Internal Boot” / flash) shows no Slots control at all on the Main page or on its Device detail page (/Main/Device?name=flash), just Identity/ZFS status/Scrub schedule and a “Boot device backup” button (which only downloads a zip, not a live mirror).

System info:

• Unraid: 7.3.2 (Lifetime license)

• Hardware: GEEKOM Mini IT13 (mini PC), BIOS 1.23, UEFI boot

• CPU: 13th Gen Intel Core i9-13900HK

• Boot pool: single ZFS device, NVMe (WPBSN4M8-1TGP), partition nvme0n1p3, 31.5GB, GPT 1MiB-aligned bootable

• Second device ready to attach: 64GB USB stick (SanDisk Ultra Fit), already recognized as Unassigned Device

Is there a supported way to add a mirror device to an already existing single-device boot pool via the GUI in 7.3.2? Or is this currently only possible by recreating the boot pool from scratch with both devices present from the start? Want to avoid guessing with zpool attach directly since I’m not sure it would also set up the EFI/bootable partition correctly for actual redundancy (not just mirrored data).

Thanks!

Follow-up question: would it help to skip trying to add a mirror to the existing single-device pool entirely, and instead wipe the boot pool and recreate it from scratch with both devices (NVMe + the 64GB USB stick) present and selected from the very start via the “Create New Config”/boot pool wizard? Or does that hit the same underlying issue as attaching to an existing pool?

Asking because I saw a related thread (Cannot add second device to existing internal boot pool (7.3.1) — wizard reports BOOT_ELIGIBLE_FALSE) where the same “add mirror to existing pool” attempt failed with a different error (efibootmgr rc=5) — so it seems like this specific scenario (starting from a single-device pool, not from scratch) may be the actual pain point, regardless of the exact symptom. Would rather confirm with someone who knows the code path before wiping a working boot pool to test this myself.

4 hours ago, Howi said:

• Boot pool: single ZFS device, NVMe (WPBSN4M8-1TGP), partition nvme0n1p3, 31.5GB, GPT 1MiB-aligned bootable

• Second device ready to attach: 64GB USB stick (SanDisk Ultra Fit), already recognized as Unassigned Device

Are you saying you want to use a USB connected device as a mirror for nvme device? Doesn't sound like a good idea.

Is your license still on USB? or TPM?

Thanks for the reply! To answer your questions:

• License GUID: It’s TPM-bound (confirmed in the GUI under License Key Management — “GUID Type: TPM”), not tied to the USB stick, so mixing device types for the mirror isn’t a licensing concern.

• USB as mirror for NVMe: Fair point on performance in general, but this boot pool is only 31.5GB with very infrequent writes (just config saves), so I wouldn’t expect any meaningful latency impact in practice — happy to be corrected if there’s a specific failure mode I’m not considering though.

That said, I’d still love an answer to the original question: is there a supported way (GUI or otherwise) to add a mirror device to an already existing single-device boot pool in 7.3.2, or does it need to be recreated from scratch with both devices present from the start? Still seeing no “Slots” option anywhere for the boot pool specifically, even though regular data pools show one fine.

11 hours ago, Howi said:

is there a supported way (GUI or otherwise) to add a mirror device to an already existing single-device boot pool in 7.3.2,

Stop the array

add a slot to the boot pool

assign the new devie

start array

Thanks JorgeB! That’s exactly what I tried, but the “Slots” option simply isn’t there for the boot pool. On the Main page, my regular data pool (“Multimedia”) shows a “Slots: 2” dropdown right below its device list — but the boot pool (“Internal Boot”) has no such row at all, just the device name/status line, nothing to change slot count. Same on the pool’s own detail page (Main → Device → flash) — no slots control anywhere, just Identity/ZFS status/Scrub schedule/Boot device backup.

Array is stopped when I check, so that’s not the issue. Running 7.3.2. Is this a known limitation for single-device boot pools specifically (as opposed to regular pools), or is there a precondition I’m missing to make that control appear?

There's no such limitation; something is wrong with your config. Post a screenshot from Main and the diagnostics.

nas01diagnostics.zip

The boot pool already has two devices assigned; Multimedia is just the data part of the boot pool. They are not two separate pools, though I see that the pool wasn't created correctly, since only the data partition is mirrored. Suggest recreating it.

That makes a lot of sense — the Multimedia pool was originally created via raw mkfs.btrfs CLI (not through the GUI pool-creation flow) months ago, and I recall its disks.ini entry ended up with bootPool="yes" because its devices share the physical NVMe with the boot partition. I was told at the time this flag was purely cosmetic/harmless, but it sounds like that’s actually the root of this issue.

Before I touch anything: I know there’s a separate, currently-open bug where creating a new ZFS boot pool from scratch fails at the last step (cmdMakeBootable, 500 error) — confirmed via both the GUI wizard and raw CLI/emcmd, tested across every combination of array/disk state. Given that, what’s the actual safe procedure here? Specifically:

1. Do I need to detach/reconfigure the Multimedia pool first (to remove that bootPool linkage) before recreating the boot pool, or can they be handled independently?

2. Will recreating the boot pool from scratch hit the same cmdMakeBootable failure, or is that a different code path?

3. Any specific order of operations to avoid losing the Multimedia pool’s data in the process?

Want to make sure I don’t break a working, actively-used data pool while fixing the boot pool.

One more detail while I wait: if I go the “fully separate boot pool” route, would creating a fresh ZFS boot pool from two identical 32GB USB sticks (both brand new, from scratch, not attached to the existing NVMe/Multimedia setup at all) avoid this issue entirely going forward? Or does the same “not created correctly” risk apply regardless of which devices are used, as long as it goes through the same creation flow?

7 hours ago, Howi said:

One more detail while I wait: if I go the “fully separate boot pool” route, would creating a fresh ZFS boot pool from two identical 32GB USB sticks (both brand new, from scratch, not attached to the existing NVMe/Multimedia setup at all) avoid this issue entirely going forward? Or does the same “not created correctly” risk apply regardless of which devices are used, as long as it goes through the same creation flow?

All you need to do is boot from USB, remove existing boot pool, create new boot pool from disks, and reboot. The disks should be empty so that no data is lost since they will be fully wiped during the process.

To be fair, it is not advisable to deviate from the GUI's method of creating boot pools.

Edited yesterday at 06:06 PM1 day by MowMdown

Thanks for confirming the general approach! One specific concern though: I have a confirmed, reproducible bug on this exact server where creating a new ZFS boot pool fails at the cmdMakeBootable step (500 Internal Server Error) — tested via both the GUI wizard and raw CLI/emcmd, across every combination of array/disk state. This happened when I originally tried to set up this system.

Have you personally done this “remove + recreate” procedure recently on 7.3.x and had cmdMakeBootable actually succeed? Trying to figure out if that bug is specific to my system/setup, or something everyone doing this hits — want to avoid getting stuck mid-recreation with no working boot pool at all.

I created and recreated many boot pool, if it's failing for you it's not a general problem. need to see the diags after the attempt.

Ran your suggested test again with fresh diagnostics attached (nas01-diagnostics-20260824-1029.zip).

One thing I noticed: cmdCreatePool fails immediately with "not stopped" if the array isn't stopped first. With the array properly stopped, create+assign succeed, but cmdMakeBootable still fails — this time with a more specific syslog message: cmdMakeBootable: not boot eligible.

Tested against a spare empty USB stick (not the production boot device), same result. Diagnostics attached from right after this failure.

nas01diagnostics202608241029.zip

3 hours ago, Howi said:

One thing I noticed: cmdCreatePool fails immediately with "not stopped"

Please use the wizard to create the pool, not the CLI

Tried going through the actual GUI wizard (Add Pool → assign device → Start array → check "Format" confirmation → click Format) instead of the CLI, on a spare empty USB stick. Ran into a separate, reproducible UI issue though: no matter how many times I try — both via automation and by clicking through it manually myself multiple times — the format action never actually submits. Syslog only ever shows the periodic auto-mount-retry ("mount error: wrong or no file system"), never a real format command going through. Confirmed the array is started (Format isn't even offered when stopped, as expected).

So I wasn't able to get further than the CLI reproduction — the diagnostics from that (cmdMakeBootable: not boot eligible) are still the most concrete data point I have. Happy to try anything more specific if you have ideas, but the wizard path itself seems to be silently failing to submit on this system before it even gets to the boot-pool logic.

24 minutes ago, Howi said:

Tried going through the actual GUI wizard (Add Pool → assign device → Start array → check "Format" confirmation → click Format) instead of the CLI, on a spare empty USB stick.

This is not the correct procedure to create a boot pool, you don't start the array or format anything, just run the wizard and let Unraid configure the internal boot pool, and it will then automatically reboot.

Thanks — found the "Tools → Onboarding Wizard" reference in the 7.3.0 release blog. But I noticed a related thread (topic 199012, "Not possible to add a second internal boot device after already configuring internal boot") where it sounds like for an already-configured internal boot pool (which is our exact situation — single-device ZFS boot pool already in use), there's no direct "add mirror" path through that wizard, and the described workaround involves erasing the cache partition and reconfiguring boot from scratch, with the new device needing to match or exceed the existing device's size.

Since this is a live production system, I want to be sure before touching anything: does the Onboarding Wizard actually handle adding a mirror to an already-configured internal boot pool cleanly, or does it require the destructive reconfigure path from that other thread? Want to make sure I don't lose the current boot config/license binding in the process.

We seem to be going in circles. I already told you before how to add a slot to an existing pool, but the pool you posted a screenshot from already had 2 members; you can create a new one if you like using the wizard (after rebooting from a flash drive)