diarnu

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

5 Neutral

About diarnu

  • Rank
    Newbie
  1. Even in that crazy long post, I forgot to add something. After first installing the plugin, there were more options listed in the dropdown boxes for CPU temp and MB temp on the settings page. Temps from coretemp and i5500_temp modules in addition to the temps and fan speeds from the w83795adg module. But for some reason those only showed up the first time I ran thru the setup. I'm not really interested in using the temps from those modules, so its not a big deal to loose them, but its weird that they showed up initially and then sort of permanently went away. So I thought it might
  2. Hey guys. I too built my unraid server around a SuperMicro motherboard. In my case, the X8ST3. And I too, had the strange issue with sensors suddenly disappearing from the settings page for this plugin. Installation went fine, sensor detection went fine, loading the modules went fine. I could select sensors for CPU temp, MB temp, and array fans too. But upon clicking the APPLY button, the sensor selections all became "Not used" and the data was no longer displayed along the bottom of the browser window or on the dashboard. Weird. Removing and re-installing the plugin di
  3. Hey guys. More recent thread on this topic here. The short version is that Bob1215 had it mostly right. You may or may not need to install syslinux per steps 6 and 7 in Bob1215's instructions, and things work better if the USB is unmounted (NOT ejected) between steps 8 and 9. Or you can just run the script twice back to back as mentioned in step 10. Also, itipmi edited the manaul method instructions in the getting started section of the wiki with slimmed down version of those steps. A few folks above mention getting the script to work by renaming the script
  4. Just to add to the discussion: I was tinkering with this yesterday as well, and ran into issues. After finding this thread, I tried the sequence of steps that jonathanm posted above and itimpi added to the wiki, and those worked fine. 2 notes: I found that if I forget to unmount the USB, then just running the script a 2nd time also did the trick. Seems like the 1st attempt unmounts the drive but then fails, and the 2nd attempt succeeds on the unmounted drive. I got the same results whether running the script as "sudo bash ./make_bootable_linux" or leaving bash out and
  5. Cool, I will add what I posted here to that thread. They also posted a series of steps that work with the script right out of the box (or out of the zip, I guess?) in that thread, and updated the getting started section of the wiki with those steps too. For those that find this thread before the thread linked above or the wiki, the steps are: Format the entire USB as a single FAT32 partition, label MUST be UNRAID (otherwise the script will not find the USB) Extract archive to mounted USB drive copy make_bootable_linux back to the
  6. I know this thread is a bit old, but I was just tinkering with this today and got the same error. I managed to get it working with 1 small edit to the script. That last line is indicating that the script is failing because sudo sees the path /tmp/UNRAID/syslinux/make_bootable_linux.sh without a command, and doesn't know what to do with it. Or at least I think that is what is happening. To fix the issue, open up the script with your favorite text editor, and find the line below (towards then end of the script): sudo /tmp/UNRAID/syslinux/make_bootable_linux.sh $TARGET
  7. Hey jowi. The nest app on "normal" wifi would not be able to communicate with the thermostat on another subnet by default. You could add firewall rules to allow the 2 clients to talk across subnets if you wanted that. But by default, pfsense does not allow traffic between different subnets. For what its worth, I recently went down a path similar to the one you seem to be headed towards. I wanted different subnets for IoT stuff, and for guests when they visit, and maybe for game consoles and set-top boxes to bypass my VPN, etc. It started to get kinda crazy with all
  8. Hey jowi. So from your diagram, it looks to me like the goal was to keep WIFI and LAN clients separate. If that is not the case, the simplest solution to get the WIFI and LAN clients to talk to each other is probably to move the AP to the switch. This has the added benefit of only needing NAT and firewall rules to route clients thru the VPN on 1 interface (LAN) rather than 2 (LAN + WIFI). You could keep the AP on a separate interface and use firewall rules to pass traffic between the subnets, but that seems way harder than just moving the AP to the switch.
  9. @Living Legend: Hey, I was looking at my server this afternoon and realized I was a bit off in my last post. For my 4 port NIC, each port is actually in its own IOMMU group. So that isn't the issue. However, the method of passing the PCI device to the VM relies on the PCI ID, which is of course the same for all 4 ports of the NIC, since they are all on the same PCI device. So my details were a bit off, but end result is the same: you had it correct, its an all or nothing situation with a multiport PCI NIC.
  10. I am a bit confused about how pfsense, the binhex delugevpn docker, and PIA port forwarding all work together. The introductory pfsense video discusses a few PIA VPN connections configured in pfsense, 1 of which (Germany, which was a port-forward enabled PIA server at the time the video was made) is used for downloads and such. However, the slightly older delugevpn docker setup video discusses using the VPN connection built into that docker. So, if all of the VPN connections are made in pfsense, how does the deluge docker know which port is forwarded from the PIA ser
  11. @Living Legend: I think you have it correct. I have a similar setup in my unraid server. I pass the entire 4 port NIC to my pfsense VM. I don't think the 4 ports can be split up very cleanly between VMs and unraid, as all 4 ports are in the same IOMMU group. I suppose you could try to break that IOMMU group up (as spaceinvader1 mentions in video 3, I think) but that may or may not work. In my case, my server has another ethernet port on the motherboard, so I use that for unraid.