kmwoley

Server not booting after power down due to ASUS FlashBack? Has anyone encountered issues with their computer not (re)booting after a clean power down? My machine is rock solid, running great. But if I attempt to restart it, it won't restart on its own... and will only power back on under certain conditions. When I initiate a reboot from the OS (or from the BIOS), the system will power down, everything shuts off, hard drives stop spinning, no output on HDMI... but not reboot as expected. The BIOS FlashBack LED will start blinking slowly on the motherboard. The power button will not shut it off, nor will it turn it on. Same thing happens if I issue a shutdown command - the OS shuts down just fine and the BIOS FlashBack LED starts to blink. As long as it's blinking the power button will do nothing. The only way to get it to boot is to cut power at the power supply. If I turn off the power supply, wait until the FlashBack LED stops blinking, then turn back on the power supply, it will boot on it's own if the BIOS setting to "Restore AC Power Loss" is set to "Power On". However, if the BIOS is not set to power on when power is restored, I have to turn on the power supply and immediately hit the power button (within a second). If I don't hit the power button fast enough, the FlashBack LED starts to blink and the machine is stuck again. There's a thread here for a different motherboard showing a very similar experience - he has a video showing that the FlashBack BIOS tool would try to install the BIOS in a loop if he puts a USB stick with a valid BIOS in his motherboard. I saw the same thing on mine. Crazy enough, he solved his issue by desoldering the ASUS FlashBack button from his motherboard. Kinda points to a fault with that button on the motherboard, which makes sense given the behavior I'm seeing. The more I look, the more I see people having issues like this with all sorts of ASUS mother boards. Question - Bios flashback button, is there a way to disable it?? | Tom's Hardware Forum Is there a way to disable bios flashback button? : r/ASUS ASUS TUF Gaming B650-Plus - flashback light still... - Republic of Gamers Forum - 1055840 It would be nice if there were a BIOS option to disable the flashback button, but I'm not seeing it. I have not yet contacted ASUS; I probably should, but I currently don't want to go without this machine or go through sending a board in and waiting for them to get it back to me. I hope nobody else encounters this... it's really frustrating!

Thanks! This resolved the issue.

Starting in early October, the container's automatic backup has stopped working. I filed an issue in Github with the details here: backup script stopped running - "*** buffer overflow detected ***: terminated" I haven't yet tried to debug this, but from some earlier posts it sounds like I'm not the only one.

Thank you for this. I recently updated to the latest BIOS and Intel ME firmware. I have the ATX form factor MB. Here's the specific steps I took: Download the latest Hirens BootCD PE and then install it on a USB stick using Rufus Download the latest Intel ME drivers (i.e. "Intel ME V2407.6.1.0 (SW 2425.6.26.0) for Windows 10 64-bit and Windows 11 64-bit."), extract the files and copy it to the USB stick into a directory (i.e. /Drivers) Download the Intel ME update tool, extract the files, and copy them to the USB stick into a directory (i.e. /Firmware) Download the latest BIOS, extract the files, run the BIOSRenamer tool, and then copy the resulting "PWW680AI.CAP" file to the root of the USB stick Reboot the computer and boot from the USB stick Run "AsusSetup.exe" to install the Intel ME drivers you put in the /Drivers directory Run "MEUpdateTool.exe" to update the Intel ME firmware you put in the /Firmware directory Reboot into the BIOS, and then install the firmware using the ASUS EzFlash Utility Note - these links are to my specific motherboard; make sure to get the files for your specific motherboard from Asus. Hope that helps!

If it's helpful for folks, here's what it took for me to stop the WebGUI/nginx crashes and enabled tailnet access to my macvlan docker containers. Background: I'm on unraid version 6.12.4. I had (and have) Wireguard working great. I could reach my local network, all of my Docker containers (those with host networks and those with macvlan), etc. etc. In order to get the Tailscale plugin to work the same as Wireguard I had to make the following changes: 1) As advised in the release notes, I changed my macvlan network & Docker settings so that they use the eth0.X interfaces instead of the br0.X interfaces. To do this, you'll need to update your network configuration to disable bridging and update your Docker configuration to allow the host to access custom networks. This config will enable macvlan, but move the interface to eth0. I recommend stopping your array and making both changes at the same time; if you do that, it *should* automatically update all of your docker containers with the right config. I did it in two steps, which meant I had to go manually change the network config of all of my Docker containers to get them to restart. 2) As you'd expect, I needed to use the command line to advertise the routes I wanted my remotes to connect to: tailscale up --accept-routes --advertise-exit-node --advertise-routes=192.168.10.0/24,192.168.20.0/24,192.168.60.0/24 --accept-dns=false 3) In the Tailscale Plugin settings, I needed to set "Enable IP Forwarding" and "Unraid services listen on Tailscale IP" to Yes. 4) On the Tailscale WebUI Admin, configure the server to allow the subnet routing. The most important bit was step #1. Without it, I could not reach my Docker containers that were on their own IP addresses. And this change also appears to have solved the WebGUI crashing that others have reported. It's been stable now for 12 hours; I'll report back if I see a change. HTH

