I upgraded today from 24.10 to 25.04 and I can’t find my virtual machine anymore.
It was set to autostart, but it is also not started.
What can be the cause.
Update version 24.10 was Scale and 25.04 is community edition
Community = Scale.
Did you read the release notes before upgrading?
I have the same problem, importing the original vmdisk also cannot start, and I currently don’t know how to solve it
Hi Protopia,
As usual I didn’t read the release notes.
I did now and wa able to import my vm and make it running.
Thanks
I’m in the same boat. I migrated the VM using the instructions but I doesn’t boot. In the serial console, I can see it stay in the UEFI boot menu. From there I can access the bios, etc but I can’t get it to boot
Me to, as I wrote before.
I completely disagree with the simple answer ‘that you should have read the release notes’
And IMHO this version should never have been publisched as a release version. It is simply not ready for that status
When you stumbled into that, were you unable to revert to the previous boot environment?
If yes, what error did you get?
And you all provided ZERO relevant information. If you need help, at least tell people what OS is installed in your VM.
No information == No help
If you had read the release notes, you would have known that this is labeled as an experimental feature, and could have chosen to wait until the next release in the fall when it’s expected to be more feature-complete.
Let’s say you’re right.[1] That still doesn’t absolve you from the responsibility of reading the release notes–major releases often contain breaking changes, so upgrading without reading them is just foolhardy.
and I’m inclined to agree–iX removed the virtualization functionality they deemed production-ready (that never really was) and replaced with one they call “experimental.” ↩︎
When i|X removed Kubernetes and replaced it with Docker without capabilities of running Kuberneres and Docker in parallel - and they admitted to me that it would have been possible to do parallel running - they created incompatibility and did a full release “prematurely” and when TrueNAS told you there was a new release and told you to upgrade there were no warnings that you might have incompatible apps and no pre- upgrade migration test to check that there weren’t. As a consequence at the time this forum was FULL of reports of people upgrading too early and having problems.
The Docker solution is still not fully complete - as I understand it you still cannot have secondary IP addresses on your network cards for Docker use.
And with Fangtooth they have essentially repeated the same “mistakes” again, this time with VMs - no warnings, “premature” release etc.
However, the quotes around words above are intentional - because it depends on the perspective you look at it from. From iX systems perspective, the non-enterprise user base are beta testers to try all the obscure nooks and crannies of new technology and help iron out all the issues before their paying Enterprise customers upgrade and hit them. But non-Enterprise customers come with all levels of risk acceptance/avoidance - the truly adventurous try out the Nightly’s or the beta releases, the slightly less adventurous try the release-candidates, and (in principle) I have no problems with early adopters upgrading to the first full release when functionality is still incomplete and there are still bugs providing that they do so fully informed of the risks.
IMO this is part of the informal deal that the non-enterprise community has with iX. 1. iX produce functionality (typically around apps and virtualisation) that are very much what the non-paying community want but not of any high priority for paying Enterprise customers; and in return 2. the community acts as beta testers.
So in principle, I think this is a completely OK deal PROVIDING that they ensure that a user upgrading is fully informed about the issues they might face when upgrading - and IMO this should NOT only be release notes (and the Dragonfish release were very sub-standard in their warnings about TrueCharts apps) but also several warnings when TrueNAS offers you an upgrade:
-
“You are running TrueNAS Chart apps in Dragonfish and when you upgrade to ElectricEel these will be migrated to Docker apps. There may be some preparatory work you need to undertake - see the Release Notes for details.”
-
“You are running TrueNAS Chart apps in Dragonfish. Before undertaking the upgrade we ran a trial migration to check they would migrate OK and found the following issues: … Do you still want to upgrade?”
-
“You are running Chart apps from a 3rd Party catalogue in Dragonfish and when you upgrade to ElectricEel these will NOT be migrated to Docker apps. You need to record the details of these apps, research how you might create equivalent apps in Docker and plan to recreate these apps after migration - see the Release Notes for details.”
-
“This is the first full release of Fangtooth and there may still be bugs you might experience.”
-
“You are running VMs, and when you upgrade to Fangtooth you will need to manually update the drivers in your VMs to make them work again. See the Release Notes for details.”
etc. etc.
Umm…this would be covered by
It TrueCharts (a third party unaffiliated with iX) hadn’t been such a long-term cluster of crap (for reasons) there wouldn’t have been the same level of pressure to migrate in the first place.
You’re never going to reach all of the users who blast through or ignore warnings and just yolo it. Release notes are fine, just give a stern warning in the UI to read them, maybe even force a click through to the notes when switching trains. Also for component level changes like “apps” or “VMs” changing, an additional click-through warning.
I’d personally rather them invest time and resources into making the present feature complete than in writing migration compatibility checks.
I don’t think anyone migrated too early to EE, except for maybe some hopping on the beta out of desperation (and at that point you should just know the score…Migrating to Fangtooth “too early” is much more likely.
-
No - these are different messages - the first refers to the TrueNAS Chart apps by iX, the second to e.g. TrueCharts.
-
No - it is unfair to say that TrueCharts was unaffiliated with iX. iX had explicitly created the ability to use 3rd party catalogues and invited 3rd parties to create them, and TrueCharts decided to participate in this. Then, having encouraged them, and TrueCharts having invested time and effort, iX dumped 3rd party catalogues and Chart technologies and left TrueCharts high-and-dry. And TrueCharts then withdrew their catalogue and left their users high-and-dry. And iX didn’t publish the migration functionality to allow TrueCharts to migrate their users to Docker (even assuming that TrueCharts or the community wanted to do so).
That said, I used / use the TrueNAS Charts apps for my main apps (which were in both catalogues) and only used/use TrueCharts for minor apps.
I’d personally rather them invest time and resources into making the present feature complete than in writing migration compatibility checks.
They have a migration script – tweaking that to do a trial run wouldn’t have been that difficult. iX just chose not to do it.
I don’t think anyone migrated too early to EE, except for maybe some hopping on the beta out of desperation (and at that point you should just know the score…Migrating to Fangtooth “too early” is much more likely.
At the time I maintained a list of forum posts for people experiencing problems with their EE migrations - and it was a long list. I explicitly warned iX that they needed warnings in the UI before an upgrade, and that this would happen, but they were not (and are still not) interested in protecting naive users from upgrading without reading the release notes and doing prep work.
Unfortunately TrueCharts just sucked, and were a big part of what killed the old app infrastructure. The repeated breaking changes, some of which put user data at risk. Not following the (not adequately documented) specs of what iX considered to be supported technology, and essentially being at war TrueNAS over technical implementation details - unwilling/unable to actually target a catalog of TrueNAS apps that worked and recommending against TrueNAS well before the platform change.
TC’s ambition way outranged its ability to deliver. End users and iX (reputation hit, support headaches from people flooding the forums asking about a non-iX product) suffered the consequences.
No, it wouldn’t. “TrueNAS Chart apps” ≠ “TrueCharts apps.” The fact that some people can’t see past the word “chart” is their own problem.
That’s quite the novel retcon of the situation. The Docker zealots chanting “Docker, Docker, Docker” like Vikings in a crowded diner were telling us that all we need is Docker, and all the problems of k3s would magically go away (horror of horrors, the k3s daemon uses 10% of one core!). We’ve had about six months on Docker, and to the surprise of literally nobody with eyes in his head, that hasn’t happened.
iX’ statement was that writing Helm charts was just too hard for them. No doubt that’s why the unpaid team of volunteers at TrueCharts were able to come up with multiples more and better charts than anything the paid team at iX ever managed to produce. The reality is (IMO, of course) that iX just don’t care to put any real effort into developing or maintaining apps. Kris said as much with respect to the Helm apps, it was obvious this was the case with both implementations of plugins on FreeNAS/CORE, and I’ve seen no reason to believe their priorities have shifted.
If TrueCharts weren’t terrible, there would have been just a bit less uproar, and potentially more ability to placate that crew with jailmaker (and maybe even incus coming in sooner I guess)
I think more precisely…more time consuming to take software that often comes from the developer in the form of a docker compose tested on docker, port it to kubernetes, and validate that it works than there is to repackage software that’s distributed for docker to run on docker reliably.
Now that’s a retcon. It TrueCharts had been anything other than the disaster that knowledgeable users actively told newcomers to avoid if possible, because they rearchitect with breaking changes every few months things might have unfolded a bit differently. The ambition and level of opinionated control, constant rearchitecting, and data opacity were just…extremely mismatched from the use case of people who just want to run some apps on a NAS reliably.
That’s why the move to docker makes sense. The volunteer catalog option was a public image and stability disaster. Their own apps were fine enough but limited in number, and BYO with kubernetes wasn’t as simple as docker, but also not as powerful as e.g. an actual kubernetes cluster.
Right, and why I’ve really just wanted them to settle on an archictecture simple enough that they can more or less copy/paste upstream apps into their catalog…and then just run my own thing on top of it. The less that iX needs to do to manage app upgrades and lifecycles…the better it is for all.
That didn’t happen–not on any kind of regular basis, anyway.
Neither did that. Breaking changes driven by TC happened once. Breaking changes driven by iX’ having removed features from TrueNAS happened a second time. No breaking changes happened “every few months.”
As to (my claim of) TC’s apps being better, where was iX’ ingress integration? Homepage integration? VPN integration? Codeserver integration? Ability to manage TLS certs?
If they were so terrible, users could have used better charts. Oh, wait, there weren’t any. For nearly 90% of the apps TrueCharts provided, iX (including the “community” train) provided nothing. You blame TC for being terrible, but there was no alternative. There was a small catalog of apps from iX, and there was a large catalog of apps–which many users found to work much better and be much more featureful–from TC. Your conclusion that “better” (whatever you take that to mean) charts from TC would have done anything to mute the drumbeat of “Docker, Docker, Docker” is truly mystifying.[1] As you say, Jailmaker was already a thing; it did nothing to quiet them.
…but somehow TC managed to do it. For roughly 8x as many apps.[2] iX found it too hard because after the initial SCALE release, they stopped caring about creating apps–again, Kris said as much in the announcement thread about throwing k3s out the window. Of course something is “too hard” when you don’t care about doing it in the first place.
The problem is that iX needs to admit this. They’ve been advertising apps/plugins for 15 years. They’ve never, in that 15 years, devoted the resources necessary to keep even their limited catalog up to date, much less to expand it to a reasonable size. They’d come out with something, it’d be new and shiny for a while, and then they’d get bored with it. Lather, rinse, repeat. It’s for this reason that I have no confidence they’ll keep up this iteration of their apps catalog.
A surprisingly (to me, at least) large proportion of users don’t seem to want this at all, they just want an environment into which they can drop whatever Compose YAML they find. Maybe iX will settle on this. But it will be a loss if they do.
You can. Just not from the TrueNAS GUI, it involves shell commands, editing YAML files (e.g. from Dockge), or using Portainer (which is an official app).
Sure. I agree that more prominent warnings would be better.
But this does not exempt users from Reading the F(ine) Release Notes before updating. And the less tech savvy users should really refrain from updating to .0 or .1 releases and rather wait for .2 or .3 until changing train, after reading through the forum (and the Release Notes, of course).
You also can currently assign an IP in the TrueNAS UI for any apps added to the catalog after December 24 of last year. The development work to enable it for all apps is largely done and staged. The only delay is because enabling it for the older apps will be a breaking change for automatic migration from 24.04 to 24.10 and so we’re giving users a bit more time to make that transition, as outlined here.