Unraid OS version 6.12.4 available

[unCoreX]

18 minutes ago, JorgeB said:

See the release notes, with v6.12.4 you don't need bridging to run VMs.

I'm gonna give 6.12.4 another shoot later. First time I run into some problems, i have posted in the bug reports. So I had to revert back to 6.12.3.

[nka]

On 9/9/2023 at 6:56 PM, meep said:

updated to 6.12.4 as 6.12.3 was hard crashing every few days. (6.12.2 before it lost me days tracking down some kind of plugin corruption).

Does 6.12.4 still crashing? I reverted back to 6.11.5 because 6.12.2 was freezing all the time.

[ConnerVT]

9 hours ago, JorgeB said:

See the release notes, with v6.12.4 you don't need bridging to run VMs.

 

Correct, you don't need bridging to run a VM.  But the question here is (which will help the person you replied to as well as myself):

 

With 6.12.4, macvlan, and no bridging, how do you access the VM from outside of the Unraid dash board? 

 

There does not seem to be an identifiable IP address which can be seen on the same subnet which the LAN network is configured (192.168.122.0/24 vs 192.168.1.0/24 for the LAN). 

[ljm42]

9 minutes ago, ConnerVT said:

Correct, you don't need bridging to run a VM.  But the question here is (which will help the person you replied to as well as myself):

 

With 6.12.4, macvlan, and no bridging, how do you access the VM from outside of the Unraid dash board? 

 

There does not seem to be an identifiable IP address which can be seen on the same subnet which the LAN network is configured (192.168.122.0/24 vs 192.168.1.0/24 for the LAN). 

 

As far as the VM is concerned, it works exactly the same whether it is on the bridge network or the macvtap network.

 

The VM template assigns the VM a mac address, and the VM can use that to get a DHCP address from the router, or the VM can assign itself a static IP. Unraid is not and has never been directly involved in the IP assignment for a VM.

 

As mentioned in the release notes, make sure the VM template is set to vhost0 and not br0.  And make sure Host access to custom networks is enabled (assuming you want that)

[ljm42]

6 hours ago, nka said:

Does 6.12.4 still crashing? I reverted back to 6.11.5 because 6.12.2 was freezing all the time.

 

Fixes for call traces and crashes related to macvlan are the main reason for this release. A config change is needed, you'll want to read the release notes for details.

[nka]

12 hours ago, ljm42 said:

 

Fixes for call traces and crashes related to macvlan are the main reason for this release. A config change is needed, you'll want to read the release notes for details.

Not sure mine were releated to macvlan, but I'll try again.

[meep]

On 9/10/2023 at 8:52 AM, JorgeB said:

This is not a common or known issue, you should start a new thread on the general support forum and post the diagnostics. 

 

On 9/10/2023 at 12:20 PM, Zonediver said:

 

Maybe a hardware-problem? Cache-SSD? New? Old?

Some more infos...

 

On 9/11/2023 at 5:52 PM, nka said:

Does 6.12.4 still crashing? I reverted back to 6.11.5 because 6.12.2 was freezing all the time.

 

Shares came back after a reboot, but significant issues persist.

 

I've made an issue thread. 6.12.4 is crashing much more frequently, than 6.12.3 was (hourly rather than daily). 
 

 

Edited September 13, 2023 by meep
clarification

[Ether Wrangler]

On 9/8/2023 at 5:26 PM, Ether Wrangler said:

 

I'm still getting what appear to be macvlan call traces after applying this.  The odd thing is, I set the network type to ipvlan in 6.12.3 and if I check the docker networks there isn't even a macvlan network.

 

NETWORK ID     NAME       DRIVER    SCOPE
68ad20afc8e2   bridge     bridge    local
a7904065acfc   host       host      local
85c9f1a91a4e   none       null      local
a66a6a6c0090   proxynet   bridge    local

 

tower-diagnostics-20230908-1718.zip 149.46 kB · 1 download

 

 

I think I finally got this fixed.  I'm still not sure why I was getting the traces with no macvlan docker networks, but I saw the comment about disabling bridging as its not needed anymore with the macvtap  device that will be created.  I turned off bridging on the NIC and have made it 2 days with no traces.  Before this I was getting multiple every day with hard locks of the OS at least every 2 days.

Edited September 13, 2023 by Ether Wrangler

[nka]

I just want to say that I've upgrade to 6.12.4 from 6.11.5 and it has been stable for me (6.12.2 was freezing every day, I do have 1 days and 6 hours now).

 

Processus was :

- Take note of all IP of Dockers using br0 (already have them, but just in case).

- Disable Dockers.

- Disable Network Bridge in Network Setting.

- Back to Dockers settings to change from macvlan to ipvlan.

- Enable Docker (and let them start).

- Update all br0 dockers to eth0 (or VLAN) and set old IP again.

- Disable Docker.

- Update to 6.12.4.

- Reboot.

- Enable Docker.

 

Thanks!

[ljm42]

5 hours ago, nka said:

