TrueNAS SCALE 22.02.0 (Angelfish) Release

[eturgeon]

We are pleased to announce the release of TrueNAS SCALE 22.02.0 (Angelfish). It is the first official release of TrueNAS SCALE. We hope you will enjoy it.

Release Notes: https://www.truenas.com/docs/releasenotes/scale/22.02.0/
Download: https://www.truenas.com/download-truenas-scale/

Thanks for trying TrueNAS SCALE 22.02.0, and as always, we appreciate all your feedback!

 

[Kris Moore]

Special thank-you to all the iX Engineers, Testers, Docs and Community users who've put so many hours into making this release awesome :)

 

[ClassicGOD]

Few issues popped up for me after update:

1. This issue happened again: https://jira.ixsystems.com/browse/NAS-113969 not sure if I should report it again, I don't see it mentioned in change log. But I found a workaround. If this happens to you and you can't delete the folder do this:
   • Go to System -> Boot and activate previous version boot environment
   • Reboot
   • Do not unlock your pools (you can verify if your dataset folders in /mnt do not contain anything)
   • Run the update again
   • You should be able to unlock pools as normal after the update completes
2. I had 2 IP addresses on my main bridge (br0): 10.0.0.100 (gui, smb) and 10.0.0.110 (Kubernetes node IP) For some reason 10.0.0.100 was removed after update and everything was switched to 10.0.0.110. I thought my system is gone after it rebooted until I noticed the new IP. Not sure if it's just a fluke with my config or more wildly spread bug.

 

[sybreeder]

I wasn't ableto upgrade to release. Something like this popped up.

Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/job.py", line 409, in run await self.future File "/usr/lib/python3/dist-packages/middlewared/job.py", line 445, in __run_body rv = await self.method(*([self] + args)) File "/usr/lib/python3/dist-packages/middlewared/schema.py", line 1269, in nf return await func(*args, **kwargs) File "/usr/lib/python3/dist-packages/middlewared/plugins/update.py", line 412, in file await self.middleware.call('update.install_manual_impl', job, destfile, dest_extracted) File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1324, in call return await self._call( File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1292, in _call return await self.run_in_executor(prepared_call.executor, methodobj, *prepared_call.args) File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1192, in run_in_executor return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs)) File "/usr/lib/python3.9/concurrent/futures/thread.py", line 52, in run result = self.fn(*self.args, **self.kwargs) File "/usr/lib/python3/dist-packages/middlewared/plugins/update_/install_linux.py", line 23, in install_manual_impl self._install( File "/usr/lib/python3/dist-packages/middlewared/plugins/update_/install_linux.py", line 43, in _install self.middleware.call_sync("update.install_scale", mounted, progress_callback, options) File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1351, in call_sync return methodobj(*prepared_call.args) File "/usr/lib/python3/dist-packages/middlewared/plugins/update_/install.py", line 72, in install_scale raise CallError(error) middlewared.service_exception.CallError: [EFAULT] Command ['chroot', '/tmp/tmpvtjzmb5_', 'update-grub'] failed with exit code 1: /usr/sbin/grub-probe: error: failed to get canonical path of `/dev/disk/by-id/wwn-0x5002538043584d30-part3'.

reboot didn't helped.

 

[f3_]

weird issue after upgrading from RC2

 

[Glowtape]

Hmm, I'm being refused access to apt on the sudo interactive shell? That's new.

--edit: Also as root in the web shell.

--edit: Nevermind, they all don't have the execute flag for whatever reason.

Code:

