It would be good to also have the ability to remove ophaned container volumes/images if I did not remove it when I deleted the container. (cleanup unused container volumes/images)
Like it is available in protainer.
It would be good to also have the ability to remove ophaned container volumes/images if I did not remove it when I deleted the container. (cleanup unused container volumes/images)
Like it is available in protainer.
Despite a lot of positive reactions here, I would like to note that IMHO the release is not as ready as suggested
And I am not talking about apps and containers, but âjustâ related to standard NAS functionallity and VMâs.
Yesterday I decided to try RC2 on my NAS (3 pools and some VMâs using VLANâs). I am NOT using apps !!
What ever seeing that I did not know how fast to switch back. Good news is that reinstalling the formal release and loading the config backup did bring up the NAS withing something like 1,5 hour. Note that I was very glad that I did have physical access to the NAS.
So, I assume that there is significant important improvement related to appâs, but calling this release RC2 ⌠Not in my opinion !
The details here are really thin. Without more data hard to say what the issue might have been. What does âGUI Changed and not OKâ even mean?
Kris,
Let me try to describe what I saw. But note that I all ready switched back after something like a hour.
The Dashboard GUI did show lots, I thing about 10 (extra!?), of empty âsub screensâ related to network and pools. I did start repairing the empty sub screens (which was possible) and removing others. Perhaps I could have created a ^workable^ dashboard. I did open / check all / the other screens / menuâs.
After doing some dashboard corrections, I did decide to check if my VMâs where accessible ⌠They where not!
At that moment I did decide to stop and switch back.
Note that:
Normally I am quite willing to test a release candidate. However I was already very very doubt full given what I has read about remaining network issues.
And this experience makes me even more care-full. It is a big home NAS and I must not think about loosing it !!
So that makes that I am very very cautious of doing further testing.
The empty Dashboard Tiles are part of the new, more individually configurable dashboard, so not a bug. I would however argue that the new tiles should auto populate if they were already present in Dragonfish. My second network Tile and all Info Tiles for the Data pools were empty and i had to configure them for them to work.
The listen to 0.0.0.0 was a bug with the new docker apps system, so it should not be a problem for you if you donât use apps, and afaik the problem was fixed a couple of days later with RC2
My experiences are related to RC2.
Note that what I saw, especially what I think is network behavoir, is reason not to do further testing. GUI thinks are less of a concern.
What ever I would be willing to share the actual config file with âtruenas developersâ if interested, but not with the community of course. Perhaps I will do another try with RC3
Choose your previous boot environment from the boot environments menu.
Iâm testing pre-release software at my own peril, of course, but I have to say Iâm really disappointed in my upgrade experience from 24.04.2.2 to 24.10-RC.2.
The two official apps I had installed, Pihole and Nextcloud, have just completely vanished from the Apps page. It looks like Iâll have to re-do them from scratch, which is quite some amount of work. Bleh.
Is there a way to somehow invoke migration manually?
Its in the release notes:
midclt call -job k8s_to_docker.migrate <poolname>
Thanks kris.
I ran this, sadly to no results.
I think my situation may be a dupe of this ticket: TrueNAS - Issues - iXsystems TrueNAS Jira
My TrueNAS Mini X was using that Pihole app for DNS resolution, i.e. the configured nameserver IP was the IP of the system itself. That probably somehow broke the auto-migration.
I think it would be good to catch this w/ a warning.
Iâve set the nameserver to 8.8.8.8 for now, before I ran the above command you suggested. Also app service is running, catalog is refreshed. Yet nothing âŚ
Anything interesting in the file /var/log/app_migrations.log
after running that command?
Hang on, exciting news! Following a reboot and another run of the command, the manual migration job is now busy doing its thing. Iâll edit this comment with the results in a bit.
Until then, thanks already - whatever disappointment I felt is more than offset by the helping hand (and in retrospect, maybe I shouldâve been smart enough to change the nameserver before the upgrade, given I made my system dependent on an app I knew had to be rejiggered).
Great to hear! That it was that simple to resolve!
Hereâs the results:
[2024/10/10 19:35:33] (DEBUG) app_migrations.migrate():225 - Migration details for âsystem-updateâ2024-10-10_17:02:56â backup on âdataâ pool
[2024/10/10 19:35:33] (DEBUG) app_migrations.migrate():228 - âpiholeâ app migrated successfully
[2024/10/10 19:35:33] (DEBUG) app_migrations.migrate():231 - ânextcloudâ app failed to migrate successfully: âFailed to deploy app: [EFAULT] Failed âupâ action for ânextcloudâ app, please check /var/log/app_lifecycle.log for more detailsâ
Pihole migrated successfully, but seems to have somehow lost its password settings. Iâm still trying to fix that, somehow the usual pihole -a -p
is not taking.
Nextcloud failed to migrate due to a problem with the CIFS mount:
Error response from daemon: error while mounting volume â/mnt/.ix-apps/docker/volumes/ix-nextcloud_cifs_bc44dff127161de2adceccf090d44b1319498faad189a5c0f8f22dbbc449cc26/_dataâ: failed to mount local volume: mount //192.168.178.130/shared:/mnt/.ix-apps/docker/volumes/ix-nextcloud_cifs_bc44dff127161de2adceccf090d44b1319498faad189a5c0f8f22dbbc449cc26/_data, data: user=eike,password=********: permission denied
Not sure why that would have stopped working, Iâll dig into it more.
Unfortunately Iâve not been able to make progress. The SMB/CIFS shares themselves seem to work fine as before. Is there any known problem with SMB mounts into apps currently?
Edit: In the meantime Iâve worked around this by installing smbclient inside the application image and using Nextcloudâs SMB/CIFS External Storage feature instead of TrueNAS mount + Local.
Release Candidates are there for a reason⌠to find bugs before production users find them.
Our preference is that if something like a bug is found, we start with a separate thread describing this issue. If its a config related cause the community may be able to help. If not, report a bug on each separate issue. We do prefer that the system is in a state where we can diagnose the issue and test any fixes.
The Release version is on track for end of the month⌠with 100+ fixes/changes. That will be suitable for early adopters who want specific features. In the meantime, most users should stay on 24.04.2 which has had the crap beaten out of it.
Moved my primary over to RC2 from Dragonfish, hit the docker limit, but changed the IP address to continue the migration no problem.
The improvements for apps I/O can not be understated from k8s. It is literally night/day different on IOwait time!
I just tried to create a custom app with a docker compose file (minidlna example from here Setting up minidlna as a docker container, path to media dataset adjusted accordingly). This works and the app is starting.
However, I cannot edit it. Instead, I get âerror detected reading appâ.
Does someone else know this problem?
I had created a custom app for vscode server after migrating to RC1 or RC2 (canât remember which). It runs fine, and I can stop and start it, but if I try to edit it, I get âError detected reading App.â I vaguely remember something about this, but I canât remember specifics. Do I need to get the compose file and then delete and recreate it? If so, where is that stored? I need to add another volume mount to it. Edit: looks like the poster right above me hit the same issue.
Edit2: The compose file was in /mnt/.ix-apps/app_configs/code-server/versions/1.0.0/templates/rendered
, if anyone else needs that info.