Unraid OS version 6.12.3 available

[ConnerVT]

Thanks for the quick reply.  Was second guessing myself, wondering maybe I *did* have it set to Latest before.

 

Wasn't much of a concern for me.  The GT710 is only in the system from when I first set up the server a few months back, and the Ryzen 1500X doesn't have a iGPU, so needed something to config the BIOS.  I agree the GT710 is almost worthless.  It's one strength is it is the cheapest GPU that allowed you to install Win10.  So it is the card in the drawer, when I need a card...  😉

 

I follow the Nvidia Driver thread, and know some folks have a need for not running the Latest driver version.  Just thought I'd give them a heads up to check after updating their OS.

[ich777]

6 minutes ago, Glassed Silver said:

If your plugin is that opinionated maybe you should provide information about that within it?

This is a bit hard since I don't know what card the users run and why? Users have maybe a reason to use such a card but they are from a efficiency standpoint really bad nowadays.

But the downloads from the legacy drivers are decreasing from release to release and the real reason why I don't want to do a "legacy" branch from the driver is that Nvidia could drop the legacy driver any time as they did with many things in the past.

 

All other branches will update properly even if you upgrade Unraid to a newer version.

 

6 minutes ago, ConnerVT said:

Just thought I'd give them a heads up to check after updating their OS.

Thanks!

[Glassed Silver]

2 hours ago, ich777 said:

This is a bit hard since I don't know what card the users run and why? Users have maybe a reason to use such a card but they are from a efficiency standpoint really bad nowadays.

But the downloads from the legacy drivers are decreasing from release to release and the real reason why I don't want to do a "legacy" branch from the driver is that Nvidia could drop the legacy driver any time as they did with many things in the past.

 

All other branches will update properly even if you upgrade Unraid to a newer version.

 

Thanks!

1) I think you misunderstood what I meant, my point is you should tell users that you fall back to latest.

 

2) As for the different point that Nvidia could drop legacy drivers anytime.... Sure... Then update the plugin to drop the channel?

 

In any case that wasn't even my point.

[stanger89]

7 hours ago, ich777 said:

For what applicaiton(s) do you need static IP address(es)?

 

I'd been having some major trouble with 6.12 (and slightly less after going back to 6.11), which I think seeing this thread is due to this.  First, I want to make sure I'm understanding correctly, with 6.12, we can't use macvlan (I switched to ipvlan), and because of that we can't setup dockers with br0 and a custom/fixed IP?

 

So assuming that is correct, then I have an issue/question.  I had been using custom IPs on a couple dockers, so I started reconfiguring my containers back to bridge and ran into an issue.  I have Plex and Jriver Media Center and both want port 1900 for UPnP.  Is there a way to get both working?

 

Either way, hoping this resolves my issues.

[bonienl]

Not correct. When using ipvlan it is still possible to set up containers on br0 with a fixed ip address. And this works correctly. I have about 10 containers running this way, including Plex.

 

 

[stanger89]

11 minutes ago, bonienl said:

Not correct. When using ipvlan it is still possible to set up containers on br0 with a fixed ip address. And this works correctly. I have about 10 containers running this way, including Plex.

 

 

Interesting, so what was it that we can't do with static IP addesses?  I really thought this might be my issue with my server going unresponsive with 6.12 after updating.

[Alyred]

38 minutes ago, stanger89 said:

Interesting, so what was it that we can't do with static IP addesses?  I really thought this might be my issue with my server going unresponsive with 6.12 after updating.

It's static/configurable MAC addresses you can't have, which are needed in some configurations (certain routers, reserved IPs mapped to MACs, etc).  Mapping to IPs works fine and IPVLAN works for most folks. I had to change one container that I was using a redefined MAC address to help spot new devices on my network when I changed it. No other issues (on that server, anyway).

[Glassed Silver]

At this point I'd already be happy seeing LimeTech publicly acknowledging the issue and communicating they are looking into it.

 

