TrueNAS SCALE 23.10.1 has been released!

[Davvo]

Does this mean I can remove this

Code:

echo 0 >> /sys/module/zfs/parameters/zfs_dmu_offset_next_sync

from my init? This was the suggested bandaid until 23.10.1

Yes you can.

 

[probain]

On a positive note. It is no longer announcing that the boot-pool "needs" to be upgraded, when viewing in the terminal. So hopefully not many people will break their grub because of that. I don't know if you can manually upgrade it through the command line though.

 

[HoneyBadger]

On a positive note. It is no longer announcing that the boot-pool "needs" to be upgraded, when viewing in the terminal. So hopefully not many people will break their grub because of that. I don't know if you can manually upgrade it through the command line though.

It's now significantly harder to break the boot-pool as you'd have to unset a specific compatibility value. Even a manual upgrade from the shell didn't result in an unbootable system for me. With that said there is still no reason to manually do it.

 

[chuck32]

Did forget: These systems were NOT running apps or vms.

No apps but couple of Ubuntu VMs.

• No VM autostarted right after the reboot, even the ones not depending on encrypted datasets. Haven't tested on subsequent reboots.
• Manual boot of ubuntu VMs and home assistant without a problem

So far (not even 30 minutes up) no apparent issues, SMB shares etc. are working.

• Exporting Netdata reporting metrics to a third party database (Graphite) is now supported (NAS-123668).

Curious to test that one, setup grafana just to realize that the feature was gone in a previous release.

Happy holidays!

 

[bcat]

Did anyone else's email alerting config silently break (i.e., stop sending emails) after the update?

Specifically, the SMTP configuration under "System Settings > General > Email" seems to have been preserved, but the destination address for alerts was not. When clicking "Send Test Email" in that settings page, I get the following error:

No e-mail address is set for root user or any other local administrator. Please, configure such an email address first.

I do have an email address configured for the root user in Credentials > Local Users, but this seems to be ignored now. Setting that email address in my non-root user (bcat, also a member of the builtin_administrators group) fixed the alert delivery (both for "Send Test Email" and for real alerts).

I am definitely supportive of moving away from the root account for day-to-day usage, but silently breaking alerting like this seems a bit dangerous....

 

[probain]

Did anyone else's email alerting config silently break (i.e., stop sending emails) after the update?

Specifically, the SMTP configuration under "System Settings > General > Email" seems to have been preserved, but the destination address for alerts was not. When clicking "Send Test Email" in that settings page, I get the following error:


I do have an email address configured for the root user in Credentials > Local Users, but this seems to be ignored now. Setting that email address in my non-root user (bcat, also a member of the builtin_administrators group) fixed the alert delivery (both for "Send Test Email" and for real alerts).

I am definitely supportive of moving away from the root account for day-to-day usage, but silently breaking alerting like this seems a bit dangerous....

aparently i get the same. good find

 

[NugentS]

Mine did not - but I am using gmail OAuth rather than a direct SMTP Server

 

[probain]

Mine did not - but I am using gmail OAuth rather than a direct SMTP Server

I do as well.
Also, when setting the e-mail address for my account again. So it has a destination address. It royaly messed up the accounts in general. Triggering password resets for root-account for web-UI login and such.

 

[Davvo]

Also, when setting the e-mail address for my account again. So it has a destination address. It royaly messed up the accounts in general. Triggering password resets for root-account for web-UI login and such.

I would open a bug report.

 

[probain]

I would open a bug report.

https://ixsystems.atlassian.net/browse/NAS-125839

(Fixed your link - Mod)

 

[MJDSys]

To work around the VM issue:

1. Run FS0:\EFI\debian\grubx64.efi in the EFI shell (via a SPICE display, setting up a temporary one if needed) to boot.
2. Log in at the Debian TTY.
3. Follow Debian's instructions to install GRUB to the "EFI removable media path".

Again, I am not sure this is a TrueNAS regression... perhaps something changed in a recent Debian update. It's just weird I didn't need that workaround with Debian 12 + TrueNAS SCALE 23.10.0.1, but it is needed again with Debian 12 + TrueNAS SCALE 23.10.1.

Hi @bcat, there used to be an issue with TrueNAS that would cause that issue, but I believe it should have been fixed with 23.10.0. I was looking forward to this fix in 23.10, so I'm concerned why it would be broken now.

 

[bcat]

Hi @bcat, there used to be an issue with TrueNAS that would cause that issue, but I believe it should have been fixed with 23.10.0. I was looking forward to this fix in 23.10, so I'm concerned why it would be broken now.

Indeed, me too (though the workaround is easy enough).

There's also a dedicated thread about this and a Jira issue has been filed.

 

[sybreeder]

Is there anything i'd neet to do before i'd update from -22.12.4.1 to this cobia version ?
I did update
TrueNAS-22.12.4.1 -> TrueNAS-22.12.4.2.
it went fine
then i've upgraded to latest cobia in gui and my main pool was disconnected. it was showimg as exported. i've reimported it again in gui but smb shares stopped working. suprisingly apps looked like was still working. Reboot didn't helped. either SMB service and server itself.
i did backed up vhdx (it's virtualized in ESXi-7.0U3f) with old truenas installation and it booted fine including shares - i had to reinstall all containers unfortunately.
i'm not using Enable Host Path Safety Checks