root@truenas[~]# ls -l /usr/bin/apt*
-rw-r--r-- 1 root root  18664 Jun 10  2021 /usr/bin/apt
-rw-r--r-- 1 root root  88376 Jun 10  2021 /usr/bin/apt-cache
-rw-r--r-- 1 root root  26936 Jun 10  2021 /usr/bin/apt-cdrom
-rw-r--r-- 1 root root  26856 Jun 10  2021 /usr/bin/apt-config
-rw-r--r-- 1 root root  22848 Jun 10  2021 /usr/bin/apt-extracttemplates
-rw-r--r-- 1 root root 276800 Jun 10  2021 /usr/bin/apt-ftparchive
-rw-r--r-- 1 root root  47416 Jun 10  2021 /usr/bin/apt-get
-rw-r--r-- 1 root root  28191 Jun 10  2021 /usr/bin/apt-key
-rw-r--r-- 1 root root  51512 Jun 10  2021 /usr/bin/apt-mark
-rw-r--r-- 1 root root  39152 Jun 10  2021 /usr/bin/apt-sortpkgs

 

[sybreeder]

weird issue after upgrading from RC2

Aren't you on nightly build ?
on mine it shows version

 

[jakommo]

I'm facing the same issue as f3_. I installed Truenas SCALE RC2 a few weeks ago and upgraded today using the UI.
After the upgrade I'm presented with another upgrade, but it fails with

Code:

Error: [EFAULT] Unable to downgrade from 22.02.0 to 22.02.RELEASE

I rolled back to RC2 to double check which version it was installing and interestingly my RC2 upgrade screen looks like sybreeder's.

But after applying this upgrade and rebooting, I'm presented with another upgrade that looks like:

And then results in the error.

It feels like the ".RELEASE" part of the version number is missing somewhere and that's why the system thinks there is another upgrade.

 

[willcycle]

I have the same situation as f3 reported. Seems the upgrade did complete though.

 

[Sean Hafeez]

So I just updated. On reboot I had a very strange issues with VM startup. The status for autostart was flipped, VMs that I did not want to start did, and VMs I wanted to start did not. The check boxes in the GUI where reversed from the setting from before the reboot and upgrade.

 

[Yazik]

After fresh install TrueNAS SCALE 22.02.0 (Angelfish) Release i have this message to update. Why? iso 8ab1cb587ac03e6b8f3688c07863b8746a009bed26c40b104a005bd1f06e47cd isn't release or what? Why i got

infoThis is not a production release, and should only be used for testing.

 

[mjflower]

I have the same situation as f3 reported

 

[bacardi8]

Same here

 

[crkinard]

weird issue after upgrading from RC2

Getting this too with a clean load on a wiped drive form the download and verified ISO.

Upgrade

TrueNAS-22.02.0 -> TrueNAS-22.02.RELEASE

Error: [EFAULT] Unable to downgrade from 22.02.0 to 22.02.RELEASE

 

[proligde]

First of all - Thanks for the great work! It has been a pleasure to use FreeNAS and TrueNAS Core / -Scale in the last 10 Years!

Unfortunately now I had severe Issues i.e. not-working-anymore regarding the NFS service after Upgrading to RELEASE when trying to connect from different linux-machines in my network, as well as from VMs on the TrueNAS itself.

Removing/Recreating NFS-Shares didn't help, neither did trying different configurations of the service itself (nfs3/4) and the shares (allowed networks, maproot/mapuser etc.).

I always got a `permission denied` and a `showmount -e <myTrueNASSCaleIP>` showed zero entries, even when running it as root on the TrueNAS server itself, even after opening exports to 0.0.0.0/0.

After booting back into RC2 everything went back to normal. Before that I also checked `journalctl` logs where stopping/starting of the NFSD seemed to work as intended with no obvious errors. Still it didn't work.

The Permission Denied message changed to "no supported protocols" when disabling NFS completely. So at least the clients tried to communicate but not much more. A `mount -v` didn't help either: I see that it tried to handshake (correctly AFAIK) for a matching version, depending on the NFSd-Settings for v3/4 but after that -> Permission Denied.

I couldn't find anything similar in Jira but I read a comment in another thread about "NFS server was switched to kernel server.".

Im not deep enough into the TrueNAS Core NFSd implementation to investigate a more useful bug description, unfortunately.

Thanks - Max

 

[nickspacemonkey]