I just want to say that I've upgrade to 6.12.4 from 6.11.5 and it has been stable for me (6.12.2 was freezing every day, I do have 1 days and 6 hours now).

 

Processus was :

- Take note of all IP of Dockers using br0 (already have them, but just in case).

- Disable Dockers.

- Disable Network Bridge in Network Setting.

- Back to Dockers settings to change from macvlan to ipvlan.

- Enable Docker (and let them start).

- Update all br0 dockers to eth0 (or VLAN) and set old IP again.

- Disable Docker.

- Update to 6.12.4.

- Reboot.

- Enable Docker.

 

Thanks!

 

Glad you are up and running! One thing I will say for anyone following along, I'd recommend updating to 6.12.4 first, before making any changes to the Docker config. The new settings have no effect on older releases so there is no added value in changing things before upgrading.

 

Also, if your goal is to use IPVLAN then don't disable bridging. When you disable bridging the system uses a macvtap network with macvlan, which was the main reason for the 6.12.4 release : ) 

[Rommel]

Updated today and I noticed that GPU Stats plugin use to detect my Arc A750 on 6.12.3, however on 6.12.4 it can only detect my Intel iGPU.

[unCoreX]

1 hour ago, Rommel said:

Updated today and I noticed that GPU Stats plugin use to detect my Arc A750 on 6.12.3, however on 6.12.4 it can only detect my Intel iGPU.

Make sure you have booth GPU selected in the GPU Statistics.
 

 

In the Dashboard:

[Thai]

Has anyone had their ZFS cache pool crash after upgrading? 

 

After upgrading, the two drives wouldn't mount and one drive would say "mounting" but never would.  The other cache drive wouldn't reattach to the cache pool.  In a jetlagged panic, I formatted the second drive.  Realized that was a dumb move since I didn't know the root cause, so I took a step back.  Now the system is saying that there's corruption on the drive that won't mount, but it will let me add that formatted drive back into the pool (not that it helps me at all, lol.)

 

Has anyone seen this?  Anything I google just leads me back to some ZFS issues, but this appeared after the update so not sure if it's related somehow.  Gonna do a memtest right now just in case.

Thanks in advance!

unraid-diagnostics-20230926-2233.zip

[JorgeB]

3 hours ago, Thai said:

but this appeared after the update so not sure if it's related somehow.

Very unlikely that this is upgrade related, the zfs pool is online so you need to manually export it first:

zpool export cache_zfs

Then start the array, go to the pool and click "clear" then "scrub", if there any errors after the scrub please start a new thread in the general support forum and post new diagnostics.

[shaunvis]

On 9/13/2023 at 2:44 PM, nka said:

I just want to say that I've upgrade to 6.12.4 from 6.11.5 and it has been stable for me (6.12.2 was freezing every day, I do have 1 days and 6 hours now).

 

Processus was :

- Take note of all IP of Dockers using br0 (already have them, but just in case).

- Disable Dockers.

- Disable Network Bridge in Network Setting.

- Back to Dockers settings to change from macvlan to ipvlan.

- Enable Docker (and let them start).

- Update all br0 dockers to eth0 (or VLAN) and set old IP again.

- Disable Docker.

- Update to 6.12.4.

- Reboot.

- Enable Docker.

 

Thanks!

 

You'd think if you had to do all that just to install an update, there'd be a flashing sign, warnings, message you have to acknowledge, or maybe something to guide you through the process instead of a simple "Click to update" and then have your server crash constantly. Especially when the release notes for 6.12.4 say most of these things are no longer an issue

[ultimz]

Upgraded from 6.11.5 to 6.12.4 - was pretty seamless. Just had to reinstall 2 plugins (gpustat and NUT) and also change docker to use ipvlan as it picked up a few traces.

 

Thanks to all the devs for their hard work. Appreciated!

[ByteHeaven]

Rolling back on trouble shooting. WebGUI is unusable because every load of page takes tens of seconds...

 

and troubles are gone.. webgui responsive again, page loads in fractions of seconds. Don't know what but something on this update is broken. And it is not immidiate (I updated already a while ago pretty soon after release of this version, troubles started within a few days ago, first slowing down, crash, docker did not start after forced reboot and was reseted on settings to default 20Gb docker image size etc. Then every screen load takes seconds to tens of seconds, including login screen. Docker though and docker apps works perfectly, same with NFS share...

 

 

Waiting next update then.

 

Edit: found later that cause of trouble was Unraid-api-re, Testing this version again later, when sure that it is ok.. (need it for shutting down the Unraid remotely with HA when electricity price hikes). Hope there would be in built ways to control this with HA at some point without any "hacks"

Edited October 3, 2023 by ByteHeaven

[Kilrah]

12 hours ago, ByteHeaven said:

Rolling back on trouble shooting. WebGUI is unusable because every load of page takes tens of seconds...

 

and troubles are gone.. webgui responsive again, page loads in fractions of seconds. Don't know what but something on this update is broken.

