TrueNAS SCALE 22.02-RC.1 Now available!

[masru]

I can logon to the GUI and marked 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.

Didn't worked for me, but I selected the boot environment while booting.
Maybe because my boot-pool is "feature@xattr_compat enabled", too?

 

[Kasazn]

Didn't worked for me, but I selected the boot environment while booting.
Maybe because my boot-pool is "feature@xattr_compat enabled", too?

Yup most likely

 

[MadMungo]

It also did not work for me, I was also able to select an earlier boot environment whilst booting.
My boot-pool is "feature@xattr_compat disabled".
I think it might have something to do with using a bridge interface for networking as during boot
I saw a line something like br0: interface disabled.

 

[depasseg]

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.

Reading through the reports in this thread, it sounds like "enabled" is causing a failure that requires console access to rollback. This is going to make upgrading my 225TB chia farm system a challenge. Any idea if this is something that IXsystems could even provide a path to resolve, or is it really a destroy and re-install as the only option?

 

[c77dk]

Nuked the pool, and recreated it from 22.02-rc.1. Checked the flag wasn't there - restored my datasets, and I'm back at "Import ZFS pools". Next stop is to try a total nuke of the server, incl. BEs

EDIT: after another reboot I was able to finish the import .... have kicked of a scrub before trying to boot again

 

[masru]

Reading through the reports in this thread, it sounds like "enabled" is causing a failure that requires console access to rollback. This is going to make upgrading my 225TB chia farm system a challenge. Any idea if this is something that IXsystems could even provide a path to resolve, or is it really a destroy and re-install as the only option?

I don't think so, but we have to wait for any official statement.

My next try would have been not to upgrade but to install RC on a fresh medium and plug all disks into that. If I understand the release notes right this installation would ignore the attribute. But I could be wrong with that ...

 

[dmordan]

I attempted to upgrade from Core 12.0-U6 to Scale RC1 which failed. Got dumped at the command prompt with the last message reading that middleware could not be started. Installing Scale from scratch works but if I attempt to import my old config, same problem with middleware failing to start on boot. First time atteempting to move from Core to Scale so no issues with xattr. Any hints?

 

[Samuel Tai]

I attempted to upgrade from Core 12.0-U6 to Scale RC1 which failed. Got dumped at the command prompt with the last message reading that middleware could not be started. Installing Scale from scratch works but if I attempt to import my old config, same problem with middleware failing to start on boot. First time atteempting to move from Core to Scale so no issues with xattr. Any hints?

It's not possible to use a Core config in Scale, due to differences in the underlying OS (FreeBSD vs Debian) and virtualization technologies (FreeBSD jails/bhyve vs KVM). You'll need to migrate everything by hand and recreate your shares manually.

 

[dmordan]

It's not possible to use a Core config in Scale, due to differences in the underlying OS (FreeBSD vs Debian) and virtualization technologies (FreeBSD jails/bhyve vs KVM). You'll need to migrate everything by hand and recreate your shares manually.

So just to confirm, it's not possible to upgrade from Core to Scale, this is not being supported due to differences in config? So anyone wishing to do so will need to format and rebuild?

I knew I would need to recreate my jails as containers, but I thought moving from Core to Scale would be supported.

 

[Samuel Tai]

So just to confirm, it's not possible to upgrade from Core to Scale, this is not being supported due to differences in config? So anyone wishing to do so will need to format and rebuild?

I knew I would need to recreate my jails as containers, but I thought moving from Core to Scale would be supported.

Not at this time. I believe a Core->Scale migration is on the roadmap, but it's not possible at present.

 

[c77dk]

So just to confirm, it's not possible to upgrade from Core to Scale, this is not being supported due to differences in config? So anyone wishing to do so will need to format and rebuild?

I knew I would need to recreate my jails as containers, but I thought moving from Core to Scale would be supported.

CORE to SCALE is possible by booting on the ISO. During install you'll be asked if you want to use your existing config - and then there ight be some tweaking afterwards.

 

[c77dk]

Not at this time. I believe a Core->Scale migration is on the roadmap, but it's not possible at present.

It's possible using the ISO - with jails and bhyve being left out

 

[depasseg]

I don't think so, but we have to wait for any official statement.

My next try would have been not to upgrade but to install RC on a fresh medium and plug all disks into that. If I understand the release notes right this installation would ignore the attribute. But I could be wrong with that ...

I was thinking this same thing - basically wipe out the TN Scale Beta boot pool and do a fresh install, then import the data pools and either restore teh config or just set up my apps and system from scratch. But I'll be waiting a bit for some further debugging and guidance.

 

[j_r0dd]

This whole xattr_compat issue leaves a bad taste in my mouth. A change like this never should have made it any form on any build until merged upstream. Breaking samba, nfs, middleware, etc is one thing, but messing with pool data is reckless imo. It was a nightmare moving one of my pools over to ubuntu from scale. Not only do I need to compile the debs from truenas source, but also need to now do some git reverts since it has been disabled in the source. I feel like SCALE was such a community effort with testing and submitting jira tickets to get to this point and now the testers are the one footing the bill on this one. I've been using freenas/truenas for many years now, but this is no bueno. I'm in the process of replicating all my datasets with zfs send tank/mydataset | zfs receive -x xattr_fallback -x xattr_compat tank/mydatasetnew and once done I will dry reimporting the pool with feature not active. Not trying to start drama or anything. Kris was helpful a few weeks back in the discord and one of the devs also was on github. I will report back once done. Only 14TB more to go....

actually just tried on a test pool....
cannot import pool 'k8s': property 'feature@xattr_compat' can only be set to 'disabled' at creation time
So it can not be disabled without destroying. Simply 'enabled' will import just fine, but 'active' is the headache. That is what I am trying to fix on this 1 pool I moved to Ubuntu. I'll update later......

 

[dmordan]

It's possible using the ISO - with jails and bhyve being left out

Yeah, I did some research and know people have done it without issue. There just seems to be something about my config that is causing problems. The upgrade installation completes without error, the database migration completes successfully, everything seems to work just fine. Then on the reboot I get the middleware issue and it's game over.

It's not a huge deal since I can reload 12.0 and restore the config, after which everything works great as always. I was asking more to understand what I should do. If migrating is supposed to be supported, how do I help with the bug process? If ultimately this is not going to be supported and I have to burn a day rebuilding it from scratch, no worries. Just looking for some insight.

 

[jkng88]

I manage to update to RC1 with no issues. However, later on I upgraded one of my pools and tried to reboot.

Then I faced the same issue as everyone where the boot stuck at importing zpool.

Tried a fresh install and all zpool can be imported except for the upgraded pool. The rest of the pool was upgraded in BETA 2 and is working but the pool that is upgraded in RC1 is causing issues.

 

[groenator]

Am I able to update my nas having these settings enabled on my titan zfs pool?

Code:

truenas# zpool get all | grep xattr
boot-pool  feature@xattr_compat           disabled                       local
titan      feature@xattr_compat           enabled                        local
truenas#

I never used Core, the NAS and pools were configured using Scale from the beginning.

 

[elvisimprsntr]

Originally on CORE, then installed SCALE BETA.1 and upgraded my pools.

Since then, I've switched to the nightlies and get a different result.

Code:

root@NAS-3[~]# zpool get all | grep xattr
data       unsupported@com.ixsystems:xattr_compat  inactive                                     local
external   unsupported@com.ixsystems:xattr_compat  inactive                                     local
external2  unsupported@com.ixsystems:xattr_compat  inactive                                     local
root@NAS-3[~]# cat /etc/version      
22.02-MASTER-20211027-092926#                             

 

[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.

Nuked the pool, recreated the pool, reinstalled the apps. Everything working.

 

[c77dk]

Nuked the pool, recreated the pool, reinstalled the apps. Everything working.

Same here - including a full reinstall of TrueNAS to make sure boot-pool didn't mess things up