First of all - Thanks for the great work! It has been a pleasure to use FreeNAS and TrueNAS Core / -Scale in the last 10 Years!

Unfortunately now I had severe Issues i.e. not-working-anymore regarding the NFS service after Upgrading to RELEASE when trying to connect from different linux-machines in my network, as well as from VMs on the TrueNAS itself.

Removing/Recreating NFS-Shares didn't help, neither did trying different configurations of the service itself (nfs3/4) and the shares (allowed networks, maproot/mapuser etc.).

I always got a `permission denied` and a `showmount -e <myTrueNASSCaleIP>` showed zero entries, even when running it as root on the TrueNAS server itself, even after opening exports to 0.0.0.0/0.

After booting back into RC2 everything went back to normal. Before that I also checked `journalctl` logs where stopping/starting of the NFSD seemed to work as intended with no obvious errors. Still it didn't work.

The Permission Denied message changed to "no supported protocols" when disabling NFS completely. So at least the clients tried to communicate but not much more. A `mount -v` didn't help either: I see that it tried to handshake (correctly AFAIK) for a matching version, depending on the NFSd-Settings for v3/4 but after that -> Permission Denied.

I couldn't find anything similar in Jira but I read a comment in another thread about "NFS server was switched to kernel server.".

Im not deep enough into the TrueNAS Core NFSd implementation to investigate a more useful bug description, unfortunately.

Thanks - Max

My Proxmox box couldn't reconnect to an NFS share after the upgrade. I rebooted the Proxmox host and all was good.

 

[proligde]

My Proxmox box couldn't reconnect to an NFS share after the upgrade. I rebooted the Proxmox host and all was good.

I heard the same thing about ESXI clients (reboot/reconnect worked) but unfortunately nothing helped with the Linux clients I tried to connect. I'm using current versions of Ubuntu (20.04) on x86-64 infrastructure and current versions of debian on ARM. Both don't work anymore until I booted SCALE back into RC2

I might add: my fstab entries look as follows:

Code:

<truenasIP>:/export-path /mountpath nfs rw,hard,intr,rsize=8192,wsize=8192,timeo=14,nofail

 

[xenu]

@proligde : Does "/etc/exports" contain entries?
I use NFSv4 shares with kerberos on several clients and they all work fine. For my proxmox host I had to disable the storage entries, do a "umount" on the CLI and the enable the storage entries again (but I always had to do this after a TrueNAS reboot because of the nfs kerberos ticket). showmount -e works as well.
I use user mounts defined by FreeIPA rules and manual entries via autofs. Manual mounting also works.
autofs entry: /mnt/truenas/media -fstype=nfs4,vers=4.2,rw,sec=krb5,soft,proto=tcp truenas01.ipa.mydomain.com:/mnt/tank/media/

 

[proligde]

@proligde : Does "/etc/exports" contain entries?
I use NFSv4 shares with kerberos on several clients and they all work fine. For my proxmox host I had to disable the storage entries, do a "umount" on the CLI and the enable the storage entries again (but I always had to do this after a TrueNAS reboot because of the nfs kerberos ticket). showmount -e works as well.
I use user mounts defined by FreeIPA rules and manual entries via autofs. Manual mounting also works.
autofs entry: /mnt/truenas/media -fstype=nfs4,vers=4.2,rw,sec=krb5,soft,proto=tcp truenas01.ipa.mydomain.com:/mnt/tank/media/

The file did not contain any entries on RELEASE while it doesn't exist on RC2 at all, as I just see now. But that's interesting: Maybe something prevents the file from being created properly / populated after switching to RELEASE? Are there any logs other than journalctl I could look into? I couldn't find anything regarding NFS logs in particular other than that.

 

[anodos]

The file did not contain any entries on RELEASE while it doesn't exist on RC2 at all, as I just see now. But that's interesting: Maybe something prevents the file from being created properly / populated after switching to RELEASE? Are there any logs other than journalctl I could look into? I couldn't find anything regarding NFS logs in particular other than that.

Can you PM me a debug please?