Skip to content

News

What is new in the project. Newest first.

8 October 2026 — v0.1.4-dev: updates by packages, and a boot code fix

If you installed v0.1.3-dev beside an existing system, update. In v0.1.3-dev an update through the train wrote the boot code into partition one of each disk, whatever that partition was. On layouts made by the TrueNAS installer it is always the boot partition; installed beside an existing system it is somebody else's — on our test machine, a member of the data pool. The new build reads the right partition from the disk layout, and the fixed script is the one that runs during the update, so updating from v0.1.3-dev is already safe.

Updates now go by packages. The train publishes a signed manifest; a system on this build installs the new version with pkg into a new boot environment, carries its configuration over and reboots into it. A manifest that does not verify stops the update. Systems on earlier builds keep receiving updates the old way, and v0.1.3-dev gets this build through the train.

Checked on this build before it was published:

  • an upgrade from TrueNAS CORE 13.3 and a clean install in a virtual machine;
  • an update from v0.1.3-dev through the train, as users will receive it;
  • on the physical test machine, by hand at the console: a fresh TrueNAS CORE 13.3-U1.2 with a raidz2 data pool, upgraded with the BSDnas installer into a new boot environment. All twelve checksums matched, read locally and over SMB with the user and share carried over from TrueNAS; the TrueNAS boot environment was kept. The run was recorded from the machine's screen.

Known issue: SMB group mapping is not synchronised (the call it relies on exists only in the patched Samba of TrueNAS). Access to shares works.

6 October 2026 — v0.1.3-dev: the installer's safety checks are now in the image

The previous image, built on 19 August, predated every installer fix made since: refusing to touch the disks when the image has no manifest, stopping with a clear refusal when an upgrade finds no installed system, and not waiting for a keypress on an unattended machine nobody is watching. The site described those as verified, but the download did not contain them. The new development build does.

Checked on this build before it was published:

  • an upgrade from official TrueNAS CORE 13.3-U1.2 kept the pool, the SMB share and an iocage jail, which runs on the FreeBSD 15 kernel;
  • an unattended network upgrade on the physical test machine brought the data pool through with all twelve checksums matching and the partition table unchanged to the sector;
  • a clean install produced a clean system.

The image also brings installing beside an existing system — into the free space of the disks, leaving the existing partitions alone. It has been run on one layout only, GPT with FreeBSD/ZFS partitions and BIOS boot; MBR and UEFI are refused, and going back to the previous system afterwards does not work yet. The status page lists what remains untested.

3 October 2026 — migration from other systems tested: no data loss in any scenario

The likeliest way someone arrives here is not a clean install but a move from whatever they are already running. We took three such systems, reproduced them on real hardware together with their data, and tried upgrading them to BSDnas.

TrueNAS CORE — the migration works. We installed stock TrueNAS 13.0-U6.7, created a data pool, filled it with checksummed files, added a user and an SMB share. Then we upgraded to BSDnas. The result: the system is ours, the pool is intact — all twelve files present and their checksums matching, the configuration carried over along with the user, the share and the network settings, and the disks were never repartitioned.

We also checked the thing people usually forget: going back. The previous TrueNAS CORE boot environment stayed untouched in the boot pool. We switched to it and the machine came up in the old system, with the data pool readable there too. We switched back and returned to BSDnas. The migration is reversible, and that was verified by booting, not by reasoning.

TrueNAS SCALE and old FreeNAS — the installer refuses. Neither was recognised as a system of ours, and we cannot upgrade either of them in place yet. What matters is what happens in that case: the installer stops with a clear message and does not touch the disks.

Upgrade was requested, but no installed system was recognised.
Refusing to erase: an upgrade must not silently turn into a wipe.

This is a deliberate decision, not an excuse. "Upgrade" and "erase everything" are different intentions, and substituting one for the other is not acceptable. After every refusal we checked the disks: the partitioning was unchanged, the pools were there, the checksums matched.

What we will not claim is why the FreeNAS refusal fired. That install keeps its system on UFS, which would be reason enough — but we never booted it, and old FreeNAS creates its configuration database on first boot, which is exactly what our recognition looks for. So the refusal may have come from the filesystem or from a database that was not there yet. Separating the two needs another run, and until it happens the UFS explanation is a guess, not a finding. SCALE is a different matter: it is Linux, and that one is plain.

Along the way we confirmed that a pool created by OpenZFS on Linux is readable by our system without a single caveat: the import is clean, every enabled pool feature is supported, the files are intact.

What comes next. Migrating from SCALE and from old FreeNAS is the next task: learning to place our boot environment alongside a foreign one without repartitioning the disks. The three tested scenarios now serve as its acceptance criteria.

17 September 2026 — the system lives on your data disks, no USB stick needed

TrueNAS requires a dedicated boot device and forbids putting pools on it. In practice that device ends up being a USB stick, and USB sticks die — a complaint familiar to almost every home NAS owner.

BSDnas drops the requirement. The installer takes a slice of a given size on each disk for the system and leaves the rest for data. The system lives on a mirror of those slices; data lives in an ordinary pool on what remains of the same disks.

Verified on real hardware: six 1 TB disks, 16 GB per disk for the system, boot-pool mirrored across all six, the data pool a raidz2 built from the remainder. One mirror member is a disk with 432 unreadable sectors, kept in on purpose — the install went through, the pool came up, no errors. A six-way mirror survives losing five disks, which leaves the system better protected than it ever was on a single stick.

Details on the Installation page.

19 August 2026 — updates run on their own train

The project no longer depends on the iXsystems update servers. BSDnas has its own mechanism: a new boot environment is created as a clone, the update is installed into it, and the previous one stays untouched — if something goes wrong, you go back by switching environments, not by restoring from a backup.

Details in Project status and Upgrading.