wayner

Sorry, but it isn't clear what the simplest solution is from the changelog. According to the changelog Isn't the first step to change from macvlan to ipvlan? But are you saying to stay with macvlan and change from br0 to eth0? And if I do this then do I have to change the bonding, bridging and access to host network settings for eth0? Which should I try first? Or should I do both?

I have received an error for macvlan call traces. I was going to make the change from macvlan to ipvlan, but I have a Ubiquiti router and other networking hardware. The release notes say: What sort of reduced functionality is this referring to? And does this affect all Ubiquiti users or some? My system is fairly simple, I have one NIC, and I use br0 for a few dockers, bridge and host for a few others. What should I be looking for when it comes to network issues?

There seem to be a bunch of people that have issues with their cache drives after upgrading to 6.12, I am not the only one - I linked to a thread up a coupole of posts.

As an update - I reverted back to 6.11.5 but the problems continued and my cache drive was unmountable. So I reformatted the cache drive to btrfs and got the system back up and running and it ran for over 2.5 days. I upgraded again to 6.12.4 and the system went down within 8 hours reporting the same types of problems - BTRFS errors with write time tree block corruption detected. Is this a bug in the unRAID 6.12.4 OS? Or do I have some hardware issues that only show under 6.12.4, but not 6.11.5.

I have been using AirVideoHD, which has a Docker, to stream video files to my iPad and iPhone. These files can be TV shows that are currently airing live that are airing live and they don't really fit into an app like Plex as Plex wants metadata. I just want to stream a file from a folder on my media/tv share. AirVideoHD hasn't been supported for years and has a few bugs from time to time. And I am worried that it may stop working in future iOS releases. Anyone have any other ideas.

@PeteAsking - I am still running 7.2.95. Is there any reason to upgrade? If so then should I go to 7.4.162? My hardware is primarily UAP-AC-Lite APs in a home environment. Plus I have a USG as my router.

Thanks, that worked. Everything looks good for now.

My cache disk became unmountable before I could use Mover to move any data from the cache drive to the array. But I had a recent backup of all of the appdata files stored on a local PC. So I reformated the cache drive and then I copied over all of the appdata folders and restarted docker. But the Docker UI says that there are no dockers running. The docker image file is supposed to be in /mnt/user/system/docker/docker.img but I don't see a system folder on my cache drive. Should I create one? Is there any way to get the system to recognize that there should be dockers? Or do I have to reinstall all dockers from scratch, and it will use the data files existing in appdata if they exist?

Thanks - how do I setup mirroring of the cache drive? Is there a doc page for that?

I am having btrfs corruption errors on my cache drive. So I want to reformat it. Are these the correct steps? Stop Docker service. Stop VM service. Set cache to yes for all shares. appdata is currently set to prefer cache. Run Mover. Wait until Mover moves over all data from cache drive to array. Stop array. Do I need to unassign the cache drive at this point? Should I format to btrfs or xfs? It seems that btrfs corruption issues are pretty common. When I get the cache back up and change the appdata share to cache prefer and run Mover will it then move all of the appdata files back to the cache? If so, should I wait until Mover has moved all appdata files back to the cache before starting the Docker service, or does that not matter? Does it make sense to add a second cache drive? If so, does that make a difference to whether I should use btrfs or xfs on the cache drive?

So I reverted back to 6.11.5 and my dockers seemed to start without having to do the forced upgrade.

Awesome, thanks!

By this you mean that I don't have to actually do a force update? I just have to have it recreate the docker due to a slight change in a parameter? So I could add a new variable called "dummy" with the value "dummy" and I would be good?

The release notes state: What does it mean by "underlying chage to cgroup v2"? What happens if you don't/can't do a force update to all of your Docker containers? What are the ramifications? I have one Docker that I don't want to update to a newer version, can I "force update" it back to the same prior version? And I may have a docker that is no longer available.

Doesn't this sound like the same issue: Users in that thread report btrfs errors that go away when reverting back to 6.11.5. About 5-6 people report the same issue as I am describing in this thread.

