clay_statue

Members
  • Posts

    25
  • Joined

  • Last visited

Everything posted by clay_statue

  1. Is this because the default sata/sas ports available in the tower aren't usable by the unraid array? I was looking at the HP ProLiant m350 and the unraid thread about that one said that the native raid controller didn't work with unraid and you needed to basically make use of the pci-e slots to connect sata drives and bypass the raid controller Additionally I see that the card you are talking about only has two SAS ports internally. I am unfamiliar with SAS... how many drives can you run off that one card? Just two?
  2. I cannot access shares on unraid from my windows laptop. I have "remote access to LAN" and indeed my laptop can ping my unraid server and my router, so I do indeed have connection to devices on my LAN. I can also access my dockers webGUI's. The wireguard connection is working in every way *except* I cannot access my shares. Even if I type the network address into file explorer \\x.x.x.x\share it cannot access the share. I tried setting tunnels both with specified NAT port forwarding and going UPnP alternatively. No dice. Before OpenVPN was deprecated I was using it as a docker image and was able to get remote access to my shares no problem... so I dunno what's going on here? [SOLVED] Had to stop the array and add the wireguard network pool to Settings > Network Services > SMB > hosts allow = 10.253.0.0/24 After I did that I could manually enter \\serverip\share in File Explorer and then map the drive. Big success!
  3. I think this is the relevant part of the log file... Jun 22 14:07:16 FractalTower rc.docker: redis: started succesfully! Jun 22 14:07:53 FractalTower rc.docker: Plex-Media-Server: started succesfully! Jun 22 14:11:10 FractalTower ntpd[2153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jun 22 14:13:00 FractalTower root: Fix Common Problems Version 2021.05.03 Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application binhex-sonarr has an update available for it Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application nzbget has an update available for it Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application redis has an update available for it Jun 22 14:13:10 FractalTower root: Fix Common Problems: Error: Machine Check Events detected on your server Jun 22 14:13:10 FractalTower root: mcelog: ERROR: AMD Processor family 23: mcelog does not support this processor. Please use the edac_mce_amd module instead. Jun 22 14:13:10 FractalTower root: CPU is unsupported Jun 22 16:20:47 FractalTower webGUI: Successful login user root from 10.10.10.25 Jun 22 16:22:10 FractalTower root: Fix Common Problems Version 2021.05.03 Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application binhex-sonarr has an update available for it Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application nzbget has an update available for it Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application redis has an update available for it Jun 22 16:22:19 FractalTower root: Fix Common Problems: Error: Machine Check Events detected on your server Jun 22 16:22:19 FractalTower root: mcelog: ERROR: AMD Processor family 23: mcelog does not support this processor. Please use the edac_mce_amd module instead. Jun 22 16:22:19 FractalTower root: CPU is unsupported
  4. Fix Common Problems threw this rather alarming error and kindly suggested that I post my diagnostics in the forum for some help figuring out the hardware issue. Any insight would be appreciated... fractaltower-diagnostics-20210616-0052.zip
  5. SpaceinvaderONE's video on setting up mysql database for use by docker containers
  6. Cool and neat. Now I can run phoenix miner at the server level rather than inside my windows VM. Of course I lose the use of my GPU for actually powering my monitors in such scenario but using a thin client and running the windows VM (my daily driver) headless would get around that.
  7. I was fidgeting with my IOMMU groups trying to free up some USB ports and unbeknownst to me, unRaid had taken control over my quad-port nic that usually get stubbed and passedthru to my pfSense VM. This meant that my cable modem was rawdoggin' straight to my server for a short while (less then 10 minutes) before I noticed what was up and unplugged it for the remainder of the tinkering. How concerned should I be? I don't have unRaid very well locked down at all because it's supposed to be sandboxed safely in my LAN behind pfSense.
  8. Excellent. I was worried Google had shunted me to another dead-end thread (as it is wont to do), but this looks like the solution. Interestingly I had this exact same problem with the my Radeon 5700XT GPU, which has a different function for graphics and sound on the same bus. The xml file automatically puts each function on a different bus, which in essence is splitting single device that isn't supposed to be split. That's what's happening to our nic basically. For a more thorough explanation of this xml config issue see SpaceInvaderOne's video about advanced GPU passthrough techniques (under five minutes). Although this video is about GPU's, the issue and the solution are essentially the same.
  9. OMFG... this is the magic bullet that finally solved my wonky VM issues! I will be riding this wave of contentment and joy every time I get a clean shutdown from a VM for years to come. I've been having a heck of a time trying to get windows 10 to shutdown clean, it had been making unRaid freeze. Fortunately I could still execute a graceful shutdown because I deliberately left my keyboard on a non-passthrough USB controller. So although I was frozen out of the webgui and running headless, I could still blindly log into the terminal and type "powerdown". That probably saved me from hundreds of hard reboots and god knows how many hours of parity checks. For dunderheads like me who are still lost in the weeds and are desperately seeking further clarification I will spell it out in the excruciating detail I wish that I had... 1) Check your IOMMU groups for the number 1022:149c or 1022:1487 attached to a USB controller called "starship/matisse". If you are trying to pass that through, that's (at least part of) what's causing boot and/or shutdown problems with your VM. solutions... 2) Don't stub it and don't passthrough the entire controller, instead passthrough individual devices. This didn't work in my case because my Focusrite external sound card was giving me demonic sound unless I passed through the whole USB controller. (I also fell down the rabbit hole of fidgeting with MSI interrupts to no avail) or.... 3) Edit the /syslinux/syslinux.cfg file on your unRaid USB (don't use notepad, use notepad++ or wordpad if on windows). You will see the various unRaid boot menu options listed in there. Under the first menu option will be "append blehblehblehstuff initrd=/bzroot". That's where you need to put "pcie_no_flr=1022:149c,1022:1487" without the " ". If you typically boot from another menu option, put it there instead. In my case the file looked like default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label Unraid OS menu default kernel /bzimage append pcie_no_flr=1022:149c,1022:1487 vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot label Unraid OS GUI Mode and so on... This worked to get windows shutting down nicely. However my Ubuntu VM was still not shutting down clean, even after appending the syslinux.cfg file. That's because this bug is a quirk between the linux kernel and this specific USB controller. Ubuntu was still flubbing the shutdown because it has more or less the same kernel as unRaid. So the final step is to get Ubuntu to behave itself... 4) Edit the Kernel Boot Parameters in /etc/default/grub by moving the cursor to the line beginning with "GRUB_CMDLINE_LINUX_DEFAULT" then edit that line, adding your parameter (pcie_no_flr=1022:149c,1022:1487) to the text inside the double-quotes after the words "quiet splash". (Be sure to add a SPACE after "splash" before adding your new parameter.) Click the Save button, then close the editor window. 5) sudo update-grub 6) restart ubuntu The earlier comments in this thread and the following three links are the source of everything I just described: https://forum.level1techs.com/t/attention-flr-kernel-patch-fixes-usb-audio-passthrough-issues-on-agesa-1-0-0-4b/151877 https://old.reddit.com/r/VFIO/comments/eba5mh/workaround_patch_for_passing_through_usb_and/ https://wiki.ubuntu.com/Kernel/KernelBootParameters
  10. So I watched the video but this apparently only works when primary vdisk location is set to "auto", in which case increasing the size is fairly straightforward. How do you increase the size of a manually assigned vdisk?? Near as I can tell if you set a manually assigned vdisk there is no way to increase it's size and the only way to increase capacity is to add a second vdisk (D:/ drive).
  11. So every time I shutdown a Windows VM, unRaid crashed and became inaccessible from the webGUI. I went through every "solution" I found available to me. Legacy vs UEFI, manually adding and altering the registry to allow MSI interrupts, uninstalling various device drivers... EVERYTHING. Turns out there is an issue with AMD GPU's when using double monitors. If both monitors are connected via DisplayPort things can get buggy. However, if you use one DP and one HDMI then somehow this works out nicely and VM's can shut down clean without crashing unraid. FYI The GPU in question was the Sapphire Pulse 5700XT
  12. Don't you hate when you finally find the thread with your exact issue and it just ends without a solution? I have a Windows 10 VM with GPU passthrough that shuts down cleanly no problem. However the Windows 10 VM that has GPU passthrough AND nvme passthrough crashes unraid. I can still do a graceful powerdown from the command line, because despite running headless unraid still accepts keyboard input so type "root / password / powerdown" will shutdown the system without having to do a hard reset. However it would be nice to figure out what about nvme passthrough is causing it to crash unraid when you shutdown the VM.
  13. Bingo! It was the card reader. This thread is solved.
  14. Yea, okay it's not the janky network setup. Even with a direct patch cable to the router it won't take an IP. I don't know if what is happening is because dhcpcd is screwing up. I checked /etc/dhcpcd.conf and swapped clientid for duid to see if that would help but it didn't. I know there is an issue with linux and the realtek chipset of my mobo's onboard LAN port. I solved it in Manjaro by blacklisting the driver r8169 in /etc/modprobe.d and installing an older driver r8125. However I saw that unraid uses the r8125 driver and it was working so I am skeptical that this is the issue, but you never know... Edit: I created an unraid trial USB using the newest unraid 6.9 Beta and that worked. The beta version has no trouble taking it's IP from the router and connecting to the internet like it should. The challenge now is to figure out how to update unraid on my existing flash drive without a working network interface. Or rebuild my system from scratch using the new trial USB and adding existing array to the new system without clearing them for the new arry....
  15. I am yet to have a wired connection to the internet for my tower. As an interim solution I am using a wifi extender to provide an ethernet port for the tower. I have 192.168.0.100 reserved on the router (static DHCP?) for unraid so it will always gets assigned the same IP whenever it boots. I don't know why unraid is refusing it, I'll try removing the reserved IP and just let it assign whatever it wants to see if that helps... This could be some something to do with my janky network setup, although it has been working fine for a few days (albeit slow). I think I need to go buy a 100ft ethernet cable and plug unraid directly to the router temporarily and see if it calms down the DHCP shenanigans. ps... This seems to be the crux of the issue Nov 8 06:57:27 FractalTower dhcpcd[1919]: br0: soliciting a DHCP lease Nov 8 06:57:27 FractalTower dhcpcd[1919]: br0: offered 192.168.0.180 from 192.168.0.1 Nov 8 06:57:32 FractalTower dhcpcd[1919]: br0: probing for an IPv4LL address Nov 8 06:57:37 FractalTower dhcpcd[1919]: br0: using IPv4LL address 169.254.111.46 So the router and unraid are actually talking to each other, but for some reason br0 refuses the IP that it's offered and just assigns IPv4LL instead. Why is br0 refusing the DHCP server?
  16. I was in the middle of setting up my first Windows VM when unraid suddenly decided it doesn't want to play ball with my router and rejects DHCP. I now get the default 169.xxx.xxx.xxx IP that occurs when it fails to obtain a working IP. It was working fine the last few days and then decided to stop... go figure. I can boot into my bare-metal Manjaro and use the eth0 without any issues, so I know it's not a hardware problem. I've tried assigning a static ip in /boot/config/network.cfg (as well as turning on/off "bond" and "bridge" in every combination imaginable) but so far nothing is working. fractaltower-diagnostics-20201106-0820.zip
  17. I searched the zip file for "sdb" and copy/pasted the relevant text to the forum because I thought it would be helpful to eliminate the extraneous information unrelated to the issues. Here's the whole shebang for you to peruse at your leisure, should you be so inclined. fractaltower-syslog-20201107-0636.zip
  18. That was the file I downloaded from under Tools>Diagnostics that ChatNoir directed me towards.
  19. This is the only relevant part of the syslog.txt that mentions sdb in anyway Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: [sda] 60088320 512-byte logical blocks: (30.8 GB/28.7 GiB) Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: [sda] Write Protect is off Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Nov 6 06:58:17 FractalTower kernel: sda: sda1 Nov 6 06:58:17 FractalTower kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Nov 6 06:58:17 FractalTower kernel: scsi 1:0:0:0: Direct-Access NORELSYS 1081 0 PQ: 0 ANSI: 6 Nov 6 06:58:17 FractalTower kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0 Nov 6 06:58:17 FractalTower kernel: sd 1:0:0:0: [sdb] Attached SCSI removable disk Nov 6 06:58:17 FractalTower kernel: floppy0: no floppy controllers found
  20. I hate that the google search leads to this thread at the top of the listing....
  21. So sdb is listed as a 0 B greyed out, unmountable mystery drive with what looks like a placeholder ID. Where did it come from? How do I get rid of it? All my drives are otherwise accounted for and listed under the "Main" tab of the web gui. I tried df, fdisk, lsblk, and parted -l commands in the terminal and none of them make any mention of sdb... Is this a ghost? Is my system being haunted by a drive from a previous era?
  22. I last mucked about with linux way back when debian was the hot new distro, well before it spawned ubuntu. I had a friend was a sysadmin during the heady days before the dotcom bubble burst and he was always showing me cool new things that the gnome desktop could do at the time. It looked like magic compared to the locked down and stodgy stock Windows environment. So I did my best to "get into it" and managed to blunder about for a while until inevitably retreating back to the safety and comfort of Windows. In the 80's, French was mandated by the Ontario school system. Before my family moved out of the province when I was ten years old I had achieved the mighty level of Grade 4 French. Now, pushing 40, my French is basically zilch but I have a passing familiarity with common phrases. That is basically my level of linux literacy... slightly greater then nothing but effectively zero. I can safely back my way out of a vi text editor, but having to actually edit a text file with it is like walking across a beach wearing swimming flippers... I can do it, but it is slow and awkward. Armed with this minimal knowledge, I jumped into Arch linux via Manjaro after two decades plus of solid Windows usage. The KDE desktop was luxurious. I enjoyed it enormously. Got my main go-to apps set up with a predictable amount of headbanging and n00b frustrations... but I was doing it. I was swimming again. In my tinkering I inadvertently courted disaster. It started with the mouse cursor. I set it to some custom cursor, but it was only so over app windows. When it hovered over the desktop it reverted to its default appearance. A minor blemish. Trivial. But I picked at it more and more... trying to fix it and falling short. Eventually I scrambled my KDE desktop settings and would have to go and reconfigure it all from scratch. Rather than deal with this minor inconvenience I tried to revert to a saved image of my system using TimeShift. Well... something happened. I broke grub bootloader somehow. Now I could only boot into Windows. Manjaro still existed on my disk, but I couldn't get to it. Eventually I figured out how to use my live USB and chroot into my native partition so I could muck about trying to undo the damage. I must have spent 15 hours on this, trying everything. In my struggling all I managed to do was tighten the noose and eventually I couldn't even boot into windows. It was at this point that I reluctantly gave up and just nuked my whole drive with a clean Manjaro install. I picked at a minor blemish until it festered into a rotten, gangrenous sore and empathy demanded the host had to be put out of its misery. Fortunately this was all tinkering done on a fresh PC build (yay covid time hobbies) so all my personal data was still safely on my crusty, trusty Windows laptop. My aforementioned sysadmin friend (who has since moved out of IT) recommended strongly encouraged that I use Windows with VMware to tinker about in linux after hearing of my trials and tribulations with inadvertently killing my bootloader slowly over a ten hour period. Deep down, I knew he was right. I am an incompetent custodian of a linux system. Deeply unworthy of root. Windows with VMware fit my usage needs and experience level perfectly. It would give me a solid base with familiar ol' Windows and whatever linux distro I wanted safely sandboxed away from all the mission critical components of the system's architecture. Somehow I don't wanna run bare-metal windows anymore. Call it pride, or hubris, or whatever... a sudden, irrational predilection towards techno-masochism perhaps. Needless to say it was deeply engrained; I wanna install linux bare-metal as a hypervisor and use kvm, qemu, libvirt to run VM's... *because it's just so neat and cool*. There's a certain invisible aesthetic to doing it this way that I don't have the expertise to fully comprehend or possibly hope to express. But I don't trust myself to do it. I just don't have the chops to pull it off, at least not at this moment. Like learning to unicycle along the edge of a cliff, always courting disaster. There has to be another way. What I needed was a linux-based VM manager, compiled and configured from the ground up by wise and diligent geeks whose level of wizardry is lightyears ahead of my own. Surely that must exist? That's when I encountered 'the usual suspects'... proxmox, unraid, and freenas. Except these are all well regarded OS's for NAS, which sort of threw me off a bit. My day to day usage is so far away from what NAS is supposed to be for. I have absolutely no need for a server in my life. A lot of forum posts I encountered poo-poo'd on the idea of using any of the usual suspects for a desktop PC and I was swayed by these sparse opinions. "Why pay for this when you can do it yourself with any linux distro you want for free?" was another common sentiment. But to me this sounds like saying "Why go pay $30 for pasta at a high-end Italian restaurant when I can make spaghetti at home?" I know the pasta I can get at the high-end Italian restaurant will be far superior to whatever I can conjure myself. Sure, if you are an experienced chef then this type of sentiment may ring true, but I am under no delusions about my linux - or cooking - ability. All credit to SpaceInvaderOne. Five minutes into his first video I knew I had found my new home. I know a lot of folks end up here from LinuxTechTips, but for me it was seeing SpaceInvader working step by step through the various processes of unraid and explaining the concept behind parity drives that really convinced me. The power of having all this in a simple, browser-based GUI = mind blowing. The amount of google time I would need to spend researching all the command line arcana needed to use KVM/qemu/libvert and breakup the IOMMU groups to do a GPU passthrough would be significant. Not impossible, but certainly daunting for somebody with my level of expertise. Without integrated graphics on my CPU, I'd also need to buy a secondary GPU for the host (which seems redundant). Running unraid headless isn't just possible, it's baked in by default. I know just enough to recognize the beautiful simplicity masking these deeply complicated and perplexing rabbit holes. The Mandelbrot also looks pretty basic until you start to zoom in and see what it's really about. I'm pre-clearing my HDD's for the array as I write this, which is my excuse as to why its so long.