Testers,
Our first set of Nightly images for what will eventually become TrueNAS 25.04, with the latest Linux 6.12 kernel have been built:
Manual Update File:
https://update.sys.truenas.net/scale/TrueNAS-SCALE-Fangtooth-Nightlies/TrueNAS-SCALE-25.04.0-MASTER-20241125-005540.update
As usual, these are intended for developer and tester types only. Don’t use with production data, things may be unstable or otherwise broken in a variety of ways. 
Upgraded one of my backup systems, so far 6.12 seems to be humming along fine:
Good chance to play with the new containers WIP feature as well. So many distros to pick from, its almost overwhelming. I’ve always wanted to try Arch… 
Before someone asks, cloud variant of image is variant with cloud-init enabled: How to use cloud-init - Incus documentation
That’s my plan, if I eventually migrate to SCALE and switch over my FreeBSD jails to Linux “Incus” jails.[1]
The Arch rolling release model + the AUR + a legit filesystem to do custom things
=
Very similar to a FreeBSD jail + the pkg repository on the latest branch
I already use Arch-based distros as my daily desktop, anyways.
This assumes that the Incus method on SCALE allows for the same, no-nonsense management: unambiguous mountpoints; a complete network stack that does not share the host’s IP address; no dependence on any other “hidden” or “iX” datasets, other than a “jails” family of datasets, a la iocage. It would also be nice to set the compression level in advance, before an “Incus jail” is created. (Using ZSTD-9 on my iocage datasets, before a jail is created, is very effective. Root filesystems compress very nicely.) ↩︎
Why assume when you can test? Any issues found early have a chance of resolution without waiting 6 more months.
I will note, the implementation is only partial right now, but either way, early feedback during active development is always encouraged!
The bridged network mode isn’t enabled in the UI yet, just NAT / Port Forwarding. But that is expected to land soonish, we’re still in the early days of the dev cycle for Fangtooth.
The naming is going to cause troubles. I can already the “it’s getting long in the tooth, with Fangtooth” jokes
That’s OK, by the time you are good and sick of those jokes, the Goldeye release will be out and we can tell folks to upgrade 
Goldeye? I cant help but call it GoldenEye.
…which will be about the time when Betta Halfmoon goes alpha and the Hell of Name Jokes will break loose.
Thanks for the best xmas gift ever, Kris!!
Looks like one of my worries about using Linux was in vain.
One of the things Linux users look for, is recent kernels. Sometimes it is because they need updated drivers, or specific bug fixes for their hardware. These problems can prevent a user from using a specific Linux distro, (or SCALE in this case). At least until the Linux distro “catches up” in kernel.
Normally a NAS or other server type software would not release a new major version yearly, let alone twice a year. But, iX seems to have made that commitment with SCALE. That allows updating the Linux kernel at least once a year, potentially twice a year depending on upstream distro.
Of course, this won’t stop some Linux people from complaining that TrueNAS SCALE, even nightlies, does not have the kernel or driver they need.
We tried to strike the right balance here of new kernel vs stability. We’ve opted to follow the LTS releases of the kernel, which means a new Linux Kernel roughly every year (In the April release of TrueNAS). Then for the fall release, we will often be pulling in the latest point release of that LTS, so you get a chance of newer bugfixes and such landing again, before making a major jump in kernel version the following year.
Same with OpenZFS, we expect a (roughly) once a year update in OpenZFS, probably also in the April Release of TrueNAS going forward, with the fall release only getting a point release update to get bugfixes and minor improvements.
Wouldn’t it be better to split updates to avoid throwing everything together?
Kernel in April, OpenZFS in October. Tick, tock.
Marcel Dassault famously made it a principle to evolve its planes one item at at time: Either a new body shape/new materials, or new motors. Never both at the same time: Too many interactions!
Is there a microcode update included in this release to bring it closer to debian stable from TrueNAS’s v2.2?
Yes and no, its a trade-off in testing and complexity. Some of those things will have overlaps, some will not. I defer to my SQA leadership expertise on the merits of how the schedule impacts their particular testing (and re-testing) plans.
I know it’s a nightly, but I wish the Apps screen worked 
Well, you are in luck because it looks like today’s nightly fixed the Apps screen again 
Im trying to update from the latest nightly update and I get:
[EFAULT] Checksum mismatch for ‘rootfs.squashfs’:
