… as soon as i’ve completed my hdd swop out, will be scheduled.
i’m still running pre dragonfish zfs… guessing it’s time to also do the enable new features.
G
That actually seems worse than what I thought it did. So if I decided I needed to downgrade, my app data would unexpectedly revert back in time and I’d lose data and state produced since doing the upgrade?
Anyway, it doesn’t change the fact there was no warning or explanation. “Hiding user data” should not be something an upgrade does unless there’s some large blinking lights highlighting what’s going on.
And I still don’t know how I’m expected to back up app data now.
If this was actually the case (which I hope it isn’t), I cannot even begin to describe just how incorrect this is.
If you had data in the apps that you were preserving by making a copy, and then you ran EE apps for a day or two which updated that data, and then you moved back to Dragonfish, you would then be working NOT on the updated data, but instead on the original data with your updates lost.
Fortunately, I think (or hope) that this is not the case, because the data in Host Paths are not copied, and only ixVolumes would contain updateable data (as opposed to static configuration data) - and ixVolumes should no longer be in use.
IMO you want to enable new features (on non-boot pools) when you are certain that you do not plan to go back to a previous version of TrueNAS that is incompatible with these features - so typically this will be once you are completely comfortable that the upgrade version is stable.
At that point you should probably:
- Remove previous versions from the System Settings / Boot page (which will free up boot-pool space)
- Run the ZFS feature upgrade on your existing pools.
I would add that there were feature upgrades available before the upgrade to a new version, I would probably apply those before doing the upgrade.
The EE upgrade enables RAIDZ expansion, which is a new feature. I can’t remember whether it was Cobia or Dragonfish that enabled Block Cloning which was also a new feature - but these upgrades to ZFS are typically in major TrueNAS versions rather than minor ones.
2 Likes
Probably a good idea to upgrade that pool in Dragonfish before upgrading 
Are you really going to go back to Bluefin?
Migrated from Core 13.3 to stable 24.10… all seems going fine, just nothing more of a fresh install → config upload. Im migrating every app from a previous VM just fine (boring, but easy).
Just a question: i have created an admin user (waiting for disabling password on root one inherited from Core), just copying settings from the root… Enough or something else to do before?
There was a warning in the release notes, besides the months of discussions on the move and potential pitfalls. The release notes explained that the data would be moved/converted to a new system. The progress of the apps being converted to the new system could be followed on Github. I do know you could revert back during the beta to Dragonfish apps setup as I did this several times and the apps I use returned to working order, but none of those apps generated any new data.
How ix accomplished this I would imagine would be however they thought best given whatever their development parameters are and the fact it’s better to provide something to return to upon failure rather than nothing to return to.
2 Likes
Anyone else seeing higher CPU usage and temps after migrating to EE? I’m seeing about 2-3C increase overall.
Don’t know what you mean by this. The document you linked to says absolutely nothing about this behaviour. They certainly could have put a warning “in blinking lights” by using the “important” boxes on that webpage, and having the upgrade button confirmation dialogue explicitly point out the movement of user data and link to an explanation.
But they didn’t.
They really should have.
Why defend them on this? Normal users aren’t beta testers who follow every step of development in the forums. It’s important the developers take on feedback that destructive changes to user data shouldn’t be taken lightley.
1 Like
I fully agree with @sendu here - normal users are not beta testers who follow the months of discussions - unless they have a problem they don’t read these forums. Indeed if you look at the TrueNAS Software Status page, they say that 24.10.0 is suitable only for Testers and not even ready for Early Adopters - and in my view if it is not ready to be recommended even to Early Adopters and is officially still a test version, then it should still be a Beta or RC and NOT a full version. And this is IMO completely at odds with the marketing hype in the Announcements which aside for a very bland link to the Software Status page, has no warnings whatsoever that 24.10.0 is not ready for everyone.
See my comments on another thread “Migrating from TrueCharts - #128 by Protopia” with a range of suggestions about how to improve the warnings.
See also Migrating from TrueCharts - #131 by DjP-iX which says that they have added an additional sentence to the Release Notes warning about 3rd party applications. Unfortunately, I do not believe that this is enough to prevent users from reading the announcement and going ahead with an upgrade without having read and acted upon the Release Notes - perhaps because they have successfully upgraded from Bluefin to Cobia to Dragonfish including several minor interim releases without needing to take any preparatory actions, possibly without reading the Release notes for any of these and so believe that the EE upgrade will be no different.
I’ve just noticed that the WebUI is vastly improved on an iPhone 
Goes from almost unusable to pleasant
2 Likes
Agreed. But this is the way iX has rolled for at least SCALE’s entire history.
- Historical tradition doesn’t automatically make it the right way.
- If it is still only a test version, then it should be announced that way.
TBH this has the appearance of arse covering - rightly or wrongly, IMO bullish announcements combined with weasel-y caveats hidden away in other barely advertised and blandly advertised web links has a somewhat bad smell to it.
Agree 110%–this is both a bad and a wrong way to handle software releases. But it’s sadly nothing new for iX.
Well it’s in the release notes and fairly detailed at that. I make it a point on an upgrade and especially a migration/upgrade that is transitioning to a new apps system to at least see if something may cause an issue with my systems. If a person chooses to not at least skim the release notes and understand how a new feature covered may affect their system, then whose fault is that? Ix for not providing a bunch of bells and whistles that will be clicked through anyway just like the checkbox to save the password seed is all the time?
Please point to any documentation that details how and why user data in ix-applications dataset was moved/copied/hidden. I still don’t know the official story, or what the official stance on backing up app data is supposed to be.
I was only referring to the ixapplications dataset which is the config data. This data does not migrate back from docker to K8s.
The hostpath data is unimpacted and can migrate backwards.
The migration process was disclosed early for Community testing and the snapshot/clone process resolved then. TrueNAS SCALE Electric Eel "Call for App Testing"
In general, that process is transparent for users, but was particularly needed for testing. Only the early testers of a software version can have an impact on how the software operates and whether any improvements to a process are needed. Please get involved early to ensure your requirements are met. After that its add Feature Reguests for future releases.
1 Like
This backup topic would be a good topic for a new forum thread in the General channel or “Apps and Virtualization.”
The migration process for Apps was described in the Call for testing. TrueNAS SCALE Electric Eel "Call for App Testing"
Is someone else facing this issue?
TrueNAS @ truenas
New alerts:
SMB shares have path-related configuration issues that may impact service stability: StoragePool: ACL type mismatch with child mountpoint at /mnt/StoragePool/SSDPool_Backup/ix-apps: StoragePool - NFSV4, StoragePool/SSDPool_Backup/ix-apps - POSIX, StoragePool: ACL type mismatch with child mountpoint at /mnt/StoragePool/SSDPool_Backup/ix-apps/app_configs: StoragePool - NFSV4, StoragePool/SSDPool_Backup/ix-apps/app_configs - POSIX, StoragePool: ACL type mismatch with child mountpoint at /mnt/StoragePool/SSDPool_Backup/ix-apps/app_mounts: StoragePool - NFSV4, StoragePool/SSDPool_Backup/ix-apps/app_mounts - POSIX, StoragePool: ACL type mismatch with child mountpoint at /mnt/StoragePool/SSDPool_Backup/ix-apps/docker: StoragePool - NFSV4, StoragePool/SSDPool_Backup/ix-apps/docker - POSIX, StoragePool: ACL type mismatch with child mountpoint at /mnt/StoragePool/SSDPool_Backup/ix-apps/truenas_catalog: StoragePool - NFSV4, StoragePool/SSDPool_Backup/ix-apps/truenas_catalog - POSIX
This come from a previous replication task, running from core
Suggest you start a new thread to discuss. Best to describe your upgrade path and how ix-apps was backed up with Core.
1 Like