SCALE 22.02-RC.2 Now Available

[truecharts]

I'm very new to Truenas and Scale so forgive me if this is basic, but having patched plex 3 times now in 3 days I think, i seem to have 3 docker images for it in the 'manage docker images' tab, is that normal, do i need to manually delete the older numbered two?

View attachment 52323

Those weird double-named tags are a known bug, fix already made for the next release:

NAS-114031 / 22.02 / Correctly use tag reference when updating chart release images by sonicaj · Pull Request #8083 · truenas/middleware

When we have a chart release consuming an image like nextcloud:23, if we normalize the tag, we have something like registry-1.docker.io/library/nextcloud:23 which is how it's resolved internally by...

github.com

 

[JohnnyD]

Those weird double-named tags are a known bug, fix already made for the next release:

NAS-114031 / 22.02 / Correctly use tag reference when updating chart release images by sonicaj · Pull Request #8083 · truenas/middleware

When we have a chart release consuming an image like nextcloud:23, if we normalize the tag, we have something like registry-1.docker.io/library/nextcloud:23 which is how it's resolved internally by...

github.com

Can I delete the two old ones safely?

 

[truecharts]

Can I delete the two old ones safely?

try:
docker image prune -a -f --filter "until=24h"

 

[derWalter]

We've just build an automated patcher to apply the required fixes from Nightly :)

Code:

curl -s https://truecharts.org/rc2patcher | bash

thanks for that awesome move of you guys!!!

 

[manzomanze]

I also noticed that /sbin/zfs list process is using a lot of cpu over 70% after update and after using the fix

We've just build an automated patcher to apply the required fixes from Nightly :)

Code:

curl -s https://truecharts.org/rc2patcher | bash

but i am not sure if it was already present before the fix, i did not notice it before

 

[truecharts]

I also noticed that /sbin/zfs list process is using a lot of cpu over 70% after update and after using the fix

but i am not sure if it was already present before the fix, i did not notice it before

That's not going to be related.
ZFS is not touched.

ZFS resource spikes are pretty normal.

 

[HITMAN]

try:
docker image prune -a -f --filter "until=24h"

Worked like a charm !
Thanks :D

 

[HITMAN]

