Hi All,

As above I can hit the page every time but when I log in it just sits on a blank screen. It’s the same when I try logging in using tailscale. All my docker containers are up and running and can be accessed via webpages. I’m running the latest stable update 7.3 I think .

The issue just seems to be with the GUI. I can’t seem to ssh into it either so the only way to get it back is to hard reset it, Obviously this is not ideal and it might work for a day or two before we are back the the start.

I also have a 2.5gb USB to Ethernet adapter I want to use. Is it possible to disable the onboard NIC on the GUI and configure the USB one with the same IP so I don’t have to change anything else?

Thanks In advance.

You should be able to install the USB NIC, make it eth0 in Settings - Network Settings - Interface Res, then reboot for the changes to apply, and it should start using it instead.

1 hour ago, JorgeB said:

You should be able to install the USB NIC, make it eth0 in Settings - Network Settings - Interface Res, then reboot for the changes to apply, and it should start using it instead.

I installed it and booted the server up. It picked it up as 2.5gb but it was set as eth1. I rebooted and disabled the built in NIC in the bios and configured the USB on with the correct IP. Eth0 is now using the USB NIC but its only 1gb.. Any ideas?

Edited July 29Jul 29 by Smokie

I have the NIC running at 2.5gb, I had to add ethtool -s eth0 speed 2500 duplex full autoneg on to the /boot/config/go

Now if anyone can help me on why the GUI becomes unloadable that would be great. I’ll watch it with the 2.5gb Nic to see if it happens again

Web page became unresponsive again and it stopped replying to a ping. I rebooted and I am back, Download the diagnostics and attached if anyone can let me know what’s wrong>

battlestar-diagnostics-20260729-2107.zip

Could be a browser issue. Have you tried clearing the browser cache and even a different browser?

Don't see any obvious issues logged, but there are some strange IPMI related errors. Post new diags when it happens again to see if they are still there

10 hours ago, JorgeB said:

Don't see any obvious issues logged, but there are some strange IPMI related errors. Post new diags when it happens again to see if they are still there

Will it keep the diags if I have to hard reset it? If it goes I normally can’t get access. Is there a command to run from ssh that will create and download the diags?

You can enable the syslog server.

On 7/30/2026 at 6:54 PM, JorgeB said:

You can enable the syslog server.

Does the syslog server not need to send the diags to another machine? I have a old synology NAS i could probably use

I just rebooted it and it took a while to come back up. She’s replying to a ping and the webpage loaded at first now it wont load and I can’t ssh into it. Back up now with a hard reset

8 hours ago, Smokie said:

Does the syslog server not need to send the diags to another machine?

You can set it to save the logs to a local share.

So I have set up the Syslog server and things have been going on for the last few days. I logged in today to try start a vm and when I pressed the vm tab it failed to load. I opened a new browser and could go to the apps tab no problem. Tried the vm tab again and it wouldn’t load. I ssh’d into it and rebooted and it said it was rebooting but stayed replying to a ping.

I had to hard reset it again so can anyone tell me what logs in the syslog I can provide to try and determine the issue?

syslog is a single text file. Zip the latest syslog from wherever you configured syslog server to save it and attach to your next post in this thread.

Also

On 7/30/2026 at 1:14 PM, Smokie said:

Will it keep the diags if I have to hard reset it? If it goes I normally can’t get access. Is there a command to run from ssh that will create and download the diags?

The word Diagnostics in any post on the forum is automatically converted to a link to the documentation that explains how to get diagnostics, including from the command line.

Next time it happens before rebooting it might be useful to see the result of this command line:

df -h /

Hi Again,

So I have downloaded the logs for today. I hard reset the server about 16:20 to make it easier to narrow down.

Hopefully someone can see what’s wrong and thanks in advance

all_2026-8-11-20_47_26.csv

Post a screenshot of your syslog server settings.

The only thing in that syslog is spam related to the IPMI like this:

08/11/2026,19:46:16,Error,BattleStar,kern,kernel,"x86/PAT: ipmiseld:7417 map pfn expected mapping type uncached-minus for [mem 0xbc3ac000-0xbc3acfff], got write-back"

There's nothing else.

I ran the logs through Claude and this is what it came back with.

All the log data is from today, 08/11/2026. Let me pull everything around the 15:30–16:30 window to see what was happening leading up to and during the freeze.

