1812

maybe unraid should not use statfs..... but either way, THANK YOU!

6 1tb ssds singe mode = 6tb raid 0 = 6tb raid 1 = 3tb raid 5=5tb raid 10 = 2tb??? file system df: Data, RAID10: total=15.00GiB, used=0.00B System, RAID10: total=480.00MiB, used=16.00KiB Metadata, RAID10: total=3.09GiB, used=128.00KiB GlobalReserve, single: total=3.25MiB, used=0.00B but main tab shows: I've tried changing format to xfs and back to Btrfs. is this a glitch? because Btrfs-usage.txt shows I rolled back to 6.9.1 to check and it showed the same on the main tab as 6.9.2 in maintenance mode, filesystem check shows: Paging Dr. @JorgeB! b1-diagnostics-20210507-2313.zip

I DIDN'T BREAK YOUR STUFF AND YOU HAVE NO PROOF.

do you have 2 processors installed?

several of us are using this: and using the hpssa option to enable it I use it on a p420i that does not have native hba mode. If yours supports hba mode, then it should be ok and you'll save yourself a pci slot for other things.

I've tried searching but can't find anything relevant. Has anyone gotten Wireguard to work on unraid using untangle as a router? Yes, I know untangle has it as an app, but I'm not interested in paying 250 a year for the functionality. If I use pfsense, wireguard works as expected with almost not modifications. Using it with untangle only gives me server access even when remote tunneled access is selected. And if I create a rule to bypass all apps for the Wireguard subnet, still no joy.... I feel like I'm missing one setting somewhere but dont know what it is. --- edit putting my laptop in the subnet that Wireguard uses allows access to all devices on the lan across subnets but no internet access, even when changing DNS from local to something like 1.1.1.1

I use the following script that loads via user scripts plugin at the start of the array: #!/bin/bash nvidia-smi -pm 1 makes my gt 710 go to P8 reliably when not used by plex.

my firewall informed me that my server attempted to connect to a malware site: System: Untangle [Verv.Nunya.com] Event: WebFilterEvent Event Time: 2021-03-23 01:36:06.975. Event Summary: Web Filter blocked http:/boaform/admin/formLogin?username=user&psd=user (Malware Sites) Event Details: app name = web_filter blocked = true category = Malware Sites category id = 56 flagged = true reason = BLOCK_CATEGORY request line = GET http:/boaform/admin/formLogin?username=user&psd=user rule id = 56 session event bypassed = false c client addr = 112.72.231.35 c client port = 2728 c server addr = redacted - my ip c server port = 80 client country = KR client intf = 1 client latitude = 36.6353 client longitude = 127.4678 entitled = true hostname = Tower local addr = 192.168.1.253 policy id = 1 policy rule id = 0 protocol = 6 protocol name = TCP remote addr = 112.72.231.35 s client addr = 112.72.231.35 s client port = 2728 s server addr = 192.168.1.253 s server port = 180 server country = XL server intf = 3 session id = 105907154162496 tags string = time stamp = 2021-03-23 01:36:05.741 time stamp = 2021-03-23 01:36:06.975 This is an automated message sent because this event matched Alerts Rule "Malware Sites website visit blocked". Fortunately it appears blocked. trying to find out more about what's going on though, and if it originated internally or was something like a malformed header sent to the server, which then tried to respond? I'm a bit out of my depth on this. The latitude and longitude logged shows South Korea...where I am defiantly not located. My server is running 6.9.1, and I use the nginx proxy manager for routing to a nextcoud installation. so only ports 80 and 443 are forwarded through my firewall. I think I'm going to start running a Clam AV instance but I have about 21 TB it has to go through. I don't download any movies or other files from the internet. Assistance is greatly appreciated!

IIRC, when directly hooked up to the cages, yes, when run through an expander, no.

modified the original post to make it clearer. It should go under menu default

Yes. In some step, something is incorrect. Without knowing everything you did and verifying each step, there is no way to know so you will have to try the process again. But I can already see that you didn't follow the steps as written because it says to only copy over the bzimage and bzmodules. That may not matter, but it shows inattention to detail. So now you should roll back to stock unraid, reboot, and start over and follow the steps as written, and then report back.

You could try another disk to see if you just got a bad one. I have no guidance because I don't use the raid controller with disks in raid 0 because weird things like this can happen.

I use an H220. I've actually used them in several HP servers from G6 to this one for years without issue and they are pretty cheap. I bought an h240 once but it didn't send drive temps through at the time,. So now it sits in a box until that's better supported or I figure out what needs to be configured. But there is no real need for a card like that which does 12gbps in most unRaid servers, mine included. Even on 10gbe networking, my transfers to an SSD cache pool are limited by network speed.

I use a slew of Samsung evo ssd's in my ml350p gen 8 without issue. But his is using an HBA. After my initial issues with the onboard raid controller, I avoid it like the plague. But there are some others running disks in Raid 0 using the controller without issues. I don't have a fix for you aside from getting a HBA or waiting to see if the patch works out. Do you have other disks you can try to see if it's the disk itself or something else?