Apps page is quite slow now :( Apps itself are not slow just the operations from TN gui.

 

[truecharts]

Apps page is quite slow now :( Apps itself are not slow just the operations from TN gui.

See above for our patch for that.

 

[HITMAN]

Thank you, apps page working faaar better now :D

 

[Patrick M. Hausen]

See above for our patch for that.

This one?

NAS-114031 / 22.02 / Correctly use tag reference when updating chart release images by sonicaj · Pull Request #8083 · truenas/middleware

When we have a chart release consuming an image like nextcloud:23, if we normalize the tag, we have something like registry-1.docker.io/library/nextcloud:23 which is how it's resolved internally by...

github.com

Because the description does not say anything about performance issues. Thanks for clarifying!

Related (I hope) question: the Apps UI offers me updates to my installed Apps quite frequently, sometimes every other day in a row. Yet there seems to be no update to the application itself. TrueCommand is still not at 2.1 for example. What is happening here?

 

[truecharts]

Related (I hope) question: the Apps UI offers me updates to my installed Apps quite frequently, sometimes every other day in a row. Yet there seems to be no update to the application itself. TrueCommand is still not at 2.1 for example. What is happening here?

No our actuall patcher for THIS release.
This one:

We've just build an automated patcher to apply the required fixes from Nightly :)

Code:

curl -s https://truecharts.org/rc2patcher | bash

---

Related (I hope) question: the Apps UI offers me updates to my installed Apps quite frequently, sometimes every other day in a row. Yet there seems to be no update to the application itself. TrueCommand is still not at 2.1 for example. What is happening here?

You seem to be confusing Apps, Containers and Applications.
Apps contain Helm charts, install scripts basically.
They reference containers, which include applications.

All of those three are combined when we push App updates.
There are release notes included for all (or at least most) of our updates.

 

[Geek Baba]

Are you using the Intel 520 card? I have the exact same error. I tried bare metal install after frustration under Hyper-V with spam errors I couldn't identify. At least I found someone potentially in the same boat.

Based on the model SuperServer 2028U-TN24R4T+ the chipset is Intel® X540 10GBase-T.

@Kris Moore should I open a bug or providing details here was enough? Looks like intel cards are having issues.

 

[truecharts]

@Kris Moore should I open a bug or providing details here was enough? Looks like intel cards are having issues.

Reported bugs here are generally not even worked on. You always need to file a bugreport.

 

[Jowie]

Tried to upgrade from TrueNAS CORE 12.0-U8 to TrueNAS SCALE 22.02-RC.2, and am stuck. "middleware is not running. Press Enter to open root shell.". Saw some threads about this issue with previous releases of SCALE, but when I checked the dmi.py file, seems the fix is already there.

dmidecode output:

I've rebooted several times, and also tried to boot the previous TrueNAS CORE install which was working great, and it reboots itself.

I'm a freebsd/linux noob, so not sure where to go next. I did save my configuration from CORE and could always reinstall that and restore my config, but wondering what I should grab to report this bug.

Thanks!

 

[Jowie]

Tried to upgrade from TrueNAS CORE 12.0-U8 to TrueNAS SCALE 22.02-RC.2, and am stuck. "middleware is not running. Press Enter to open root shell.". Saw some threads about this issue with previous releases of SCALE, but when I checked the dmi.py file, seems the fix is already there.

dmidecode output:
View attachment 52827

I've rebooted several times, and also tried to boot the previous TrueNAS CORE install which was working great, and it reboots itself.

I'm a freebsd/linux noob, so not sure where to go next. I did save my configuration from CORE and could always reinstall that and restore my config, but wondering what I should grab to report this bug.

Thanks!

Screenshots and errors during boot:

Running the systemctl status commands didn't reveal anything too helpful to me, but happy to send along that output if needed.

 

[Jowie]

Screenshots and errors during boot:
View attachment 52829
View attachment 52830
View attachment 52831
Running the systemctl status commands didn't reveal anything too helpful to me, but happy to send along that output if needed.

Guessing that the issue is it seems I'm not getting IP address on my NICs:

Not sure how to fix this upon first boot of the install of TrueNAS SCALE. Anyone have any suggestions?

 

[Dosch]

Guessing that the issue is it seems I'm not getting IP address on my NICs: View attachment 52832
Not sure how to fix this upon first boot of the install of TrueNAS SCALE. Anyone have any suggestions?

Same issue here - via dhclient or manual configuration of the interface the network connection issue can be fixed (resolv.conf and interface-configuration file has to be created, otherwise settings will be lost at reboot). But i didn't manage to get a reboot on which the middleware is starting properly. Hostname is also lost.

In addition the walinuxagent is permanently generating errors.

During boot the ix-update-service is failing aswell, seems the startup procedure is not waiting for network connection. If Trying to start the Middleware manually a couple of errors occur:

 

[Dosch]

Seems to be fixed within the latest nightly build from feb 6th.

Just trying network configuration via Truenas Shell results in errors - if creating an interface configuration file within /etc/netwok/interfaces.d/ it works fine.

 

[nitromethane]

Hi all, new guy here.

I've been running TrueNAS SCALE since beta (also True/FreeNAS for some years now), and it has been a mostly reliable experience.

The problem I'm having right now, is that the Web UI storage page is painfully slow when trying to delete a dataset. I have just spent about 8,5 minutes (yes that long) watching a spinning circle between clicking "delete dataset" and the confirmation dialog opening up.

While waiting, I SSH-ed in to the server to see what htop has to say, and one "middlewared" process was hammering the CPU at 100% the entire time. I'm running an old AMD FX processor but I don't think it should be that slow. RAM usage was nothing special.

Now that the system is idling the "middlewared" process pins the CPU for a second or two every now and then.
Also "k3s server" process CPU usage consistently fluctuates around about 25%.

Is this a known problem?
Do you experts have any sudgestions no what I should try and/or take a look at next?