No, it's unraid-api-re, the thread for which you have posts in that has been killing your UI.

Edited October 3, 2023 by Kilrah

[ByteHeaven]

Yes, found out it later after writing this. Sorry for first thinking there was something weird under the hood in this version causing this. (was still looking info after writing the post)

[dnoyeb]

Just wanted to chime in after running this release since it came out.  I was crashing every few days and getting concerned I had issues with ram or cpu..  then this release came out and viola!  No more crashes (knock on wood).  

 

I do remember seeing some macvlan errors from time to time, and now it's all gone. 

 

Thanks so much for this release and the fixes.  

[johnieutah]

Been away from Unraid for quite a while and am still way back on 6.10.3.

 

Is there anything in particular I need to pay attention to with this update?I did see there was mention of Fritzboxes and Ubiquiti equipment, both of which I run.

 

Thanks!

[jpowell8672]

2 hours ago, johnieutah said:

Been away from Unraid for quite a while and am still way back on 6.10.3.

 

Is there anything in particular I need to pay attention to with this update?I did see there was mention of Fritzboxes and Ubiquiti equipment, both of which I run.

 

Thanks!

Run Tools > Update Assistant first then follow release notes upgrade procedure:

 

Version 6.12.4 2023-08-31

Upgrade notes

Known issues

Please see the 6.12.0 release notes for general known issues.

Rolling back

Before rolling back to an earlier version, it is important to ensure Bridging is enabled:

Settings > Network Settings > eth0 > Enable Bridging = Yes

Then Start the array (along with the Docker and VM services) to update your Docker containers, VMs, and WireGuard tunnels back to their previous settings which should work in older releases.

Once in the older version, confirm these settings are correct for your setup:

Settings > Docker > Host access to custom networks

Settings > Docker > Docker custom network type

If rolling back earlier than 6.12.0, also see the 6.12.0 release notes.

Fix for macvlan call traces

The big news in this release is that we have resolved issues related to macvlan call traces and crashes!

The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report.

If you are getting call traces related to macvlan, as a first step we recommend navigating to Settings > Docker, switch to advanced view, and change the "Docker custom network type" from macvlan to ipvlan. This is the default configuration that Unraid has shipped with since version 6.11.5 and should work for most systems. If you are happy with this setting, then you are done! You will have no more call traces related to macvlan and can skip ahead to the next section.

However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode.

For those users, we have a new method that reworks networking to avoid issues with macvlan. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution

Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)

Settings > Docker > Host access to custom networks = Enabled

Note: if you previously used the 2-nic docker segmentation method, you will also want to revert that:

Settings > Docker > custom network on interface eth0 or bond0 (i.e. make sure eth0/bond0 is configured for the custom network, not eth1/bond1)

When you Start the array, the host, VMs, and Docker containers will all be able to communicate, and there should be no more call traces!

Troubleshooting

If your Docker containers with custom IPs are not starting, edit them and change the "Network type" to "Custom: eth0" or "Custom: bond0". We attempted to do this automatically, but depending on how things were customized you may need to do it manually.

If your VMs are having network issues, edit them and set the Network Source to "vhost0". Also, ensure there is a MAC address assigned.

If your WireGuard tunnels will not start, make a dummy change to each tunnel and save.

If you are having issues port forwarding to Docker containers (particularly with a Fritzbox router) delete and recreate the port forward in your router.

To get a little more technical...

After upgrading to this release, if bridging remains enabled on eth0 then everything works as it used to. You can attempt to work around the call traces by disabling the custom Docker network, or using ipvlan instead of macvlan, or using the 2-nic Docker segmentation method with containers on eth1.

Starting with this release, when you disable bridging on eth0 we create a new macvtap network for Docker containers and VMs to use. It has a parent of eth0 instead of br0, which is how we avoid the call traces.

A side benefit is that macvtap networks are reported to be faster than bridged networks, so you may see speed improvements when communicating with Docker containers and VMs.

FYI: With bridging disabled for the main interface (eth0), then the Docker custom network type will be set to macvlan and hidden unless there are other interfaces on your system that have bridging enabled, in which case the legacy ipvlan option is available. To use the new fix being discussed here you will want to keep that set to macvlan.

 

https://docs.unraid.net/unraid-os/release-notes/6.12.4/#:~:text=This release resolves corner cases,properly shut the system down.

[greenflash24]

Is there currently any way for using an existing zfs pool with native zfs encryption as an Unraid pool, or does it have to be formatted?

 

If not, is Unraid planning to add support for native zfs encryption?

[JorgeB]

4 minutes ago, greenflash24 said:

Is there currently any way for using an existing zfs pool with native zfs encryption as an Unraid pool

It's not supported at the moment.

[greenflash24]

13 minutes ago, greenflash24 said:

Is there currently any way for using an existing zfs pool with native zfs encryption as an Unraid pool, or does it have to be formatted?

 

8 minutes ago, JorgeB said:

It's not supported at the moment.

That's very unfortunate.