That 15:30–16:30 window is almost entirely filled with repeating ipmiseld / IPMI SDR cache errors — noise unrelated to the freeze. Let me strip those out and see what else is happening, especially right at 16:00–16:20.

That gap is the smoking gun. Let me verify what’s happening in that silent window, and pin down exactly what triggered it.

Confirmed. There’s no nginx access logging at all after 15:42:24, and the next successful webGUI login isn’t until 19:35:07 (well after the reboot). That’s exactly the signature of a hung GUI.

What happened

15:44:42–15:46:16 — A VM using GPU passthrough was being started or stopped, and the NVIDIA GPU (0000:07:00.0) was being handed back and forth between vfio-pci (VM passthrough) and the host’s nvidia driver. You can see the classic passthrough dance: driver unload → VGA arbitration change → vfio-pci reset/rebind → nvidia-drm reload.

15:46:17 — Right in the middle of that handoff, the kernel hit a NULL pointer dereference (Oops) inside the NVIDIA kernel module, specifically in nv_audio_dynamic_power, triggered by the qemu-event process (PID 43042) — i.e., a QEMU/VM-related event thread. This is a known category of bug where the NVIDIA driver’s audio power-management code chokes during a GPU driver reload/rebind cycle.

15:42:24 onward — nginx (which serves the web GUI) never logs another request after this point. No more webGUI logins, no more HTTP activity — until 19:35, well after your reboot.

15:49:58–16:22:00 — Only automatic background events (emhttpd spinning down idle disks) appear — the kind of thing that doesn’t require the GUI or user interaction — and then silence in terms of anything web/GUI related until you rebooted.

Root cause

A kernel-level crash in the NVIDIA driver during a GPU passthrough VM start/stop, which wedged the graphics/DRM subsystem badly enough to take the web GUI down with it, even though background array processes limped along a bit longer. This is a well-documented Unraid pitfall with NVIDIA GPU passthrough — the audio-function power management path in the driver is fragile during rapid bind/unbind cycles.

What to check/try:

• Which VM uses that GPU (07:00.0) for passthrough — was it starting or stopping right around 15:44–15:46?

• Update your NVIDIA driver plugin version (this bug class gets patched periodically)

• If you’re passing through both the GPU and its HDMI audio function, try binding the audio function to vfio-pci at boot (via vfio-pci.ids=) instead of letting it bounce between host/VM — this specific crash is in the audio power path

• Check the VM’s XML for <hostdev> audio device config

Want me to pull the full stack trace/module list into a text file for you to reference when filing a bug report

I the decided to pass the HDMI audio from the GPU through to the VM and Unraid failed to load. I had to go into safe mode and unbind to get back up and running

38 minutes ago, Smokie said:

I ran the logs through Claude and this is what it came back with.

That's a good idea to filter out the spam, and it does look to me to be GPU-related.

This is getting out of hand now lol.. So I had started up my VM earlier today and played a few games. Shut it down and made sure that the GUI was working etc etc.

I logged in just now and the first thing I noticed is that on my dashboard it was not showing my docker containers or my VM’s, The box they should be in was just blank. I logged into the Immich webpage and uploaded some photos from my phone and then decided to give it a reboot. It took a while to come back up and I actually thought that it hadn’t but I could log into any of the docker containers without issues. The GUI eventually loaded but when I logged in I just get a blank screen. Same with different browsers on different machines. After a few minutes it will load again and I can try log in again but its just the same, Blank screen.

I can’t SSH into it either for some weird reason.

I have attached the log files for all of today if anyone can try pinpoint what the issue is?

Thanks

all_2026-8-12-21_27_49.csv

Log continues to be spammed; it's not easy for a human to analyze like that. If you cannot stop that IPMI related spam, you can try an LLM again, it can easily filter those.

Is the IPMI spam related to the GUI crashing? Can it be disabled? Surely IPMI spam like this should not be happening? I’ll run it through Claude again and see what it narrows down

2 hours ago, Smokie said:

Is the IPMI spam related to the GUI crashing?

Mostly likely not, it just makes the logs very difficult to check.

2 hours ago, Smokie said:

Can it be disabled?

Not sure; don't remember seeing a similar issue before, an IPMI firmware update may help.