Jump to content

Unraid OS version 6.12.4 available


ljm42

Recommended Posts

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.

Link to comment
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). 

  • Like 1
Link to comment
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)

  • Thanks 1
Link to comment
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.

Link to comment
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 by meep
clarification
Link to comment
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 by Ether Wrangler
  • Like 1
  • Upvote 1
Link to comment

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! :)

Link to comment
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 : ) 

Link to comment
  • 2 weeks later...

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

Link to comment
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.

  • Like 1
Link to comment
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

  • Upvote 1
Link to comment

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 by ByteHeaven
Link to comment
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 by Kilrah
Link to comment

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.  

Link to comment
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.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...