RifleJock

Members
  • Posts

    47
  • Joined

  • Last visited

About RifleJock

  • Birthday 11/08/1995

Converted

  • Gender
    Male
  • Location
    United States

Recent Profile Visitors

1208 profile views

RifleJock's Achievements

Rookie

Rookie (2/14)

1

Reputation

  1. I can confirm, that I run into a lot of these problems as well. I had originally built the 7950x on Asus X670E Extreme. I ended up doing RMA's and other things that left my build in a messy state. While buying and swapping hardware around, I ultimately ended up building a secondary system. The other system, the 7950x3D and x670e Gene, seems to be a lot more stable. I will say that I went away from unraid due to the instability with it. Now both of those systems are on 7950x3D, and I notice, that there are lots of limitations with unraid and the x3D processors as well, having to send data through a specific core, and crashes after reserving specific cores for vm's. I'll be playing around with all the builds again on unraid soon, I'm sure I'll still run into the same issues, but seing as there as been a lot of BIOS updates and Kernel updates with unraid, perhaps there is some stability now? We will see.
  2. How necessary is this process? (using ich777/minecraftbasicserver) --env 'UID=99' \ --env 'GID=100' \ The issue that I'm facing, is that my Minecraft (MC Eternal) server reboots will take literally forever to reboot due to this process. I've got hundreds of gigs of Dynmap and World data, and everytime the container reboots, this process will struggle to go through each of the directories created, mainly Dynmap and World folders will cause this to take forever as there are millions of folders/subdirectories. Can I set the necessary permissions one time, and disable this process from the bootup process?
  3. Same boat here, AX1500i. Unraid 6.10.0-rc3 root@CRYZEN:~# lsusb Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 003: ID 0b05:1984 ASUSTek Computer, Inc. USB Audio Bus 005 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 1b1c:1c02 Corsair Corsair Link TM USB Dongle Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub root@CRYZEN:~# root@CRYZEN:/sys/bus/usb/drivers# ls -al total 0 drwxr-xr-x 8 root root 0 Mar 19 04:13 ./ drwxr-xr-x 4 root root 0 Mar 19 04:13 ../ drwxr-xr-x 2 root root 0 Mar 19 04:13 hub/ drwxr-xr-x 2 root root 0 Mar 19 04:13 synaptics_usb/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usb/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usb-storage/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usbfs/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usbhid/ root@CRYZEN:/sys/bus/usb/drivers# cd hub/ root@CRYZEN:/sys/bus/usb/drivers/hub# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:08 1-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb1/1-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 10-0:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 2-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb2/2-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 3-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 3-5:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/3-5:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 4-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb4/4-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 5-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 5-1:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-1/5-1:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 6-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb6/6-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 7-0:1.0 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb7/7-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 8-0:1.0 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb8/8-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 9-0:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb9/9-0:1.0/ --w------- 1 root root 4096 Mar 19 09:08 bind lrwxrwxrwx 1 root root 0 Mar 19 09:08 module -> ../../../../module/usbcore/ -rw-r--r-- 1 root root 4096 Mar 19 09:08 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:08 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:08 unbind root@CRYZEN:/sys/bus/usb/drivers/hub# cd ../synaptics_usb/ root@CRYZEN:/sys/bus/usb/drivers/synaptics_usb# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ --w------- 1 root root 4096 Mar 19 09:11 bind -rw-r--r-- 1 root root 4096 Mar 19 09:11 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:11 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:11 unbind root@CRYZEN:/sys/bus/usb/drivers/synaptics_usb# cd ../usb root@CRYZEN:/sys/bus/usb/drivers/usb# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:11 10-1 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 3-5 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 3-5.1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/3-5.1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 5-1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 5-6 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-6/ --w------- 1 root root 4096 Mar 19 09:11 bind --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:11 unbind lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb10 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb2 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb2/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb3 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb4 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb4/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb5 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb6 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb6/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb7 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb7/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb8 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb8/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb9 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb9/ root@CRYZEN:/sys/bus/usb/drivers/usb# cd ../usb-storage/ root@CRYZEN:/sys/bus/usb/drivers/usb-storage# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:12 10-1:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-1/10-1:1.0/ --w------- 1 root root 4096 Mar 19 09:12 bind lrwxrwxrwx 1 root root 0 Mar 19 09:12 module -> ../../../../module/usb_storage/ -rw-r--r-- 1 root root 4096 Mar 19 09:12 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:12 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:12 unbind root@CRYZEN:/sys/bus/usb/drivers/usb-storage# cd ../usbfs/ root@CRYZEN:/sys/bus/usb/drivers/usbfs# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ --w------- 1 root root 4096 Mar 19 09:13 bind lrwxrwxrwx 1 root root 0 Mar 19 09:13 module -> ../../../../module/usbcore/ -rw-r--r-- 1 root root 4096 Mar 19 09:13 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:13 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:13 unbind root@CRYZEN:/sys/bus/usb/drivers/usbfs# cd ../usbhid/ root@CRYZEN:/sys/bus/usb/drivers/usbhid# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:13 5-6:1.7 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-6/5-6:1.7/ --w------- 1 root root 4096 Mar 19 09:13 bind lrwxrwxrwx 1 root root 0 Mar 19 09:13 module -> ../../../../module/usbhid/ -rw-r--r-- 1 root root 4096 Mar 19 09:13 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:13 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:13 unbind root@CRYZEN:/sys/bus/usb/drivers/usbhid# ^C root@CRYZEN:/sys/bus/usb/drivers/usbhid#
  4. It's doing pretty well, though one major issue, can't run a GPU in PCIE slot one, New bios update came out yesterday, was going to do some testing again on it. Having GPU in slot one, board fails to do resets correct. Luckily, managed to get SLI working still using slot 3 and 7. Find it weird that slot 7 is hardware id 1:00:00. Additionally, raw windows 10 thinks the same, that the bottom gpu ends up being the primary. Doing research on other sites about the slot resets failing, I managed to find that it's apparently due to the chipset drivers, AMD has the version that supposedly fixes it labeled as Beta, so Asus doesn't officially include them in the bios updates. They are still using the lastest full release, which has been known to cause issues on Ryzen Threadrippers on gaming boards (which have the beta drivers as a beta bios) as well as the Threadripper Pros. Recommend using another item in the slot 1 as a work around. Anyways, I had once also though that the microSD card slot on the board would work for passthrough. While it did technically, I ended up confusing the licensing as this slot is IPMI passable. As well as some virtual USB's that you can upload files to using the web-ui for the board management. Was weird, because having the system boot, it would change the GUID of the microSD card slot every boot, and additionally, if I installed my valid USB, the licensing would see it correctly, and think its writing to the usb flash drive, but would actually write to the SD card (which showed up as flash). But os would see the usb's capacity and licensing. Other than that, or and the Kernel not showing a supported CPU on boot, it all has been working okay I suppose. Lots of troubleshooting for sure, and 6.10 rc2 is allowing the gui to work in UEFI boot, and tpm2.0 passthrough works as well. both cpu based and motherboard/hardware based. DM me or something if you have more detail questions or are interested in the board, can do some testing for you.
  5. I've ran into this same problem multiple times as well. Now that I'm on a new system, I'm certain it's not the hardware that's at fault. I think I've narrowed it down, I've wiped and re-installed my flashdrive back to 6.9.3. I've rebuilt all my docker containers (I also use the vm/docker folders plugin) when on 6.9.3. Then, I upgrade (causing shares's settings to disable). I then re-enable the shares. All shares, disks and folders go missing. Trying from a fresh install using the windows flash creation/installation tool, I install 6.10.0-rc1. This time, enabling the shares appears to work. Next, the docker container's show they are errored, and that the images are missing. I delete and re-download them. Once completed, after a short time, my shares appear to go missing... I'm also running parity re-build in the background since it's a new OS, and I happened to add two drives. Once the parity build starts, it doesn't appear to like being paused. Logging also has stopped working through the web-ui since the disappearance of the shares. I can spin disks up, (the 1 and 2TB disks spun down, since party is still going, but not read from them.) But once spun up, they appear to not want to spin down manually again. I have to wait for my disk settings' 45 minute timer to kick off the spin down. On the first few attempts at a fresh install, after editing networking and other settings, I managed to get to a state where the web-ui was completely unresponsive, booting locally to the gui was also not working as I continued to get the plagued blinking cursor. I ran a tcpdump and saw my connections coming into the system, but the system did not respond to the web-ui requests. Also attempted multiple browsers. It appeared as if a core service of the web-browser was failing to start on startup. This last go around, the web-ui is sluggish, but working... The only thing I hadn't changed this last time compared to the first few attempts, was any networking settings (from the initial install to the flashdrive) as well as the identification settings. Same with management access (other than enabling ssh). Changing those before ended up leading to no web-ui. I'm not sure why this version seems to have issues when it comes to the web-ui, but there are too many things "fixed" from the previous versions, that I don't want to go back. For instance, even with "nomodeset", my ASPEED VGA adapter from the BMC's IPMI appears to be working now when booting UEFI (other than when the web-ui becomes completely unresponsive.) PS: Also, I'm only working in UEFI booting mode, as is required on this system to get all NVMe's and Sata drives to show up. Maybe a limitation of the bios, working with Asus to resolve those related issues. Here is the diagnostics. IDK what else I'm missing, not really sure of a lot of things when it comes to the software side of it. If anyone has any suggestions or questions, please let me know. Edit: I just realized my "user" folder has gone missing... what could cause this? cryzen-diagnostics-20211025-1004.zip So, I'm guessing something happened to bzmodules or something? and the user mount is unknown now? IDK, I'm too n00b to figure anything else out, I'll wait for a senior.
  6. Looks like I still have this problem as well... I had thought it was just my hardware, seen with UEFI and Legacy, I've tried every CSM variation in my bios, even trying older and newer bios's. Asus z10pe-d16 ws. Board ended up dying a while back, and I ended up upgrading to the Asus PRO WS wrx80e SAGE SE WIFI, this uses a similar IPMI and BMC setup as the previous board, both used an ASPEED (VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41)) This one being a newer revision. Not sure what I'm missing. I hadn't tried other modes, but I suspect that CSM usage and legacy boot will allow the gui to work once again. (version 6.9.2) cryzen-diagnostics-20211022-0913.zip cryzen-diagnostics-20211024-1119.zip
  7. Hello all, curious the status of this plugin. Noticed my AX1500i isn't being recognized. Anyone else have an AX1500i working?
  8. I'm down to be a guinea pig for the multi-gpu tests... I'm sure I have some AMD's laying around somewhere I could slap in there as well to test cross vendor support. Also, I've noticed that they have some vGPU support when it comes to the Intel iGPU's... I'm curious if we can get stats on those as well.
  9. While that is a valid point and what I currently do with my anime directories (for plex and other media servers). The goal with the GoPro libraries was not for that of economics, but rather, of performance from the array disks. With the anime libraries, it's setup to where a disk is accessed based on the series you are watching. If you decided to binge the series, the disk will stay spun up as the shows usually don't exceed 45 minutes (post full read and cache of the at each start of an episode) of which, is my disk spin down setting time. For instance Plex will read a disk at the start of an episode. Go full ape in transcode based on your transcode settings. Transcoded files then sit on the cache to be read back live during your stream. If the disk spun down, and the user either decided to change their quality settings, skip the episode at some point, or scrub backwards (sometimes, transcodes are discarded and need to be rerecorded (this was back in the day.. transcodes stick around a little longer now.).). Anyways, it just so happens that 45 minutes until spin-down works perfectly in all the scenarios that I could reference in my system. That combined with specific directory splitting, or disk allocation methods, I've not had to use the spin-up groups as of yet.. though I'm starting to see more of a need for them...
  10. I've never used them. However, was considering it now, but seeing as they might go away, may consider not using them. I had a use case before, when I used 6x 8TB drives. This was on my Media share, where I had used "most-free" and changed the directories split such that each 30 minute GoPro video would be placed among these drives evenly. I would do this so that when reading videos from these drives whilst doing video editing that would reference 4 or 5 videos from the trip of the day, I could get full sequential reads from the Array disks per video. In order to prevent spin-downs, my work around would be to set the disk spin down delay to that of 45 minutes, that way, it was harder for the drive to spin down, while reading from all the drives.
  11. So there is a big difference here... Your physical environment, and your virtual one. All things done within UnRAID are considered your virtual environment, and everything outside of that is considered your physicals. You can either setup UnRAID to have a L2 interface, of which you pass through as a bridge to your virtualized Palo Alto. (There wouldn't be much of a point in running a L2 within Palo if this is the case.) This will allow your Palo to communicate only on that physical L2 interface of UnRAID when trying to communicate with anything else on that same L2 interface in your physical environment. Perhaps a real Palo Alto with the same VLAN tagging for redundancy or whatever. Now lets say you have a virtual Check Point device and a virtual Palo both on your unraid, regardless of what physical interfaces are assigned in UnRAID, whatever bridge you passthrough to the virtual environments, you can create L2 interfaces within your CheckPoint and Palo Devices, and only devices on that same bridge (on UnRAID) in the same virtual L2 LAN will communicate. However, I believe any traffic destined to a network outside of UnRAID will get put onto UnRAID's physical configuration's interface when it is attempting to leave the UnRAID box itself. If your UnRAID is configured as a physical L3 with default tagging, then traffic will leave tagged as such. This type of configuration only separates the virtual traffic within the UnRAID box. Depending on what your scenario is, you could do either or both. It all comes down to your physical and virtual topology. LMK if you have any further questions, I can break this down further if needed. -Jockie.
  12. https://www.youtube.com/watch?v=LkW3niAWAHs https://forums.unraid.net/topic/50882-guide-custom-vm-icons-automatically-downloaded-and-installed-to-unraid/ So, you have several physical interfaces in UnRAID, you can set these to their own VLAN in unraid, and then assign the bridge to Palo. You can also edit the xml I believe to be a different type of interface, rather than inet. Otherwise, just put a managed L2 switch next to your unraid box, and trunk your interfaces to Unraid.
  13. Not exactly, the most recent post made by me I believe is the only thing seen on unraid's forum about Palo setup process. One thing to mention, that might not have been mentioned before is the licensing, if you are going to make this a legit license, you MUST not remove the UUID in your xml file for the device, as Palo Licensing is near impossible to move once established. Save a copy of it somewhere.