If you find yourself here because your MinIO container stopped being able to start on or around October 31st, it's likely because MinIO removed support for "Filesystem" backends and didn't provide an automatic upgrade/migration path: https://min.io/docs/minio/linux/operations/install-deploy-manage/deploy-minio-single-node-single-drive.html Looks like the only solution is to run a previous container version, stand up a new version simultaneously and copy your data/settings to a new MinIO deployment. Really annoyed by this. Off I go to recreate and duplicate a few TB of data...

@DanielWWS - it appears we have the exact same issue. I tried two different Coral USB devices. I tried plugging the Coral to an externally powered USB 3.0 hub. I never found a solution. If you do, please post!

Thanks for the help on this, but I didn't find a solution that worked. The closest I came was by trying an external, powered USB hub. I actually saw the TPU do some detection in Frigate for a moment... only to stop working shortly thereafter. I think I might have a defective device so I'm going to return it.

Yes, I'm using the original cable that came with the coral. How are you mapping the specific USB? $lsusb ... Bus 004 Device 002: ID 1a6e:089a Global Unichip Corp. ... In my case, would I map /dev/bus/usb/004/002 ? I don't know how to find, or cannot find, a specific /dev/tty* device for the coral.

My box has 3 USB devices - the USB stick for the OS, a zwave stick, and the Coral. The Coral is on the USB 3 hub. The other two devices are on a USB 2 hub. Interesting theory that it could be lack of power; my motherboard is very, very old and it wouldn't surprise me if there's some quirk there. My USB Coral is mapped via the default settings: /dev/bus/usb -> /dev/bus/usb My USB zwave stick is mapped in another container to the specific device: /dev/ttyACM0 -> /dev/ttyACM0 Any issue with those settings?

Hey folks - I'm trying to get Frigate setup with a Google Coral USB stick. Everything on the setup has gone well, except that the USB device is behaving strange. It appears to be connecting/disconnecting repeatedly. And it's awfully warm to the touch when it's not in use. It doesn't look like it's actually being used to detect anything, either. To make sure it's not an issue with the Coral, I've plugged the USB device into a Windows based system and have confirmed that it (1) doesn't get warm at idle and (2) works correctly following the Google getting started instructions. When trying to use the device on my Unraid box, I get these repeated errors in the log: ... Jun 9 00:02:39 lenny kernel: usb 4-2: LPM exit latency is zeroed, disabling LPM. Jun 9 00:03:29 lenny kernel: usb 4-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd Jun 9 00:03:29 lenny kernel: usb 4-2: LPM exit latency is zeroed, disabling LPM. Jun 9 00:04:19 lenny kernel: usb 4-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd ... And in Frigate, I get a corresponding set of repeated errors around the same time: ... detector.coral INFO : Starting detection process: 126 frigate.edgetpu INFO : Attempting to load TPU as usb frigate.edgetpu INFO : TPU found frigate.watchdog INFO : Detection appears to be stuck. Restarting detection process... root INFO : Waiting for detection process to exit gracefully... root INFO : Detection process didnt exit. Force killing... detector.coral INFO : Starting detection process: 136 frigate.edgetpu INFO : Attempting to load TPU as usb frigate.edgetpu INFO : TPU found frigate.watchdog INFO : Detection appears to be stuck. Restarting detection process... root INFO : Waiting for detection process to exit gracefully... frigate.watchdog INFO : Detection appears to be stuck. Restarting detection process... root INFO : Waiting for detection process to exit gracefully... root INFO : Detection process didnt exit. Force killing... detector.coral INFO : Starting detection process: 146 ... This feels more like an OS, USB, hardware issue than something specific to Frigate... can anyone help point me in the right direction to diagnose this? Thanks in advance.

I dislike this solution for a few reasons. The primary of which is that passing in the entire BT bus into a Docker container only works if it's running as privileged and on the host network IIRC. In my configuration, I run my containers in VLANs for network isolation, making it such that they can't access the Bluetooth devices. If the BT support were removed from the host OS, I'd then have to create/maintain a Docker container in a higher-permission config just to run a simple Bluetooth script. Feels like overkill to go in that direction to me. It's nice that there's multiple ways to do it so that if someone runs into a driver issue they need to work around, they can use Docker. But I don't think the host OS support necessitates the frequent/trivial OS updates that seem to be the desired reason to remove the support. TL;DR - I appreciate and use the native host OS support for bluetooth and would like to keep it.

Added bluez back in Thank you!

@dmacias I just upgraded to 6.7.2. Is there a reazon bluez would have disappeared from NerdPack? It was super useful. Thanks!

Thank you - super useful. I'm starting to do some dev on Unraid for a really basic project and needed to get `make` installed.