Hoopster

As far as I am concerned, yes, it can be closed as the server in question boots consistently and without errors since adding the indicated line to i915.conf.

@VeeTECH That's what I did to add "options i915 enable_dc=0" to the i915.conf file on the flash drive.

That seems to have worked. Thank you. I guess I just missed that as it appears to have been mentioned previously. It makes sense as, even in 6.11.5, I had to disable low power mode for the HandBrake presets using QSV (lowpower=0 in More Settings in the Video tab) or all encodes attempted with QSV crashed.

I was afraid that might be necessary as the video seemed to indicate the boot process stopped with loading the i915 driver. Blacklisting i915 allowed the server to boot properly but this server has only the iGPU for graphics and is primarily a Plex server. Apparently, the Linux kernel in 6.11.5 has no problems with the i5-11600 CPU/iGPU but the kernel in 6.12.0 does not like it. 🙁

I have had at least 8 different hardware platforms on which I have run Unraid. On 2 S3 Sleep worked perfectly On 4, it was "iffy" and full of non-critical problems but very unrealiable On 2, it broke the server and it would not wake up from sleep. In one case, I had to replace the motherboard (fortunately still under warranty). In the other I had to replace the BIOS chip (both server-grade hardware) I avoid S3 sleep now because it is just unreliable and you don't know if it will work until you try it. I have no argument against S3 sleep in Unraid other than those already presented but I would never use it based on my experience.

Attempted to update two servers from 6.11.5 to 6.12.0; one upgraded without a hitch, the other will not boot into 6.12.0, it fails in the middle of the boot process and just stops. I will try to determine exactly where it fails but video output cuts out at that point as well. Can't get diagnostic as it does not boot. However, it is running syslog server and I have those logs. The system has a PiKVM so I will need to figure out how to record video in the PiKVM. Once I gather all available data, I will post a "bug" report.

Here are my settings which work. The only difference I see other than the port number (which you have tried changing) is that I have STARTTLS set to No.

I do exactly this. I have a pool SSD dedicated to Plex data with all other docker container appdata on the "cache" pool SSD. I just set the appdata path in the Plex docker like this: The other docker containers just use the default appdata path specified in Settings --> Docker:

That is only required for the first few posts to validate you are a human. There have been spambot problems in the past in these forums. Sometimes, this indicates your system wants to boot UEFI instead of BIOS. Renaming the EFI- folder on the Unraid flash drive to EFI (remove the - character at the end) addresses that. However, if it booted fine and now does not want to boot this may not be the issue unless you recently updated the BIOS/UEFI in your system.

