TrueNAS 13.0-U1 is Now Available

[winnielinnie]

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!"

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

 

[vlj]

Can Danb35 use all he finds in the map as weapon?

 

[Patrick M. Hausen]

@morganL Which version of FreeBSD is in 12.0-U8.1?

 

[winnielinnie]

@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]

Precisely the problem. 12.2 is out of support. Or as they say, it's dead, Jim!

 

[morganL]

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]

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]

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]

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]

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.

 

[cobrakiller58]

two unscheduled reboots since update..... time to start testing hardware

 

[morganL]

two unscheduled reboots since update..... time to start testing hardware

Lets see if anyone else has a similar issue... were there none beforehand?

 

[Samuel Tai]

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]

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

 

[cobrakiller58]

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.

 

[winnielinnie]

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.

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]

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.

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.

 

[winnielinnie]

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.

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]

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.

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]

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?