jonathanm

Indirectly, you do. massive bread errors in the syslog. I agree it would be nice if there was a notification event fired so you know about it immediately instead of seeing the chaos caused whenever you log in later. Maybe even an option to perform some action if /boot ceases to be populated. I'd like a configurable option to automatically shut down properly, even though it couldn't be recorded as a clean shutdown I'd know best efforts were taken to keep my data intact, and a notification that the boot USB was removed and the array shutdown properly would be good troubleshooting information when I bring the array back online. I just had a lightbulb moment. @Squid, would it be possible to mirror all writes to flash to a mounted image file on the array somewhere? A modified RAID1 of sorts? Then if the physical USB is unable to read or write, continue operating on the array copy, with the option to repair or remount the physical USB and bring it back in sync? I'm envisioning a system where flash replacement could be done live, with the license update happening on next array start.

Edit the first post and change the title.

The UPS that I use don't ever NOT use batteries. They are not switching, they are constant output totally isolated from the mains. Instead of monitoring the line power and reacting, the input is solely used to keep the batteries charged, and the output is constantly pulling from the batteries. They are rated for hospital equipment, which can and does include inductive loads.

Nope. Theoretically I suppose you could assign a 1GB USB thumb drive as disk1.

Did you disable the docker and VM services? As in, no Docker or VMS tab visible in the GUI?

Depends on the write mode selected in settings. Turbo (reconstruct) does exactly that, spins up all drives for writes.

It is important. I'm not saying that it isn't. It's just the urgent tag triggers a bunch of immediate attention, which isn't necessarily productive in this specific instance. Better to put it in the que of important things to try to fix, instead of in the "emergency we better find a solution before thousands of people corrupt their data" category, only to find out that it's not that big of a deal for 99% of the user base. Screaming for attention for something that in the grand scheme isn't a show stopper may cause the issue to get pushed down farther than it deserves to be as an over reaction to the initial panic. Politely asking for help resolving it goes a lot further than pushing the panic button.

With 1 parity disk assigned to parity1, and one data disk, yes, the operation is pretty much a RAID1. Any other configuration reverts to the general parity disk calculations, with the associated speed penalties. Disks can be configured to spin down when not being actively accessed. However, with only 2 disks and no cache drive defined, any docker container or VM services will keep the array spun up constantly.

Respectfully, while I agree that it's urgent in the sense that there is something wrong that needs to be addressed, there is a valid workaround in place to run unraid without triggering the issue, and it only effects a small subset of hardware. GUI mode just doesn't work properly on some systems. It's been that way since it's been introduced. I don't think this deserves the urgent tag, which implies a showstopper issue for general usage in a majority of hardware with no workaround.

So to be clear, this only effects GUI mode?

I know it feels to you like software, because that's what you changed, but your symptoms really sound like hardware. When is the last time you had the server open and cleaned out the dust bunnies? It sounds to me like you are having problems whenever the server is stressed.

Google El Gato HD 60 Pro unraid site:forums.unraid.net Doesn't seem to be a whole lot of success with that particular card.

If updating doesn't solve it, attach diagnostics collected after the problem has occurred and before rebooting.

Perhaps update and see if that fixes the issue. We're way past that release now.