Unraid OS version 6.12.3 available

[bambi73]

Updated from 5.11.5 and everything is working fine (not using Plex). Only exception (expected 😄) is MACVLAN.

 

6 hours ago, bonienl said:

I have Unifi network gear and no issues.

 

I have Unifi too (UDM-Pro) and I wouldn't call state with IPVLAN as "no issues". It's working (great) but Unifi itself doesn't consider state of network as correct either (not so great):

• It occasionally complaints about multiple IPs assigned to single MAC in Admin messages
• In Client view my Unraid server show random IP address (probably last one updated in ARP table) and it's changing
• It messes statistics (and probably QoS too)
• Router is constantly (each 15sec) and unsuccessfully ARPING to IP addresses which aren't "main" at the moment (not sure if static ARP records will fix it because ARP table contains "correct" records)

Anyway it's good you are planning to involve kernel developers in the problem. Before you wrote this I intended to ask if there are some Linux kernel and/or Docker engine issues in their trackers (as I didn't find anything relevant). Was bit hopeful that recent (kernel 6.4) commits into macvlan.c will fix things.

Edited July 17, 2023 by bambi73

[Kilrah]

2 hours ago, takkkkkkk said:

Also, why couldn't LT make IPVLAN the default if that's the workaround??

It has been the default for new setups since 6.11...2 I think? But it's naturally not being auto-changed since that may need additional changes in people's setups.

[bonienl]

38 minutes ago, Kilrah said:

It has been the default for new setups since 6.11...2 I think? But it's naturally not being auto-changed since that may need additional changes in people's setups.

 

Since 6.11.4, see https://docs.unraid.net/unraid-os/release-notes/6.11.4

 

Only for new installations, existing installations (people upgrading) need to change manually.

 

[Terebi]

upgrade went ok. Go the docker stuck thing, I was unable to open up a terminal window to do the command.  After a while it must have rebooted itself. Started a parity check so it must have not been considered a graceful shutdown. 

 

had the pegged cpu problem for a bit, but only lasted like 5 min. 

 

still seeing problems with docker versions not available for upgrade checks 

[tucansam]

I've never seen this many X.X.y releases in a row in maybe forever.  Are the major releases not ready for prime-time before they're rolled out?

 

[Glassed Silver]

9 hours ago, tucansam said:

I've never seen this many X.X.y releases in a row in maybe forever.  Are the major releases not ready for prime-time before they're rolled out?

 

More eyes = more bugs found.

 

Beta tests and RCs are done by few people, gold releases are done by everyone except for the few who are cautious.

[Grobalt]

After a week with array on compressed ZFS ... i copy everything back to XFS. Huge cpu workload, nearly all time a core is 100% load, the copy speed is below 50 MB/s with 18TB enterprise SATA spindles (both write methods).

[tucansam]

"Plex AEA services" and scanning media has 16 cores at 95-100%...... I don't recall this ever happening before in previous versions of unraid.

[shredswithpiks]

On 7/16/2023 at 12:17 AM, Pete0 said:

Edit: I just saw that it actually is doing a parity check. I only didn't see it right away because of the new notification thing in the Web GUI. Great. This will take another 24 hours.

 

I just updated and the array went straight into a parity check. I doubt your issue is result of a power outage/dip/whatever.

But, docker and plex seem to be running without needing me to kick it with workarounds, so that's nice.

[1812]

upgraded 2 similar machines from .2 to .3 no issues except this is new: 

 

Jul 17 14:54:50 Tower1 smbd[24128]: [2023/07/17 14:54:50.767379,  0] ../../source3/lib/adouble.c:2363(ad_read_rsrc_adouble)
Jul 17 14:54:50 Tower1 smbd[24128]:   ad_read_rsrc_adouble: invalid AppleDouble resource .DS_Store

 

 

but I'm not that concerned about it at the moment because of the file type/what that does. I haven't had any file transfer issues (yet) will come back if it becomes a thing.

Edited July 18, 2023 by 1812

[tjb_altf4]

On 7/17/2023 at 9:35 PM, wgstarks said:

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.

I remember reading about macvlan crashes as far back as 6.9, for me it 6.10 upgrade that saw crashes appear.

[coldviber]

just me or a lot of ram use in this last version?

[Niklas]

Just now, coldviber said:

just me or a lot of ram use in this last version?

 

Normal here. 

[xgxxl89]

最新版本出现插件无法更新的bug 状态一直在检查中

[ljm42]

On 7/18/2023 at 5:13 AM, shredswithpiks said:

I just updated and the array went straight into a parity check

 

It won't help you now, but this was discussed in the first post in this thread, bullet 3 in particular. Now that you are on 6.12.3 this cause of unclean shutdowns won't happen.

[Pete0]

