jpowell8672

Members
  • Posts

    379
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by jpowell8672

  1. 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
  2. 12 minutes ago, pervel said:

    I just got two Samsung 870 QVO 2.5" SSD and set them up in a new pool. I'm just curious if the trim function will be run automatically on the new pool just like on the original cache pool? Or do I have to do something special to trigger it?

     

    Also, they are set up in a BTRFS raid1. Will trim be performed on both drives?

    No need to trim any btrfs pool since it uses the discard=async mount option

     

    • Thanks 2
  3. 14 minutes ago, hawihoney said:

     

    What's that?

     

    If you have the fix common problems plugin installed which most do and is good to have then you will have a Update Assistant under the tools tab which is:

    Update Assistant

    This script is part of Fix Common Problems

    These tests, while not definitive will give you recommendations on what you should do prior to updating your unRaid OS. The tests are run against what the available update for unRaid expects and/or wants.

    There may also be perfectly valid use-cases for any issues that this script finds.