Correct. Currently there is no other way. But, there is something in development by other forum members to use/froce the controller in JBOD mode even though it's not available in the bios. If that becomes viable then I'll definitely share here.

You did not follow the steps in the first post for "VM problems - pass-through" your logs show 0000:04:00.1: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. 0000:04:00.1: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. your fix is:

For real. I've gotten a few kernel panics/crashes on my m1 Mac.... early adopter price....

any reason why virtmanager won't connect to my server? I keep getting port 22 connection refused.... yes I have a pw on the server also, can anyone else confirm that removing a video card and going back to vnc makes the vm hang on "Guest has not initialized the display (yet).

The current method of RMRR patching is now deprecated. For the new method of RMRR patching please see here:

Welcome to the "new" new method of working around HP's RMRR problem on unRaid. For the previous/deprecated method which was no longer working, see: https://forums.unraid.net/topic/72681-unraid-hp-proliant-edition-rmrr-error-patching/ Additionally, for 6.9 there was a way to compile the patch yourself using the now deprecated kernel helper. This method starting with 6.10 is more streamlined as the patch is pre-built into unRaid now. First the disclaimer: This patch been tested with no negative attributes observed by myself and many others. . Many have been running an RMRR patched version since mid 2018 when we first started producing them, and so far have had no reported issues. In 2021 I sold my last proliant, so as new releases of unRaid are made public, it will be on the users to report any issues as they may (or may not) arise.. As the patch only omits RMRR checks, it should not affect any other core function of the OS. But as a general notice, neither Limetech or myself, or any contributors are responsible/liable for any loss of data or damage to hardware in enabling this patch in unRaid, or on any other system you install it. The "New" New unRaid HP Proliant Edition - RMRR Error Patching Description/Problem It is well documented that many HP Proliant servers have RMRR issues using certain BIOS versions after about 2011 when trying to passthrough devices in a linux environment. Device passthrough fails and the onscreen error will show: vfio: failed to set iommu for container: Operation not permitted And a look further into the logs show: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. HP is aware of this problem and is not updating older machines. There are some bios options to try to fix this on newer models with some success. On unRaid, the problem is addressed by patching out the RMRR check. As of 6.10 the patch is now built into unraid, but off by default. Information regarding the patch can be found here: https://github.com/kiler129/relax-intel-rmrr Note: the patch author states: ------------------ --->>>A big thanks to @ich777 for creating the ability for users to previously easily compile the patch themselves, and to @limetech for now incorporating it into unRaid itself. <<<--- ------------------ Previously, @AnnabellaRenee87 and I maintained and provided the patched file for users. But now you will be able to easily enable the patch as it is included in unRaid starting with 6.10. Installation/Enable Procedure valid starting with 6.10 For users already using a previously patched version of unRaid, follow these steps: 1. Make a backup of your flash device by clicking on the main tab, then scroll down to your boot device section, click flash, then click flash backup and wait for the download. 2. Modify your syslinux.cfg by going to the main tab>boot device>flash in the "Unraid OS" section. Modify to the following: append intel_iommu=relax_rmrr initrd=/bzroot The patch is off by default and requires this to enable it. 3. Update to at least 6.10 of unRaid, reboot. 4. After the server has booted up, open a terminal and enter dmesg | grep 'Intel-IOMMU' If the patch is active you will get the following response DMAR: Intel-IOMMU: assuming all RMRRs are relaxable. This can lead to instability or data loss For users already running 6.10 and above follow these steps: 1. Make a backup of your flash device by clicking on the main tab, then scroll down to your boot device section, click flash, then click flash backup and wait for the download. 2. Modify your syslinux.cfg by going to the main tab>boot device>flash in the "Unraid OS" section. Modify to the following: append intel_iommu=relax_rmrr initrd=/bzroot The patch is off by default and requires this to enable it. 3. Reboot. 4. After the server has booted up, open a terminal and enter dmesg | grep 'Intel-IOMMU' If the patch is active you will get the following response DMAR: Intel-IOMMU: assuming all RMRRs are relaxable. This can lead to instability or data loss Disable To disable the patch, remove the modification to syslinux.cfg and reboot. Other Proliant Problems Check this thread for fixes to other common Proliant problems: https://forums.unraid.net/topic/59375-hp-proliant-workstation-unraid-information-thread/ Happy unRaiding!

Simply amazing stuff. You are a credit to the community.

It keeps pulling Catalina instead of Big Sur for me even though I selected Big Sur twice with method 1....macOS Product: 061-86291 Switched to method 2 says it's trying for Product: 001-86606... I guess I'll leave it overnight and see what greets me in the am. update: method 2 downloaded Big Sur

People testing network throughput ¯\_(ツ)_/¯