On 7/18/2023 at 2:13 PM, shredswithpiks said:

 

I just updated and the array went straight into a parity check. I doubt your issue is result of a power outage/dip/whatever.

But, docker and plex seem to be running without needing me to kick it with workarounds, so that's nice.

At least in my case I think it was. My unRAID Server now has a uptime of 6 days and no type of error occured since that time.

[Frank1940]

I am another one who had a unclean shutdown when I did the upgrade.  Let me provide some additional information as I did not do things in the standard way.  Basically, I did the first part of the reboot manually which I think provides some insight in to what happened in my situation

 

When I did the upgrade from 6.12.2 to 6.12.3 on my Media Server, I attempted to manually stop the array before I did the reboot.   The disks in the array all went to the "Unassigned" status but the the array stopping 'wheel' continued to run.  I looked at the log and there was a series of messages concurring about 20-30 seconds that the cache drive could not be 'unmounted'.  

 

Now, both of my servers are very simple setup.  There are no VMs.   This server has only two Docker apps installed and they were both running--  FoldingatHome and mysql.   I probably waited about five minutes to see if it could be unmounted.  Nothing happened to accomplish that.  I looked at the Docker Tab and found that it was already shutdown.  At that point, I update the Unraid firmware to the new version and then did a reboot.  (Probably, I should have tried to capture a diagnostics file at this point...)  Of course, I had an unclean shutdown because the reboot process forced a shutdown of the cache drive after the timeout.. 

 

After an hour with no errors detected, I cancelled the parity check.  I knew that the parity and data disks had been unmounted.  Thinking about it now, I suspect that one of five computers that use the mysql database (they are running KODI) had not done a proper disconnect. 

 

Next time, I will stop the mysql Docker first...

Edited July 21, 2023 by Frank1940
Added 'mysql' to "stop the mysql Docker first" in last paragraph....

[ljm42]

1 hour ago, Frank1940 said:

I am another one who had a unclean shutdown when I did the upgrade.  Let me provide some additional information as I did not do things in the standard way.  Basically, I did the first part of the reboot manually which I think provides some insight in to what happened in my situation

 

When I did the upgrade from 6.12.2 to 6.12.3 on my Media Server, I attempted to manually stop the array before I did the reboot.   The disks in the array all went to the "Unassigned" status but the the array stopping 'wheel' continued to run.  I looked at the log and there was a series of messages concurring about 20-30 seconds that the cache drive could not be 'unmounted'.  

 

It won't help you now, but this was discussed in the first post in this thread, bullet 3 in particular. Now that you are on 6.12.3 this cause of unclean shutdowns won't happen.

[Frank1940]

3 hours ago, ljm42 said:

 

It won't help you now, but this was discussed in the first post in this thread, bullet 3 in particular. Now that you are on 6.12.3 this cause of unclean shutdowns won't happen.

 

At the time, I remember reading about this command but I did not know where and when I has seen it.   My ability to recalled trivial details is not as good as it was a few years back. Since the array had stopped, I knew that everything had been written to the data disks, parity updated and any buffers/cache had been flushed.  So forcing a shutdown was not going to cause a data loss problem on the array itself. 

[jademonkee]

On 7/17/2023 at 3:56 PM, bambi73 said:

Updated from 5.11.5 and everything is working fine (not using Plex). Only exception (expected 😄) is MACVLAN.

 

 

I have Unifi too (UDM-Pro) and I wouldn't call state with IPVLAN as "no issues". It's working (great) but Unifi itself doesn't consider state of network as correct either (not so great):

• It occasionally complaints about multiple IPs assigned to single MAC in Admin messages
• In Client view my Unraid server show random IP address (probably last one updated in ARP table) and it's changing
• It messes statistics (and probably QoS too)
• Router is constantly (each 15sec) and unsuccessfully ARPING to IP addresses which aren't "main" at the moment (not sure if static ARP records will fix it because ARP table contains "correct" records)

Anyway it's good you are planning to involve kernel developers in the problem. Before you wrote this I intended to ask if there are some Linux kernel and/or Docker engine issues in their trackers (as I didn't find anything relevant). Was bit hopeful that recent (kernel 6.4) commits into macvlan.c will fix things.

Just adding to the voices on this issue:

I use MACVLAN on Docker, and have had no problems with that. I have Unifi gear (USG and 2x APs, with the controller running in Docker), and have no problems (except for it complaining that my bonded eth on the server shares an IP address).

If there's anything I can do to help troubleshoot this problem (contributing to a known-working hardware list, for instance), feel free to reach out.

[wirenut]

I am one who has had an unclean shutdown after upgrading.

I followed the instructions for the upgrade to 6.12.3. I did have to use the command line instruction, upgrade went fine and server was up for 6 days, this morning i needed to reboot server.

