BSDnas v0.1.4-dev — updates by packages, boot code fix for installs beside an existing system

Development pre-release built from BSDnas-15-MASTER-202610071727
(middleware 3d8df4ab98, core-build 8ce3022, pkgtools cb15b42, FreeBSD base
c7d7dee1e397 on stable/15).

If you installed v0.1.3-dev beside an existing system (adopt=yes), move
to this build before anything else. In v0.1.3-dev an update through the
train rewrote the boot code into partition one of every disk that had a
freebsd-boot partition, whatever partition one held. With the layouts
iXsystems shipped that is always freebsd-boot; with adopt=yes it is somebody
else's partition, and on our test machine it was a member of the data pool.
The index is now read from gpart show, and a disk without freebsd-boot is
left alone. The fixed script is the one in the new package, so updating
from v0.1.3-dev to this build is already safe.

Updates by packages:

• A train moves to pkg-based updates by publishing a signed manifest.json
  next to its LATEST. A system on this build checks for it first; a train
  without one keeps updating the old way. A manifest that is published but
  fails verification stops the update instead of falling back.
• The update installs into a new boot environment with pkg chrooted into
  it, so package scripts never run against the live system. The
  configuration template, the database migration on first boot and the
  version shown in the interface are carried into the new environment.
• The configuration secret survives the update; before, the database
  migration replaced it, which dropped HTTPS and the stored passwords.
• An older build is never offered as an update.
• A dropped or timed-out connection to the update server is retried, both
  in the package path and in the old freenasOS path.

Verified on this build, 7 October 2026:

• Upgrade from official TrueNAS CORE 13.3 in a virtual machine: pool and
  SMB share preserved, the CORE boot environment kept.
• Clean install in a virtual machine: READY with no pools and no shares.
• Update from v0.1.3-dev to this build through the train, as users will
  receive it: offered, downloaded, installed, rebooted into the new version;
  afterwards no further update offered.
• On physical hardware, by hand at the console: a fresh TrueNAS CORE
  13.3-U1.2 install on two mirrored disks with a raidz2 data pool on four
  more, then the BSDnas installer's "Upgrade Install" into a new boot
  environment. The data pool came through with 12 of 12 checksums matching,
  read both locally and over SMB with the user and share carried over from
  TrueNAS; the TrueNAS boot environment is kept. This run was recorded from
  the machine's screen.
• The package update path end to end on physical hardware, between two
  earlier builds of this series: data pool intact, partition table
  unchanged, configuration secret preserved.

Known issue: when SMB starts, the group-mapping sync fails (net --json groupmap exists only in iXsystems' patched Samba; this build ships Samba
4.23 from ports). Share access is not affected; group mappings are not
synchronised.

Not tested: varied controllers, real workloads, long-running systems, swap
under load.

Verify the image with SHA256SUMS and its detached signature
(BSDnas-signing-key.asc, ed25519 fingerprint
58528D1CDBDAAF7B01ED2BBE1E2F7A792066322D).