ljm42

Please retest in 6.12.2, it has fixes that should help with the issues mentioned here. If you continue to have issues we need diagnostics from 6.12.2 after the problem occurs. Note that it is difficult to help multiple people in a single thread because problems that seem related can have different solutions.

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.

This will be fixed in 6.12.2, but again navigating the webgui without at least a Trial license isn't really supported.

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.

It would probably be something similar to the other items starting with "network" here: https://docs.unraid.net/unraid-os/release-notes/6.12.1

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

Have you started your Trial yet? Looking at it, this page may throw an error if you don't have a license yet. The system isn't meant to be used without at least a Trial license.

Odd. Would you please go to Tools -> PHP Settings and enable "All Categories" of error reporting? Press Apply, then press View Log (it will open in a popup window) Then navigate back to Settings -> Management Access, does anything show up in the error window?

This is an issue with PHP 8, where they changed how they handle line breaks between email headers. When used in conjunction with sendmail, this causes the headers to be malformed. Thankfully there is a config flag ( mail.mixed_lf_and_crlf = On ) to revert to the previous behavior, this will be included in 6.12.2 Interestingly it seems that gmail patched their servers to accept the malformed headers from PHP8/sendmail, which is why I never noticed the issue during the RC phase. Other smtp servers don't accept the malformed headers and throw a 554 error instead.

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 : )