2 hours ago, JorgeB said:

Yes, as long as they are >8GB.

Nope, once you boot from a pool, the flash drive is not even mounted; the licensed file is also copied to the boot pool.

Thank you — both answers are very helpful.

On the license drive point -- just to confirm the practical implication.

Once the boot pool is established and the license file is copied to it, can the original USB flash drive be physically removed permanently?

Or does it need to remain present for ongoing license validation even though it's not mounted?

If the USB drive can be removed after initial setup that changes the configuration picture significantly -- USB licensing users would achieve complete USB elimination through the mirrored boot pool without needing TPM, which wasn't previously understood to be possible.

37 minutes ago, andrebrait said:

not sure whether this works for this case, but I have also opened a GitHub issue for it here: https://github.com/unraid/webgui/issues/2583

I would recommend closing that and creating a feature request here: https://product.unraid.net/b/unraid-os-feature-requests

This is the preferred way by LT and also allows other users to comment and upvote it.

10 minutes ago, Lolight said:

Or does it need to remain present for ongoing license validation even though it's not mounted?

This.

Boot can be mirror but I want the data part to be zfs stripe. And encrypted. Possible?

6 minutes ago, Niklas said:

Boot can be mirror but I want the data part to be zfs stripe. And encrypted. Possible?

Data partition can be whatever you want, boot partition, for now, can only be an unencrypted zfs mirror (or single if you just use one device).

I don't care what the boot partition is as long as the rest can be zfs stripe and encrypted. 😉 Thanks

Edited March 23Mar 23 by Niklas

3 hours ago, JorgeB said:

This.

But we can transfer the license and tie it with TPM correct?

5 hours ago, JorgeB said:

The initial plan was to use Btrfs, which I'm also a big fan of, it has some advantages over ZFS, also some weaker points, notably the handling of dropped devices; they are not automatically brought up to date as with ZFS, and if the pool is kept being used while degraded, it will start creating single chunks for data and metadata, requiring a balance to RAID1 once the old device is brought online.

But those were being dealt with; the showstopper was an issue that was found, which is not directly a Btrfs problem but a Grub problem with its btrfs driver.

That driver is needed to first detect and load the pool devices, and it's used until the kernel driver is loaded later. Now the problem was that if you had a mirrored Btrfs pool with a stale device, and both were connected, it would fail to boot from the most recent one; it could only boot from the stale one. Example:

• Boot pool was a mirror consisting of sda and sdb

• While the server is online, sdb drops offline, let's say due to a bad cable

• The user reboots and checks/replaces the bad cable, or the device just comes back online by itself so that both devices are back online

• If the user tried to boot from sda, Grub would fail to load that filesystem, and it would just splat on boot

• Curiously, it could always boot from sdb, the stale device; just the more recent one would always fail.

After some research, it was found this was an old, known issue with btrfs and Grub, which likely won't be fixed any time soon, so after spending some days trying to work around it, LT decided to pivot to zfs, I'm sure it wasn't an easy decision, since it meant abandoning previous work done, and it ended up delaying the beta by 2 or 3 weeks, but in the end, I think it was the right decision to make the pool boot as reliable as possible.

Any chance on supporting boot from BTRFS in single device mode?

1 hour ago, Joloxx9 said:

But we can transfer the license and tie it with TPM correct?

Correct, as long as TPM 2.0 is available.

1 hour ago, primeval_god said:

Any chance on supporting boot from BTRFS in single device mode?

I don't know if LT has plans for that; technically it's certainly possible, and IMO the more choices the better. My recommendation would be to create a feature request here: https://product.unraid.net/b/unraid-os-feature-requests

That allows other users to comment and upvote so that LT can better gauge the interest.

38 minutes ago, JorgeB said:

Correct, as long as TPM 2.0 is available.

And fTPM works as well, for those in doubt about that

Looking forward to giving this a try! Booting from internal storage is definitely interesting.

Hope to see NetBird one day get first-party support like Tailscale does, that would be very cool.

Because i got no answer so far, i ask my question again:

Modern CPUs have a TPM inside... is this supported or do we need a "Hardware-Module" for the TPM-header?

Someone with infos here?

11 minutes ago, Zonediver said:

Because i got no answer so far, i ask my question again:

Modern CPUs have a TPM inside... is this supported or do we need a "Hardware-Module" for the TPM-header?

Someone with infos here?

I think the below is what you were asking. fTPM is TPM built into the CPU (AMD)

On 3/23/2026 at 12:09 PM, andrebrait said:

And fTPM works as well, for those in doubt about that

4 hours ago, Zonediver said:

Modern CPUs have a TPM inside... is this supported or do we need a "Hardware-Module" for the TPM-header?

Someone with infos here?

Check out the last section of the guide:

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

On 3/22/2026 at 11:07 AM, primeval_god said:

