Title says it all. Will this be possible? Currently my boot/flash is on a dedicated USB disk. Can I move it to the cache disk (SSD in ZFS mirror) and will this give me mirrored protection for failure?

Yes that's what the new internal boot feature is for.

And no negative impact of running dockers and boot files from the same disk?

Wasn’t sure whether the new internal boot requires a dedicated internal disk for boot?

No.

You can choose whether you want the drives to be dedicated to boot or shared with data when setting up.

Is there a "how-to"? I had googled and found below that says that I need to vipe / use an empty ssd/nvme to use as my internal bootdisk?

If the device has data that you want to keep you need to migrate it first

On 5/31/2026 at 10:12 PM, steve1977 said:

Can I move it to the cache disk (SSD in ZFS mirror) and will this give me mirrored protection for failure?

Before going further with the cache drive migration -- did you know that Unraid 7.3 actually supports a mirrored USB boot pool?

Two USB drives in a ZFS mirror, redundancy against single drive failure, zero impact on your cache drive or its data.

Might be worth considering given where things stand right now.

Thanks for your help. What do you mean by "where things stand right now"?

I have not yet pulled the triggered, but planned to change my setup to migrate from the usb boot flash disk to a mirroed zfs pool that keeps 8GB for the bootdisk and remainder for docker containers and download location for the *arrs. Separately, I'll a few array disks as well as an nvme for my virtual machine. Eventually, I'd like to install the VM bare-metal to allow dual-boot into Unraid (with VM accessing bare-metal) or optionally also boot into the VM directly, which will be better for occasional gaming.

I meant given that you're still in the planning stage -- it's easier to evaluate alternatives now than after the fact.

The configuration you're describing, 8GB boot partition shared with docker containers and download storage on the same NVMe, means a single drive failure loses your OS configuration and all that data at the same time.

That's a huge failure spread for one physical device.

A mirrored USB boot pool handles the redundancy without touching your NVMe at all.

Your NVMe stays dedicated to docker and storage with its full capacity available.

The two functions stay independent -- if either fails the other is unaffected.

https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-internal-boot-hardware-selection-and-risk-tradeoffs/

Thanks. Plan was a mirrored ZFS pool for boot/docker. This should leave me protected unless both disks die.

Besides losing 8gb from my “docker/scratch” disk, I don’t see any obvious disadvantages. Am I missing any?

Advantage would be to have a cleaner setup rather than the need to work with usb disks, which historically have proven to be prone to failures.

Historical unreliability of the current crop of consumer USB flash is real, but the opposite is also true for higher-quality legacy MLC and current industrial MLC/SLC drives.

The historical record also shows that legacy consumer USB flash drives are very reliable -- some of those are still being used as Unraid boot devices 2 decades later.

fTPM licensing (if you plan on using it) adds a layer that USB licensing doesn’t have -- BIOS updates, microcode patches, or CMOS clears that can reset the identifier. But those risks are not applicable to dTPM - the discrete TPM module.

I'm just trying to present a bigger picture.

You can only make an informed decision when you're aware of all known pro's and con's.

One more thought -- internal boot is a brand new feature.

The Unraid community's own golden rule applies here as much as anywhere: new major features need time to prove themselves in real world conditions across diverse hardware configurations.

You mentioned no issues with your current USB setup.

That's actually the most important data point. A working system with no complaints is not a problem requiring a solution -- especially when that solution involves a fundamental architectural shift rather than a routine upgrade.

Unlike a software version that can be rolled back, migrating to internal boot changes your boot architecture, your licensing anchor, and your failure domain in ways that aren't easily reversed.

The long term reliability picture for internal boot won't be clear for another year or two minimum!

If your USB setup works, the most defensible position right now is to wait.

Let others accumulate the real world experience first.

Revisit in 12-24 months when the community has long term data rather than early adopter enthusiasm

Edited June 23Jun 23 by Lolight