TrueNAS SCALE 22.02-RC.1 Now available!

[mballe]

I am running into the import issue. I updated my Core system to Scale as Beta1 came out. I have not done anything related to xattr_compat that I know of. This is what I see when I run

zpool get feature@xattr_compat boot-pool tank


NAME PROPERTY VALUE SOURCE
boot-pool feature@xattr_compat enabled local
tank feature@xattr_compat enabled local

Based on that info, am I expected to have the import issue, and is there any solution available by now?

 

[depasseg]

I read that article from Kris 4 times, and I still can't tell if it affects my pools or not. The article needs to have output examples of "good" and "bad" from that zpool command.

 

[Patrick M. Hausen]

No problem booting or importing the storage pool, but "spinning progress indicator of death" when I try to view my installed apps. Viewing available apps, updating catalogs work fine.

 

[07stuntar1]

What is the best way to make a iscsi or smb distributed share? I dont see it in true command yet?

 

[Kris Moore]

What is the best way to make a iscsi or smb distributed share? I dont see it in true command yet?

SMB will be the first option, coming in a TrueCommand update in the coming months.

 

[truecharts]

To clarify, we're not aware of any import issues related to ACLs.

We've seen our fair share of ACL related complications during BETA, but we've also yet to encounter anything that looks like those for RC1.

RC1 seems to be relatively solid and more solid than the last beta, except for a super small amount of users that created a pool during the problematic period described in the release notes.

 

[skieast]

Upgraded from BETA2, all seems good. Pools imported. No errors (yet). BETA2 was an upgrade from CORE 12.0-u6 which also went well. I was having some NFS acl issues before, will see what has changed. Thanks for the update.

 

[mballe]

According to the release notes, this issues affects:

Users who created or upgraded a pool using a TrueNAS SCALE build from between June 29 and July 15, 2021, or who have manually set xattr_compat=all on a dataset and written an xattr will have activated the feature.

I first upgraded my Core system to Scale when Beta1 came out. The Beta1 software on my device has a creation date of 2021-09-01.

So my setup should in theory not be affected by this issue? But it seems to be.

 

[depasseg]

So if this "enabled", does that mean I'm in trouble?

Code:

truenas730xd# zpool get all | grep xattr_compat       
boot-pool  feature@xattr_compat           enabled                        local
hdd01      feature@xattr_compat           enabled                        local
hdd02      feature@xattr_compat           enabled                        local

 

[elvisimprsntr]

I'm currently running nightlies. I unintentionally deleted BETA.2.

Is there a way to install RC.1 without wiping my nightlies?

UPDATE: After reading the posts about problems upgrading in place from BETA.2 to RC.1, seems the nuclear option might be the way to go or simply wait for RC.2

 

[morganL]

So if this "enabled", does that mean I'm in trouble?

Code:

truenas730xd# zpool get all | grep xattr_compat      
boot-pool  feature@xattr_compat           enabled                        local
hdd01      feature@xattr_compat           enabled                        local
hdd02      feature@xattr_compat           enabled                        local

Reading through the release notes: https://www.truenas.com/docs/releasenotes/scale/22.02-rc.1/#zfs-feature-flag-removal
Your pool has the feature "enabled", but not "active"
Only if the feature is "active" is there a long term problem.
Be prepared to rollback, but I think you are OK. You can wait for confirmation or let us know how it goes.
We do need to document what happens to pools with "enabled" state after upgrade.

 

[Kasazn]

Anything unusual about the pools?.... were they created by SCALE or imported from CORE or somewhere else.
It would be good if anyone with difficulties could share their zpool features.

Just a normal zpool, been on Scale since day 1. Reformatted once for Beta1 and 2. Nothing special. SMB shares only.

EDIT: 3x4TB pools are on HBA. 1x 750gb system pool is on motherboard SATA3 header.
EDIT: Attached pool config as per comments above
EDIT: I did not change any flags or enable anything manually from Shell.
EDIT: I tried remounting the pools on RC.1 but no avail. Back to BETA.2 it is.
EDIT: Those drives showing "active" are the disconnected/offline pools.

 

[masru]

OK, I can confirm that my failing RC1 update is caused by the xattr issue.
Running "zpool get all | grep xattr" I have 11 pools showing "enabled" and one showing "disabled". None shows "active".

 

[c77dk]

OK, I can confirm that my failing RC1 update is caused by the xattr issue.
Running "zpool get all | grep xattr" I have 11 pools showing "enabled" and one showing "disabled". None shows "active".

Also no "active" with my pool - but unable to import. So in the process of nuking pool and restoring

 

[Etorix]

the affected pools simply cannot be imported.

Quite annoying for a storage server, isn't it?
This "simply" is hereby nominated for the Understatement of the Year Award.

 

[Patrick M. Hausen]

Quite annoying for a storage server, isn't it?
This "simply" is hereby nominated for the Understatement of the Year Award.

You are aware that you are testing pre-release software? If you need a reliable storage server now, I recommend you run CORE.

 

[masru]

You are aware that you are testing pre-release software? If you need a reliable storage server now, I recommend you run CORE.

This is true for sure. And I'm not complaining. But he has a point here.

The description "the affected pools simply cannot be imported." is not really what happens here.
The upgrade process from BETA.2 fails completely and leaves you with a bricked system, at least for now. You have to roll back.

And it is really fortunate it happens now, so that the developers can implement an update process which doesn't leave your system unusable :)

 

[Patrick M. Hausen]

The description "the affected pools simply cannot be imported." is not really what happens here.
The upgrade process from BETA.2 fails completely and leaves you with a bricked system, at least for now. You have to roll back.

But you don't lose the data, if you roll back, do you? Not quite sure if I got this correctly ...

And it is really fortunate it happens now, so that the developers can implement an update process which doesn't leave your system unusable :)

Yes, definitely

 

[masru]

But you don't lose the data, if you roll back, do you? Not quite sure if I got this correctly ...

Yes, true, no data loss.

But the update leaves you with a system that will not boot into the GUI anymore, leaving you with an OS installation which can't be finished or even accessed by the web frontend.
Oh, and you can't SSH into it, too (connection refused). Let's hope it is still on your desk and not somewhere remote ;)

I think we agree that "the affected pools simply cannot be imported." is an insufficient description of that state? :)

 

[Kasazn]

But you don't lose the data, if you roll back, do you? Not quite sure if I got this correctly ...

I can logon to the GUI and mark my BETA.2 as my active boot, so yes I can rollback and my pools are there again. No data loss. As for those who cannot even access the server through the network. No idea.