ljm42

Sorry, I'm still not clear : ) What version of Unraid is that screenshot from?

Unraid 6.12.2 has a different version of Docker, recommend upgrading

Please upgrade to 6.12.2, then wait 15 at least minutes before getting updated diagnostics (this gives Fix Common Problems time to run and flag issues)

What version of Unraid? If you aren't yet on 6.12.2, please upgrade

The go script in these diagnostics looks like this: #!/bin/bash # Start the Management Utility cp /boot/config/rules.d/99-usb-rules.rules /etc/udev/rules.d/99-usb-rules.rules chmod 644 /etc/udev/rules.d/99-usb-rules.rules udevadm control --reload-rules udevadm trigger --attr-match=subsystem=usb hdparm -W 1 /dev/sdi /usr/local/sbin/emhttp & Is that what you are expecting? If so, please reboot and then upload a new set of diagnostics so we can compare. Seeing this kind of stuff always makes me nervous, I'd suggest that you add comments explaining what all these commands do, perhaps including links to the forum post or guide you got them from. This will help you in the future if you forget why you added them : ) and it will help anyone who is trying to help you in your forums.

If extra packages are needed, you should create an "extra" directory on the flash drive and put the packages there, then Unraid will install them as it boots and you don't have to tweak the go script. Having said that, adding packages like this on your own is not really a good idea. You need to check for updates on a regular basis and keep the files current to prevent problems. Whatever you are using these packages for, it would be better to keep the base OS as stock as possible and find a Docker container for this functionality

I wouldn't say "highly likely", but "possible" : ) The thing is, the system does try to prevent problems here. For each piece of hardware that you want to bind to vfio for passthrough to a VM, the vfio-pci.cfg config file includes both the Vendor ID (8086:125c in the example below) and the PCI ID (0000:04:00.0) BIND=0000:04:00.0|8086:125c It is the PCI ID that can change when you move hardware around (or possibly after an OS upgrade). If the system can't find a piece of hardware with the specified Vendor ID at the specified PCI ID, then it simply skips that entry in the config file (so it is not bound to vfio) In theory, skipping a piece of hardware that moved to a new PCI ID shouldn't cause any issues. Deleting vfio-pci.cfg means skipping everything, and that works. But it seems that with certain hardware, if one item from the config is skipped and another isn't, that prevents the system from booting? I'm not sure how we could improve on this, but am certainly open to suggestions.

Please upload your full diagnostics.zip file (from Tools -> Diagnostics). It may have clues as to what is causing the issue.

Great! I was testing a theory on whether making a dummy change would clear out that old nic, good to know for sure it requires a manual update.

The issue is probably that both eth0 and eth2 are assigned to the same subnet with the same gateway. Fix Common Problems has been warning of this: Jun 26 11:00:24 Tower root: Fix Common Problems: Error: Multiple NICs on the same IPv4 network ** Ignored If you go to Settings -> Network Settings, how many Network Interfaces do you see? If you can see eth2, set the "IPv4 address assignment" to none and reboot. If you don't see eth2, make a dummy change to eth0 and hit apply, then reboot. Please upload your diagnostics afterwards so I can confirm the dummy change worked, if it didn't then we will need to manually edit a file. Note: once the networking issue is resolved, there is an issue with your GPU that is filling the syslog with: Jun 27 04:40:03 Tower kernel: radeon 0000:00:01.0: ring 6 stalled for more than 28698819msec Jun 27 04:40:03 Tower kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x00000000000012ef last fence id 0x00000000000012f0 on ring 6) We'll need someone else to help with that.

Sorry you are having trouble, please start your own thread and upload your full diagnostics. It gets very confusing trying to respond to multiple issues in the same thread.

You are getting call traces related to macvlan, see the release notes: https://docs.unraid.net/unraid-os/release-notes/6.12.0#known-issues

We need diagnostics from 6.12.1 to diagnose issues with 6.12.1. Having 6.11.5 can be useful for comparison, so don't delete this.

Go to Settings -> Network Settings and make sure a Default Gateway is specified for eth0. If that doesn't help we'll need diagnostics

It is possible this is a video card problem, and the system may continue booting in the background without updating the display. Be sure to check the webgui and SSH before assuming it is frozen. Either way, this sounds like something that will take a bit of back and forth and the announce threads are not great for that. When you're ready to try again I'd suggest starting a new thread and including diagnostics from 6.11.5 if you can't get them from 6.12.1.

Not a lot to go on here, but be sure to check the known issues in the release notes: https://docs.unraid.net/unraid-os/release-notes/6.12.0#known-issues

Does it display correctly if you reboot in safe mode? A plugin that is incompatible with the new dashboard will cause that. I thought we had caught them all. Edit: tracking this down is going to take some back and forth and an announcement thread is not great for that. Once you know whether the problem happens in safe mode or only in normal mode, please start a new thread in general support. Feel free to @ me

Nice troubleshooting The syslog is full of this, anyone have ideas? Jun 27 04:30:58 Dyon-unRAID kernel: i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 7f Jun 27 04:31:01 Dyon-unRAID crond[1519]: exit status 255 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

I'm not sure why the console would stop updating during boot, what happens if you press <enter> a few times? The syslog has call traces related to macvlan, that is likely why it crashed. See the release notes here: https://docs.unraid.net/unraid-os/release-notes/6.12.0#call-traces-related-to-macvlan

This is not a known issue, so I'm asking for a bunch of details to try and figure out where to focus. Is this a new Unraid install or did you upgrade from a previous version? If an upgrade, do you know what version you came from? Did any of the issues you have reported occur in that version or is it all new? Pick one of your shares that you don't mind sharing screenshots and directory listings for. Then go to the Shares tab and click on the specific share, and take a screenshot of all the settings. Also show the details of the SMB/NFS share settings if you can. What is creating the files? If a Docker container, can you show a screenshot of the container config that shows the exact paths that are being passed to the container? What are you using to read the files? If it is something like Windows Explorer, what user are you using to access the files? (the user should be listed on the screenshots above) Can I ask why you are choosing to use NFS to share with Windows? Have you considered using SMB instead?

The problem I was looking for isn't there. All good now?

You can take a photo if you want : ) Or you can redirect the output to the flash drive like this: cat /etc/nginx/conf.d/servers.conf > /boot/output.txt Then the "output.txt" file will be in the root of the flash drive

The issue is that you have two WireGuard configs that are using the same IP address. Assuming they are wg0 and wg1, run these commands wg-quick down wg0 wg-quick down wg1 Then run: /etc/rc.d/rc.nginx reload That should give you access to the webgui. Navigate to Settings -> VPN Manager and review wg0 and wg1 and make sure they are setup for different network pools and IPs before restarting the tunnels.

Please provide the output of the command: cat /etc/nginx/conf.d/servers.conf

coming soon : )