I am also curious about this. Until and unless BTRFS is supported internal boot is of no use to me.

I have the same opinion there, not losing memory for a ZFS pool

Edited March 25Mar 25 by starbetrayer

On 3/23/2026 at 3:30 AM, JorgeB said:

The initial plan was to use Btrfs, which I'm also a big fan of, it has some advantages over ZFS, also some weaker points, notably the handling of dropped devices; they are not automatically brought up to date as with ZFS, and if the pool is kept being used while degraded, it will start creating single chunks for data and metadata, requiring a balance to RAID1 once the old device is brought online.

But those were being dealt with; the showstopper was an issue that was found, which is not directly a Btrfs problem but a Grub problem with its btrfs driver.

That driver is needed to first detect and load the pool devices, and it's used until the kernel driver is loaded later. Now the problem was that if you had a mirrored Btrfs pool with a stale device, and both were connected, it would fail to boot from the most recent one; it could only boot from the stale one. Example:

• Boot pool was a mirror consisting of sda and sdb

• While the server is online, sdb drops offline, let's say due to a bad cable

• The user reboots and checks/replaces the bad cable, or the device just comes back online by itself so that both devices are back online

• If the user tried to boot from sda, Grub would fail to load that filesystem, and it would just splat on boot

• Curiously, it could always boot from sdb, the stale device; just the more recent one would always fail.

After some research, it was found this was an old, known issue with btrfs and Grub, which likely won't be fixed any time soon, so after spending some days trying to work around it, LT decided to pivot to zfs, I'm sure it wasn't an easy decision, since it meant abandoning previous work done, and it ended up delaying the beta by 2 or 3 weeks, but in the end, I think it was the right decision to make the pool boot as reliable as possible.

Thanks for the explanation, but what happens with UEFI and BTRFS?

On 3/23/2026 at 10:34 AM, JorgeB said:

I don't know if LT has plans for that; technically it's certainly possible, and IMO the more choices the better. My recommendation would be to create a feature request here: https://product.unraid.net/b/unraid-os-feature-requests

That allows other users to comment and upvote so that LT can better gauge the interest.

Done

https://product.unraid.net/p/internal-boot-from-non-zfs-single-device-pool?b=unraid-os-feature-requests

@Lolight thank you for writing the post that you did.

I think this section is especially important for Unraid users:

Practical TPM Recommendations

• Most stable for licensing: A dTPM discrete module installed in the motherboard's TPM header.

  Identifier persists through BIOS updates and maintenance events.

  Recommended for users who update BIOS frequently or who have experienced fTPM instability on their specific platform.

• Acceptable for most users: fTPM on platforms with stable BIOS update histories.

  Understand that BIOS updates carry a small risk of TPM state reset.

  Keep a record of your current license state before performing BIOS updates. Avoid clearing CMOS unnecessarily.

• Verify before migrating: Whether your board uses fTPM or dTPM, and whether your specific BIOS update history has produced fTPM resets on your platform.

  AMD Ryzen users in particular should check community reports for their specific motherboard model before committing to fTPM licensing.

• Legacy hardware without TPM: USB licensing continues working exactly as before.

  Internal boot remains available with USB licensing — the USB drive stays required for license validation.

  No TPM header or module purchase is necessary unless TPM licensing is specifically desired.

6 hours ago, starbetrayer said:

Thanks for the explanation, but what happens with UEFI and BTRFS?

Same thing, both legacy and UEFI boot first use the limited Grub driver, and that's what caused the problem with a stale btrfs mirror.

6 hours ago, starbetrayer said:

I have the same opinion there, not losing memory for a ZFS pool

The ARC only uses free RAM, if anything else requires it, it will automatically release it.

Re: internal boot, if your existing pool is a BTRFS mirror and you want to preserve what's on it:

Couldn't you remove one drive from the pool, provision it for internal boot, add it back to the pool (which would copy existing data to the BTRFS partition) then repeat the process with the other drive?

4 minutes ago, CS01-HS said:

Couldn't you remove one drive from the pool, provision it for internal boot, add it back to the pool (which would copy existing data to the BTRFS partition) then repeat the process with the other drive?

Nope if I understand correctly what you mean, but you could

• remove a device from the existing mirrored btrfs pool

• use the wizard to make that device the boot pool

• after booting from it, format the data partition btrfs and copy or move the data from the other pool

• once done, remove the other pool and add its device to the boot pool, it will mirror both the boot and data partitions.

Beta has been stable for me, thanks all

Yep. Stable for me too. Just waiting for some fixes in beta 2. Then i'll try internal boot (no tpm, old harware).

Edited March 25Mar 25 by Niklas

It's also been stable for me. Just waiting for the containerd image store support and I'll likely move all my NAS'es to 7.3.0.