I spun up all discs

I individually stopped all my dockers and my VM.

I hit reboot button.

it is about 4 hours into unclean shutdown parity check with no errors, log repeated this while shutting down:

 

Jul 22 08:34:04 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:04 Tower emhttpd: shcmd (5468228): exit status: 32
Jul 22 08:34:04 Tower emhttpd: Retry unmounting disk share(s)...
Jul 22 08:34:09 Tower emhttpd: Unmounting disks...
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): umount /mnt/cache
Jul 22 08:34:09 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): exit status: 32
Jul 22 08:34:09 Tower emhttpd: Retry unmounting disk share(s)...

 

attached diagnostics captured from reboot.

 

not sure what/why it happened.

tower-diagnostics-20230722-0834.zip

[Glassed Silver]

1 hour ago, wirenut said:

I am one who has had an unclean shutdown after upgrading.

I followed the instructions for the upgrade to 6.12.3. I did have to use the command line instruction, upgrade went fine and server was up for 6 days, this morning i needed to reboot server.

I spun up all discs

I individually stopped all my dockers and my VM.

I hit reboot button.

it is about 4 hours into unclean shutdown parity check with no errors, log repeated this while shutting down:

 

Jul 22 08:34:04 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:04 Tower emhttpd: shcmd (5468228): exit status: 32
Jul 22 08:34:04 Tower emhttpd: Retry unmounting disk share(s)...
Jul 22 08:34:09 Tower emhttpd: Unmounting disks...
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): umount /mnt/cache
Jul 22 08:34:09 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): exit status: 32
Jul 22 08:34:09 Tower emhttpd: Retry unmounting disk share(s)...

 

attached diagnostics captured from reboot.

 

not sure what/why it happened.

tower-diagnostics-20230722-0834.zip 213.08 kB · 1 download

Probably a good idea to post this into a dedicated thread if you ask me.

 

off-topic/rant:

The longer I am on 6.11.5/6.12.x the more I wish I had heeded the cautious lessons of MACVLAN issues and remained on 6.9.2 until resolved,

That being said, a few weeks ago I didn't know I'd get a Fritz!Box router...

[Glassed Silver]

13 hours ago, jademonkee said:

Just adding to the voices on this issue:

I use MACVLAN on Docker, and have had no problems with that. I have Unifi gear (USG and 2x APs, with the controller running in Docker), and have no problems (except for it complaining that my bonded eth on the server shares an IP address).

If there's anything I can do to help troubleshoot this problem (contributing to a known-working hardware list, for instance), feel free to reach out.

Could it be none of your dockers use br0?

[ljm42]

1 hour ago, wirenut said:

I am one who has had an unclean shutdown after upgrading.

I followed the instructions for the upgrade to 6.12.3. I did have to use the command line instruction, upgrade went fine and server was up for 6 days, this morning i needed to reboot server.

I spun up all discs

I individually stopped all my dockers and my VM.

I hit reboot button.

it is about 4 hours into unclean shutdown parity check with no errors, log repeated this while shutting down:

 

Jul 22 08:34:04 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:04 Tower emhttpd: shcmd (5468228): exit status: 32
Jul 22 08:34:04 Tower emhttpd: Retry unmounting disk share(s)...
Jul 22 08:34:09 Tower emhttpd: Unmounting disks...
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): umount /mnt/cache
Jul 22 08:34:09 Tower root: umount: /mnt/cache: target is busy.
Jul 22 08:34:09 Tower emhttpd: shcmd (5468229): exit status: 32
Jul 22 08:34:09 Tower emhttpd: Retry unmounting disk share(s)...

 

 

This is not related to the recent bug fix. Most likely, you had a SSH or a web terminal open and cd'd to the cache drive, like this:

root@Tower:/mnt/cache/appdata# 

 

If desired, you can install the Tips and Tweaks plugin, by default it will automatically kill any ssh or bash process when you stop the array.

 

There are other potential causes too, see https://forums.unraid.net/topic/69868-dealing-with-unclean-shutdowns/

 

If your normal workflow regularly gives unclean shutdowns, I'd get in the habit of stopping the array first before restarting. That will give you a chance to see the "Retry unmounting disks" message in the lower left corner and start investigating.

[Revan335]

The new recommended docker Path is on the 6.12 Documentation/Release Notes -> Docker /mnt/user/docker not /mnt/system/docker on ZFS with special Config.

https://docs.unraid.net/unraid-os/release-notes/6.12.0

 

Can you change the default Docker Path and his configuration to this?

 

Then have new Installations the new Path and Config without reading the Release Notes. When 6.13 or higher released "nobody" read this old Release Notes/Documentation.

Edited August 18, 2023 by Revan335