The status quo seems to be based on letting the community figure it out with a variety of workarounds and hacks which I find problematic at best and concerning at worst.

[safiedin]

cant afford a downtime. i think i pass this upgrade this time

 

sincerely

noob 😅

[sdballer]

This circumvents the "I have read checkbox" ... just fyi.

[faxxe71]

Update done from 6.11.5 to 6.12.3:

update all Apps and Dockers

disabled VM (have one running)

disabled Docker (21 always running)-i use ipvlan with few dockers on different ip in br0

backup from the boot stick

update and reboot properly

enabled the docker service and 21 dockers came up correctly

enabled the VM service and 1 VM starts correctly

 

Everything works flawless and its now up since 24h.

 

-faxxe

 

Edited July 17, 2023 by faxxe71

[Glassed Silver]

19 minutes ago, faxxe71 said:

Update done from 6.11.5 to 6.12.3:

update all Apps and Dockers

disabled VM (have one running)

disabled Docker (21 always running)-i use ipvlan with few dockers on different ip in br0

backup from the boot stick

update and reboot properly

enabled the docker service and 21 dockers came up correctly

enabled the VM service and 1 VM starts correctly

 

Everything works flawless and its now up since 24h.

 

-faxxe

 

Yeah, IPVLAN is fine, problem is that not for all of us that's a viable option.

 

LimeTech seems to like to pretend it is, unless they simply are too busy catching up with this mess and want to communicate betterment once they figured it out. Personally communication should come first, but sadly this is the kind of behavior I always feared to experience at some point down the line with a proprietary and commercial product that's based on community development and support so much.

 

Happy day when LT steers this ship around again, love unRAID regardless, but for a server OS this is becoming a bit of a sour tale.

[Kilrah]

1 hour ago, Glassed Silver said:

LimeTech seems to like to pretend it is, unless they simply are too busy catching up with this mess and want to communicate betterment once they figured it out.

That issue seems like a docker/kernel problem and LT likely cannot do anything about it on their own, relying on upstream to fix their stuff.

 

 

[Ford Prefect]

 

1 hour ago, Kilrah said:

That issue seems like a docker/kernel problem and LT likely cannot do anything about it on their own, relying on upstream to fix their stuff.

 

2 hours ago, Glassed Silver said:

Yeah, IPVLAN is fine, problem is that not for all of us that's a viable option.

 

To clarify things a bit, here. I think that the majority of users is fine with the comment from @Kilrah, but another group of users Is having a problem with the "LT approved" solution, which is using/switching to IPVLANs.

As stated by @Glassed Silver, the user group affected are the ones where their SoHo Router goes berserk with multiple IPs on the same MAC.

These are approx 90% of the German users, who are using an AVM fritzbox (which is the default router provided by all german ISPs).

Also I know of one user ( @warp760) , also from the German subforum, who reports the same Issue with a unify dream machine.

If some of the internationl users , running a unify router box, could confirm this issue, it hopefully might push up the priority for LT??  

 

P.S.: sorry for a bit of going OT here. RE v6.12.3, with all the various issues reported since v6.12 reaching GA, I am staying on v6.12RC2, which is running fine for me

 

[bonienl]

17 minutes ago, Ford Prefect said:

If some of the internationl users , running a unify router box

I have Unifi network gear and no issues.

 

For those who need macvlan, because ipvlan doesn't work for them (Fritz users), an alternative solution is to disable the bridge function of br0 and make it a plain eth0 interface. Disabling the bridge function is only applicable when no VMs are used using br0.

In the docker container settings, the network needs to be re-assigned to the custom-eth0 interface instead of the custom-brr0 interface.

 

We are collecting as much information as possible about the macvlan issue and are looking into getting the Linux kernel developers involved to find a solution. Rest assurred, we also want this issue to be solved.

 

[Ford Prefect]

15 minutes ago, bonienl said:

I have Unifi network gear and no issues.

The issue is only in the router, not other gear from unify. Even real VLANs work fine.

 