I will just add a ME TOO to this thread. My system was rock solid under 6.11.5 and since I upgraded a few days ago to 6.12.4 I am having btrfs issues. I will try rolling back to 6.11.5.

What about if I got a second 500GB NVME, used that as a second cache drive, and then reformatted the first drive? Is that an easy process to do? These drives are very cheap right now - $40 Canadian. Does that make sense?

Should I stick with BTRFS or use XFS?

By reformatting the pool, you mean my drive array? Or the cache drive?

So, this keeps happening, I upgraded from 6.1..5 to 6.12.4 on Friday afternoon. About 2-3 hours later the issue occurred. I rebooted, and it ran for about 7 hours before reoccurring. I rebooted the next morning and the system ran for about 30 hours before the issue occurred. Then the system ran for about 22 hours before I just got a hard crash. Previously my stems was still alive - the web UI worked and the system responded to pings. This time it went down hard and I had to do a power cycle to bring back. Should I try going back to 6.11.5 to see if this is just an issue with 6.12.4?

By bad RAM, do you mean bad RAM in the NVME SSD, or bad RAM in terms of the PC's DRAM memory?

Looking at the error message a little more closely it looks like the drive with errors is the nvme drive which is my cache drive. Why would it start throwing serious errors after an upgrade of the unRAID OS? Is this just a coincidence? When I do an extended SMART test it finishes immediately. Is that because it is an SSD? Here is the SMART test output: smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.49-Unraid] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: WDC WDS500G2B0C Serial Number: 21305D807219 Firmware Version: 211210WD PCI Vendor/Subsystem ID: 0x15b7 IEEE OUI Identifier: 0x001b44 Total NVM Capacity: 500,107,862,016 [500 GB] Unallocated NVM Capacity: 0 Controller ID: 1 NVMe Version: 1.4 Number of Namespaces: 1 Namespace 1 Size/Capacity: 500,107,862,016 [500 GB] Namespace 1 Formatted LBA Size: 512 Namespace 1 IEEE EUI-64: 001b44 8b41b6d08e Local Time is: Sat Sep 2 11:17:19 2023 EDT Firmware Updates (0x14): 2 Slots, no Reset required Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp Log Page Attributes (0x1e): Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Pers_Ev_Lg Maximum Data Transfer Size: 128 Pages Warning Comp. Temp. Threshold: 80 Celsius Critical Comp. Temp. Threshold: 85 Celsius Namespace 1 Features (0x02): NA_Fields Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 3.50W 2.10W - 0 0 0 0 0 0 1 + 2.40W 1.60W - 0 0 0 0 0 0 2 + 1.90W 1.50W - 0 0 0 0 0 0 3 - 0.0250W - - 3 3 3 3 3900 11000 4 - 0.0050W - - 4 4 4 4 5000 39000 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 2 1 - 4096 0 1 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 33 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 3% Data Units Read: 11,332,177 [5.80 TB] Data Units Written: 44,540,222 [22.8 TB] Host Read Commands: 77,074,211 Host Write Commands: 531,724,132 Controller Busy Time: 737 Power Cycles: 78 Power On Hours: 14,728 Unsafe Shutdowns: 64 Media and Data Integrity Errors: 0 Error Information Log Entries: 1 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Error Information (NVMe Log 0x01, 16 of 256 entries) No Errors Logged

Yesterday I upgraded my server from 6.11.5 to 6.12.4. Everything appeared to go well. But after a few hours I noticed that my dockers weren't running. When I tried to restart one I get Execution Error. I rebooted the system. Overnight the problem re-occurred. The system crashed some time after 1:17am. Anyone have any idea on what the issue is and how to fix? Are BTRFS errors related to my boot USB drive? Do I need to replace that drive? Could this be a bug or issue in 6.12.4? Is it just a coincidence that this occurred after upgrading? Should I restore back to 6.11.5? Here are the logs that were in red from the time that I think the problem occurred. Diagnostics are attached.portrush-diagnostics-20230902-0915.zip

Thanks for your help. All updated and all is well - at least so far!

That makes sense. Should I always wait until you have updated the plugin before updating to the latest OS version? It would be bad news for me if I updated and couldn't use my TV tuners.