You have a lot of call traces in your syslog. These usually indicate some sort of hardware issue. When enough call traces pile up, they eventually result in the server becoming unresponsive. I am not expert enough to tell you what is causing these call traces (perhaps someone else can point you in the right direction), but, there are a lot of them. Jun 11 01:20:52 Olympus kernel: Call Trace: Jun 11 01:20:52 Olympus kernel: <TASK> Jun 11 01:20:52 Olympus kernel: __schedule+0x596/0x5f6 Jun 11 01:20:52 Olympus kernel: ? _raw_spin_unlock_irqrestore+0x24/0x3a Jun 11 01:20:52 Olympus kernel: ? __mod_timer+0x207/0x232 Jun 11 01:20:52 Olympus kernel: ? rcu_gp_init+0x460/0x460 Jun 11 01:20:52 Olympus kernel: schedule+0x8e/0xc3 Jun 11 01:20:52 Olympus kernel: schedule_timeout+0x9d/0xd7 Jun 11 01:20:52 Olympus kernel: ? __bpf_trace_tick_stop+0x9/0x9 Jun 11 01:20:52 Olympus kernel: rcu_gp_fqs_loop+0xed/0x351 Jun 11 01:20:52 Olympus kernel: rcu_gp_kthread+0x131/0x14d Jun 11 01:20:52 Olympus kernel: kthread+0xe7/0xef Jun 11 01:20:52 Olympus kernel: ? kthread_complete_and_exit+0x1b/0x1b Jun 11 01:20:52 Olympus kernel: ret_from_fork+0x22/0x30 Jun 11 01:20:52 Olympus kernel: </TASK> Jun 11 01:20:52 Olympus kernel: rcu: Stack dump where RCU GP kthread last ran: Jun 11 01:20:52 Olympus kernel: Sending NMI from CPU 10 to CPUs 14: Jun 11 01:25:02 Olympus kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Jun 11 01:25:02 Olympus kernel: rcu: 4-...!: (0 ticks this GP) idle=a66/0/0x0 softirq=859477/859477 fqs=0 (false positive?) Jun 11 01:25:02 Olympus kernel: rcu: 6-...!: (1 GPs behind) idle=49c/0/0x0 softirq=834876/834877 fqs=0 (false positive?) Jun 11 01:25:02 Olympus kernel: rcu: 7-...!: (6 GPs behind) idle=604/0/0x0 softirq=869619/869619 fqs=0 (false positive?) Jun 11 01:25:02 Olympus kernel: rcu: 12-...!: (24 GPs behind) idle=616/0/0x0 softirq=795406/795407 fqs=0 (false positive?) Jun 11 01:25:02 Olympus kernel: rcu: 14-...!: (0 ticks this GP) idle=09d/1/0x4000000000000000 softirq=800399/800400 fqs=0 Jun 11 01:25:02 Olympus kernel: rcu: 15-...!: (1 GPs behind) idle=c40/0/0x0 softirq=837297/837299 fqs=0 (false positive?) Jun 11 01:25:02 Olympus kernel: (detected by 3, t=3310590 jiffies, g=2244009, q=685778 ncpus=16) Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 4: Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 6: Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 7: Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 12: Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 14: Jun 11 01:25:02 Olympus kernel: Sending NMI from CPU 3 to CPUs 15: Jun 11 01:25:02 Olympus kernel: rcu: rcu_preempt kthread timer wakeup didn't happen for 3370617 jiffies! g2244009 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 Jun 11 01:25:02 Olympus kernel: rcu: Possible timer handling issue on cpu=14 timer-softirq=55127 Jun 11 01:25:02 Olympus kernel: rcu: rcu_preempt kthread starved for 3370620 jiffies! g2244009 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=14 Jun 11 01:25:02 Olympus kernel: rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. Jun 11 01:25:02 Olympus kernel: rcu: RCU grace-period kthread stack dump: Jun 11 01:25:02 Olympus kernel: task:rcu_preempt state:R stack: 0 pid: 15 ppid: 2 flags:0x00004000

This has been a no-go in accordance with the Unraid licensing policy; no transfer of license to another email address for any reason whatsoever. No License Transfers Lime Technology does not support the transfer of Unraid OS licenses to a 3rd party for any reason whatsoever. If you are an OEM partner or buying for a third party, please select the OEM toggle at checkout. In your case, you may wish to contact Limetech directly to explain the situation and see if they will make an exception. Another possibility is you keep the current Unraid license and USB flash drive for a future Unraid system and license a new one for the current system with the new owner's information. You can copy the config folder from the current USB key to the new one and the system will function exactly as it currently does. I suspect this is what Limethech will suggest you do.

Rarely does a docker.img file need to be larger than 20GB. Even with a lot of docker containers, this is sufficient. 100GB is definitely excessive and indicates configuration problems somewhere. For example, I have 15 docker containers with only 12 GB used in the 20GB docker.img file. If you keep needing to increase the size of docker.img and usage within the file keeps growing even when you add no new containers, it is almost certain you have one or more containers improperly configured and they are writing data into docker.img instead of to an array, cache/pool or unassigned devices location. The most common offenders are file download apps (Deluge, Transmission, the *arrs, etc.) , backup apps, media management apps (Plex, emby, jellyfn), etc. A good way to find potential offenders is to click on the Container Size button and look for containers that are unusually large. Some are 2-3GB in size and this is normal for that container. Other are much smaller. For example, my Plex container is only 334 MB in size and the Krusader container is 2.38GB. Both are normal. If you see one or more that appear to be unusually large, ask for help in the support thread for that container. Docker.img is only meant to be the storage location for the docker container images and not their data.

DFM is a great tool and I am certainly not suggesting you not use it; however, if you find that it does not meet your needs for mass disk reorganization (Move, Copy, etc.) many of us find the Unbalance plugin to be very useful.

The screenshot you posted above of the menu shows your selected action will take place on Workpool because you clicked on that disk in the location column. It is unclear to me if Delete in this case means delete everything on Workpool or just delete the share/folders from Workpool. I would hope it would be the latter but it appears it may have deleted everything on Workpool. Clicking the Action button (+) performs the selected action on the highlighted folder/share; at least this is how I read it in the documentation. I could be wrong as I have never attempted to do what you were trying to do. The File Manager documentation can be downloaded from first post in this thread.