AFAIU the "issue" is with people using local network names for different "machines/dockers".  These routers "automagically collect" the different machines, based on MACs, not on IPs in their local DNS resolver / static table and once a new machine pops up in the network, people would assign it a proper name...now, where the static table gets messed up completely on a regular basis with ipvlan setups.

Edited July 17, 2023 by Ford Prefect

[Kilrah]

1 hour ago, Ford Prefect said:

These are approx 90% of the German users, who are using an AVM fritzbox (which is the default router provided by all german ISPs).

These users should also complain to AVM given they're one of very few providers having this problem.

[bonienl]

45 minutes ago, Ford Prefect said:

The issue is only in the router,

 

With "gear" I mean different equipment from Ubiquiti, including a router, the USG-Pro-4 in my case.

 

45 minutes ago, Ford Prefect said:

now, where the static table gets messed up

 

This is only a display thing. Connections work fine.

Unifi shows MAC addresses but does not further split out the table when multiple IP addresses have the same MAC address.

 

If it is a concern, why not report an issue to Ubiquiti?

 

[Ford Prefect]

54 minutes ago, Kilrah said:

These users should also complain to AVM given they're one of very few providers having this problem.

 

27 minutes ago, bonienl said:

If it is a concern, why not report an issue to Ubiquiti?

 

Well, that recommendation has already been given.

However, from a more distant view, it feels like the size of the problem on the side of AVM or ubiquity (or openWRT, who does the same thing) is too small, not speding up the process. Hence unraid users feel like Don Quixote, fighting the windmils 

As I am using mikrotik gear, I am not affected, but feel the pain of the others.

 

With the introduction of v6.12 the problem became more and more apparent to users, hence the initial discussion here.

But the problem is known since the move from macvlan to ipvlan had been introduced as the solution in unraid, I think.

So maybe we should take this discussion to another, dedicaded thread if need be.

[stanger89]

11 hours ago, Alyred said:

It's static/configurable MAC addresses you can't have, which are needed in some configurations (certain routers, reserved IPs mapped to MACs, etc).  Mapping to IPs works fine and IPVLAN works for most folks. I had to change one container that I was using a redefined MAC address to help spot new devices on my network when I changed it. No other issues (on that server, anyway).

Thanks for the clarification, unfortunately I'm still having issues, which I am documenting in my prior thread to not derail this one:

 

[takkkkkkk]

Just curious, what changed in 6.12 to cause this IPVLAN / macvlan  issue?? Also, why couldn't LT make IPVLAN the default if that's the workaround??

 

[wgstarks]

17 minutes ago, takkkkkkk said:

Just curious, what changed in 6.12 to cause this IPVLAN / macvlan  issue??

Actually I think it started with 6.11. I just upgraded to 6.12 yesterday but been getting callback trace warnings from FCP for this issue starting about 6 months ago while I was still on 6.11.

 

From what I have read there is some speculation that it’s a kernel problem but I don’t think anyone knows for sure. No real pattern so far.

[Titan84]

5 hours ago, Ford Prefect said:

If some of the internationl users , running a unify router box, could confirm this issue

Hi,

I'm Running IPVLAN with a UDM-PRO without any issues at all. Been running this way since 6.11.x. My Brother and friend also have a UDM-PRO with IPVLAN and no issues there either.

Edited July 17, 2023 by Titan84

[JorgeB]

20 minutes ago, wgstarks said:

Actually I think it started with 6.11.

The macvlan issues started with v6.5, though with each newer release it appears that more and more users are affected, which by itself is strange, since AFAIK nothing has been changed to cause that other than using newer kernels.

[Swarles]

Damn, not had any issues with 6.12.X thus far which has been great. I did happen upon this thread suggesting to stop the array and dockers prior to upgrading to 6.12.3...but unfortunately I completely forgot and rebooted before doing that. Unfortunately the upgrade/reboot process resulted in an unclean shutdown for me. Only time I have experienced that. Remember to do ALL the steps everyone!