TrueNAS 13.0-U1 is Now Available

Joined
Oct 22, 2019
Messages
3,587
Subjectively, it feels like iX are leaving CORE to die on the vine; it's looking like all the new development effort is going into SCALE with none of it (even GUI features which you'd think would be easy to move over) making its way back into CORE.

I hope this is true, but remain somewhat skeptical. Yes, you just released CORE 13--with at least one Corral-class showstopping bug. Over six weeks later, and it hasn't been fixed, nor has the release been pulled. And Kris' comments at that time sounded a lot like CORE was going to stagnate. The remarks here about "the major transition of TrueNAS from FreeBSD to Linux," well, don't do much to dispel that impression.

Really, it's been the case for quite some time that the best practice for using plugins is to not use plugins. But Morgan's denials notwithstanding, I suspect CORE's days are numbered.

iX seem to have a real problem with determining when their software is release-ready.


"Tickets now on sale! Be sure to use code DEDUP22 at MyBookie for five dollars off your first bet!"

4eSDnQX.jpg



All in good fun, everyone! :tongue: (I took the quotes way out of context for fun. We're all civilized here.) :wink:
 

vlj

Dabbler
Joined
Oct 25, 2019
Messages
14
Can Danb35 use all he finds in the map as weapon?
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
@morganL Which version of FreeBSD is in 12.0-U8.1?
 
Joined
Oct 22, 2019
Messages
3,587
@morganL Which version of FreeBSD is in 12.0-U8.1?

This is my output on a TrueNAS Core 12.0-U8.1 system:
Code:
% uname -a
FreeBSD truenas.local 12.2-RELEASE-p14 FreeBSD 12.2-RELEASE-p14 325282c09a5(HEAD) TRUENAS  amd64


Code:
% freebsd-version
12.2-RELEASE-p14
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
Precisely the problem. 12.2 is out of support. Or as they say, it's dead, Jim!
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
Precisely the problem. 12.2 is out of support. Or as they say, it's dead, Jim!

While individual components of TrueNAS may be out of date, we view support of TrueNAS as a whole. TrueNAS 12.0-U8 is still supported.
If there were a bug in FreeBSD 12.2 that was impacting a customer (or many members of the community), there are several potential solutions:

1) Hot patch fix the specific bug ourselves​
2) Use a patch (or change the configuration) to avoid the specific bug​
3) Update to 13.0-Ux where bug is already fixed​
4) Sidegrade to SCALE 22.02 (mostly if issue is virtualization or App related)​

1) and 2) are for emergencies. We released U8.1 as an emergency. There was no strong demand for U9.

Most problems would now be solved with 3) TrueNAS 13.0 is significantly faster, more secure, and inherently more reliable. However, it isn't as mature.

Some customers and community prefer 4), sidegrade to TrueNAS SCALE. More functionality, but less maturity.

Our approach is to provide sensible choices - we don't claim perfection. Most people agree that quality has improved significantly over the last 4 years with greater investment in testing and more discipline.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
You cannot pkg install anything in a 12.2 jail and while 12.3 jails probably run well this is not guaranteed. I hope that old recurring problem is finally solved with TN 13.0 tracking FreeBSD-stable.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
You cannot pkg install anything in a 12.2 jail and while 12.3 jails probably run well this is not guaranteed. I hope that old recurring problem is finally solved with TN 13.0 tracking FreeBSD-stable.
It's a good example of where 3) "Upgrade to TrueNAS 13.0" is needed.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
I am running 13.0 everywhere I need jails. But you probably know what I an getting at: there is currently no general, conservative or mission critical (your definitions) version of TN based on a supported version of FreeBSD. And I think that is a problem.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
I am running 13.0 everywhere I need jails. But you probably know what I an getting at: there is currently no general, conservative or mission critical (your definitions) version of TN based on a supported version of FreeBSD. And I think that is a problem.
Yes, but we just released TrueNAS 13.0-U1.1 which we think is a good candidate.
Agreed it's not yet field-proven. That is not a switch we can flick.
 
Joined
Jan 18, 2017
Messages
524
:eek: two unscheduled reboots since update..... time to start testing hardware
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,398
I've not encountered any unscheduled reboots after upgrading to 13.0-U1.1. It only deploys the ixnas.so hotfix @anodos dropped last week for manual installation in U1. Unless there's something funky going on with SMB Aux parameters in either the SMB service or share definitions, I don't see how this could trigger an unscheduled reboot.
 

vlj

Dabbler
Joined
Oct 25, 2019
Messages
14
I've not encountered any unscheduled reboots after upgrading to 13.0-U1.1. It only deploys the ixnas.so hotfix @anodos dropped last week for manual installation in U1. Unless there's something funky going on with SMB Aux parameters in either the SMB service or share definitions, I don't see how this could trigger an unscheduled reboot.
No unscheduled reboot here as well. I also have anodos's hotfix
 
Joined
Jan 18, 2017
Messages
524
Lets see if anyone else has a similar issue... were there none beforehand?
No, there were none before.
I've not encountered any unscheduled reboots after upgrading to 13.0-U1.1. It only deploys the ixnas.so hotfix @anodos dropped last week for manual installation in U1. Unless there's something funky going on with SMB Aux parameters in either the SMB service or share definitions, I don't see how this could trigger an unscheduled reboot.
I'm betting against it having anything to do with SMB, I'm going to try to stamp it out BEFORE doing the hotfix since the problems in the fix haven't been an issue for me.... that I am aware of.
 