Mover only moves data off of cache disk and onto the array for shares that are set to cache: yes You need to read and understand the various cache settings and make sure you have the shares set properly Cache settings documentation. This is the expected behavior. This does not move anything off cache drive that is already there.

When you setup appdata in a different cache/pool drive location, simply reinstall all your previous docker containers from the Previous Apps section of the Apps tabs. They will be restored with all previous settings intact. If your data is to be moved to different drives, you can use the Unbalance plugin to move the data where you wish. If it is staying on the same drive(s) you can preserve certain disk assignments in a new configuration. Data remains intact. You can also reassign drives to new slots if you wish and data remains intact as long as you do not format the drives.

Art of the Server is a known good seller who stands behind what he sells. It is often used server pulls but they are the genuine goods. The second seller is from China. "LSI" cards from China are very often counterfeit. There is no way to tell until you get it. Some work just fine, counterfeit or not, and others have problems. It's a crap shoot. The Chinese cards says the brand is "unbranded" which is a good indicator it is at least a knock-off and not genuine LSI. I suppose it comes down to your choice of whether to pay more for a sure thing or gamble on a less-expensive item from China.

This is true. Limetech has been getting "pressure" for native ZFS support for close to two years. The addition of ZFS is in response to user demand for it and was a major undertaking for the team. Obviously, that has held their attention for a while. Arc support has Linux kernel dependencies and messing with the Linux kernel version, unless necessary, is something the team tries to avoid during a new release cycle although it has happened (usually with just minor, incremental kernel versions). I am sure Intel Arc support, at least as far as the Linux kernel takes it, will be coming in a future release.

My main server has been chugging along for months with no problems. Today, three SSDs assigned as pool devices and UD disappeared from the system. Since they are all in a 4x 2.5" SATA SSD/HDD enclosure for one of the 5.25" bays in my case, I assumed there was a problem there. Apparently, the Molex to SATA power adapter cable that powered that enclosure had failed as replacing it solved the problem. System was happy again and all SSDs showed up. Then there was a very annoying noise coming from one of my case fans. Down went the server to figure out what was up with that. Tightened all screws, made sure no cables were touching the fan and fired up the server again. Noise gone. Server would not boot to Unraid. The Unraid flash drive did not even appear in the BIOS as a boot option and it was trying to boot from the optical drive. I am using a USB 2.0 adapter in the case that connects straight to the motherboard internal USB 2.0 header. Re-seated everything, ran checkdisk on the flash drive just in case (no errors), and reattached the USB flash drive to the pigtail. Flash drive showed up in BIOS and the server now boots properly again. Then I discovered the optical drive will not open or close with the button press; just flashing lights and no action. The little plastic L in the SATA power connector on the drive had the small tip broken off. I had to rig a way to keep the power connector cable firmly attached to the drive and then all worked well. I hate SATA connectors, they are so flimsy and the cables come loose easily. Although I try to be careful, messing around inside the case can and will cause other problems even if you fix the original one. There is not a lot of extra room in the case and it is easy to bump and loosen other cables while messing with the one(s) suspected of causing problems. I hope I don't need to open it up again for a good long time. 😀

Some additional featuers (such as reflink) were added to XFS a while ago that results in more space being used when initializing the filesystem with a format. 55G for an 8TB drive is not unusual.

@paulbram This is another option (BTRFS RAID1) for pool devices, but there have been cases where power outages/spikes affected all devices in the pool. Although this is not typical, it can happen. Basically your options are: Redundancy within the pool Backup of pool data outside the pool Both of the above

In a word "no" with respect to parity protection. By definition, prefer cache means to store appdata or whatever is in the share on a pool device outside of the parity-protected array. This is normally done to avoid the parity write speed penalty and to avoid spinning up hard drives as these cache/pool devices are often SSDs. Even setting a share to cache Yes means the data is not parity protected while it is on cache/pool location until the Mover runs and moves it to the array. I have appdata as a cache preferred share and my protection for it is a scheduled run of the appdata backup plugin a couple of times a week. My appdata backup location is an unassigned device that is outside the array and pools.

4K transcoding takes a lot of horsepower. If you don't have a lot of horsepower, it takes a lot of time. That's why optimized libraries are good so you don't have to transcode in real-time; however there can be a big upfront investment in time.

If using Plex, you don't have to download content in both 4K and 1080p. Plex will "pre- transcode" the 4K content into mobile friendly versions. https://support.plex.tv/articles/214079318-media-optimizer-overview/