Jump to content

joelones

Members
  • Content Count

    517
  • Joined

  • Last visited

Community Reputation

3 Neutral

About joelones

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, I'm just curious if anyone with strong networking skills can explain to me the following setup - why it works and why it doesn't. I have a quad nic: 1 port (untagged 3.x subnet vlan1) and second port (vlan 10) as below both connected to an old cisco switch: My docker network as follows: Concerning my question, as I said eth1 is connected to a cisco switch and if I select the port mode to access and allow vlan 10, I am not able to ping anything on br1.10. However, if I set it as a trunk port to allow vlan 1 and vlan 10 - it works. I would not expect to set it to a trunk port and I clearly only want vlan 10 traffic flowing. Perhaps I'm confused or something.. Thank
  2. Thoughts here? I've upgrade from Kypton to Leia and cannot reliably get the kodi headless to update the db via json rpc VideoLibrary.scan method anymore. I have the advancedsettings.xml that was posted earlier in this thread and a passwords.xml that has credential information for the smb path/username/password. From what I remember the initial sources were configure with another client and then subsequent updates commands would work with this headless docker, it no longer works. I just setup all my other clients to Leia and noticed that I had to change the smb max version to v3 to get them to access unRAID smb shares. Like so: <setting id="smb.maxprotocol">3</setting> <setting id="smb.minprotocol" default="true">0</setting> Of course this was done via the GUI. Not sure if this has to be on this headless as well. I know it's in guisettings.xml but every time I try to change to the above on headless it reverts back to: <setting id="smb.maxprotocol" default="true">3</setting> <setting id="smb.minprotocol" default="true">0</setting> Even if I stop the docker, edit and restart. Odd...
  3. I need to pass the following device to a Hass OS VM (Home Assistant): "Texas Instruments TI CC2531 USB CDC (0451:16a8)" The device is a USB CC2531 dongle flashed with zigbee2mqtt firmware which the VM sees as /dev/ttyACM0. Without the dongle passed the qemu-system-x86 process for this VM consumes approx 25% cpu, when attached to the VM the cpu rises to 150%. I really don't have any pertinenent logs or any. I'm on 6.8 stable and the VM is using Q35-2.11. Any advice thoughts here will be greatly appreciated.
  4. @bastl So I updated to 6.8 stable and decided to try this workaround. I did try the Skylake emulation for my AMD FX8320 and it didn't quite seem to like it very much and gave an unsupported CPU error when I tried to start the VM. I guess my CPU is either too old or lacks the instructions to emulate Skylake properly. Maybe I need to model an older Intel CPU, like Sandybridge or something?? I know my model is a Opteron_G5. I had no choice but to opt for Emulated QEMU64 mode, hopefully the lack of AES-NI won't impact overall CPU performance with respect to VPN usage. EDIT: I seem to have gotten pfSense to boot with AES-NI on my AMD wit this: <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>Opteron_G5</model> <vendor>AMD</vendor> <feature policy='require' name='vme'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='tsc-deadline'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='arat'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='bmi1'/> <feature policy='require' name='mmxext'/> <feature policy='require' name='fxsr_opt'/> <feature policy='require' name='cmp_legacy'/> <feature policy='require' name='cr8legacy'/> <feature policy='require' name='osvw'/> <feature policy='disable' name='rdtscp'/> <feature policy='disable' name='svm'/> </cpu>
  5. Ok thanks. I may just wait for 6.9 at this point knowing that we'll have to upgrade back to the v5 kernel anyway. Hopefully the GSO bug is squashed as well, but this is definitely a viable option at this point thanks to your testing.
  6. @bastl well done! I'm assuming the "Intel Skylake CPU" option is the way to go to keep AES-NI compatibility? Any downside to that? I'm on a rather old AMD FX8320 CPU.
  7. I went from rc7 to rc9 and my pfSense VM does not boot. Had the "GSO" type bug prior. Passing in a Intel Quad NIC to my pfSense VM. Thoughts here? Guess it's a known thing:
  8. I've upgrade to v6.8rc6 and I see a question mark icon for a custom docker, can you please elaborate how to set it? I have an icon file in the folder: /boot/config/plugins/dockerMan/images as 'custom-program_name-latest-icon.png' matching the local repository/image of 'custom/program_name'... EDIT: never mind, pointed the icon url to a local php server...
  9. Thanks for your help, and yeah I do have a pfSense backup (physical) box so that's not the problem in that regard. More so, it's everything else that runs on unRAID (dockers, etc...) that's the problem, and fear that'll I hose something in the process. But I do backup the flash before proceeding so in every case I tried, I was able to revert back to 6.5.3. EDIT: Solved this by replacing an older PCI dual-nic card with a PCI-E quad nic and removing my Radeon HD 6450 PCI-E for a PCI rage cheapo GPU for basic console.
  10. I mean, it appeared to be the case. But honestly, I did not run it for too long without bringing up the pfSense VM, so I cannot be 100% certain that it doesn't freeze with pfSense off. But it has been my experience that it tends to freeze almost in a short amount time once pfSense starts. Gonna probably pull out the legacy PCI NIC and get another PCI-E Quad NIC and use it instead. Perhaps something changes. Although I'm gonna have to pull out the dGPU and hope that this mobo boots with no GPU.
  11. I did a memtest and also swapped the dimms with 4 known working ones, same issue. Further info:
  12. Thanks, but that's exactly what I tried today, 6.8rc5 after experiencing the same with 6.6.7/6.7.x.
  13. Not individual NICs, it's a quad NIC ( single card ) passed-through via the append command boot argument (vfio-pci.ids=1b73:1100) to the pfSense VM. The passthrough seems to work as it did prior to the upgrade, the VM boots with quad NIC as it did before. Nothing has changed really. I don't think I'm gonna get to the bottom of this unless I start swapping removing hardware and observing whether it crashes it or not. Appears to be software / kernel related. Something about this config that bothers newer kernels, just frustrating that it freezes without the slightest of indication of what it could be in the log.
  14. Right, thanks for the reply, exactly what I tried to do short of removing hardware. I stopped both docker and VM managers and I believe I only noticed the freezing when I brought back up the pfSense VM with the passed through quad nic.