Joined
Oct 22, 2019
Messages
3,587
Lets see if anyone else has a similar issue...
Might not be specific to Core version 13, but I did inadvertently force a friend's TrueNAS server to its knees on a consistent basis, causing unscheduled reboots. (Really a system hang/crash until a power-cycle was forced.)

Their system: TrueNAS Core 13.0-U1

Through SSH, trying to run a zfs send/recv to another pool, in which the source dataset is non-encrypted, but the destination dataset is encrypted and locked, the transfer will commence, spit out an error about no available base snapshot, create a non-encrypted dataset nested underneath the encrypted destination dataset, and then the entire system hangs. Cannot ping server, SSH session broken, web GUI unresponsive, etc.

The mistake was we forgot the load the key (for the encrypted destination dataset) prior to the send/recv. However, I would have assumed the send/recv would simply abort with an error. Not sure why it takes down the entire server. :oops:

This would be hard for me to help troubleshoot, since I'd rather not keep crashing my (or their) system repeatedly for the sake of a bug report.

I realize we used the terminal (SSH) rather than a Replication Task in the GUI (it's for a good reason.) But even still, if a send/recv is not possible, it should abort with an error; not crash the entire server.

Not sure if this is related to TrueNAS, per se, or upstream OpenZFS.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,545
Might not be specific to Core version 13, but I did inadvertently force a friend's TrueNAS server to its knees on a consistent basis, causing unscheduled reboots. (Really a system hang/crash until a power-cycle was forced.)

Their system: TrueNAS Core 13.0-U1

Through SSH, trying to run a zfs send/recv to another pool, in which the source dataset is non-encrypted, but the destination dataset is encrypted and locked, the transfer will commence, spit out an error about no available base snapshot, create a non-encrypted dataset nested underneath the encrypted destination dataset, and then the entire system hangs. Cannot ping server, SSH session broken, web GUI unresponsive, etc.

The mistake was we forgot the load the key (for the encrypted destination dataset) prior to the send/recv. However, I would have assumed the send/recv would simply abort with an error. Not sure why it takes down the entire server. :oops:

This would be hard for me to help troubleshoot, since I'd rather not keep crashing my (or their) system repeatedly for the sake of a bug report.

I realize we used the terminal (SSH) rather than a Replication Task in the GUI (it's for a good reason.) But even still, if a send/recv is not possible, it should abort with an error; not crash the entire server.

Not sure if this is related to TrueNAS, per se, or upstream OpenZFS.
If you can download a debug from the remote server you can check whether it's a kernel panic causing reboot. That said sometimes with security-related issues the correct course of action is to panic or crash. Your debugs will probably give clues about what is going on and why.
 
Joined
Oct 22, 2019
Messages
3,587
That said sometimes with security-related issues the correct course of action is to panic or crash.
Imagine that type of logic if someone enters the incorrect passphrase when trying to login. :tongue:

I can try to recreate the issue on a playground Linux box (bypassing TrueNAS) to see if it is indeed upstream ZFS. That way, I don't have to crash a running TrueNAS server.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
Might not be specific to Core version 13, but I did inadvertently force a friend's TrueNAS server to its knees on a consistent basis, causing unscheduled reboots. (Really a system hang/crash until a power-cycle was forced.)

Their system: TrueNAS Core 13.0-U1

Through SSH, trying to run a zfs send/recv to another pool, in which the source dataset is non-encrypted, but the destination dataset is encrypted and locked, the transfer will commence, spit out an error about no available base snapshot, create a non-encrypted dataset nested underneath the encrypted destination dataset, and then the entire system hangs. Cannot ping server, SSH session broken, web GUI unresponsive, etc.

The mistake was we forgot the load the key (for the encrypted destination dataset) prior to the send/recv. However, I would have assumed the send/recv would simply abort with an error. Not sure why it takes down the entire server. :oops:

This would be hard for me to help troubleshoot, since I'd rather not keep crashing my (or their) system repeatedly for the sake of a bug report.

I realize we used the terminal (SSH) rather than a Replication Task in the GUI (it's for a good reason.) But even still, if a send/recv is not possible, it should abort with an error; not crash the entire server.

Not sure if this is related to TrueNAS, per se, or upstream OpenZFS.

If you use the TrueNAS WebUi/API/CLI, then TrueNAS software might be able to handle the condition. If you use the OS (BSD or Linux) CLI, then there's not much TrueNAS can do.
 

airflow

Contributor
Joined
May 29, 2014
Messages
102
I upgraded today from 12.0-U8.1 to 13.0-U1.1 and ran into the problem that I couldn't authenticate with SSH & PubKey-Auth on the system.

When I checked the log /var/log/auth.log, I see

Code:
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Connection closed by authenticating user root 192.168.0.45 port 64467 [preauth]


In /etc/ssh/sshd_config, there's the line

Code:
#PubkeyAuthentication yes


Is this intentional? Why has PubKeyAuth been disabled per default now?
 
Top