_Shorty

Well, I eventually got around to fooling with this a bit more. label unRAID OS menu default kernel /bzimage append initrd=/bzroot boot=a This boot=a parameter seems to make the machine successfully shut off every time, but I still get no love on reboot attempts. But this is ok. The only time I seem to reboot it is when a new version is released anyway, and it is a simple matter to just tell it to shut off and then go hit the power button whenever that completes. I'm glad that is working, at least. Wonder what it is with that motherboard and linux that don't like each other, at least as far as this issue goes, heh. I believe I tried every valid boot= flag and that was the one that at least worked for shutdowns.

Powerdown shuts the machine off just fine. I did a bit of googling on linux in general, rather than restricting myself to unraid, and found quite a few people with the same issue. Some reports of solving it by adding the boot paramater "reboot=b" or "reboot=pci" or some other similar things, such as seen here: https://askubuntu.com/questions/7114/why-cant-i-restart-shutdown I suppose I should try adding that to my boot params, providing I can figure out how to add them to unraid. I'll try that in the morning when I get the chance.

Frank, no difference. Still exhibits the same behaviour. Squid, well, it doesn't happen when booting into and rebooting from Windows. Sometimes shutdown works, and sometimes it seems to do something similar to what I've described. unRAID doesn't seem to be behaving as far as whatever power mode commands it sends in order to reboot/shutdown. The machine is 10 years old. It has long had the latest BIOS. And it has never exhibited this behaviour under any version of Windows in that decade.

I've got an AMD Phenom II X4 965 machine that will not reboot. If I issue a "powerdown -r" command it appears to go through all the various shutdown stages just fine, and the last two messages I see are '/boot unmounted' and 'rebooting' but the machine never reboots. The video display turns off. And it seems to go into some weird frozen state. The reset button does nothing. The power button pressed momentarily does nothing. I have to hold down the power button for a few seconds for the power to actually turn off. And then I am able to power it back on and it boots up as though nothing were wrong. I've done a little bit of searching trying to find where a syslog might be saved to help diagnose this, but I can't seem to find any saved copy anywhere on my flash drive. Any help would be appreciated. Thanks. edit: I should note, I do not have any dockers or anything installed. And I only have a few plugins installed, which are mostly a few of the Dynamix ones. All I use the machine for is Samba shares.

Thanks for the reply. I think maybe this was a false alarm. I was browsing from a Windows machine, and Explorer for some reason had gone into that mode where it tries to guess what types of files are in a "folder" and reads some amount of information from every file in an attempt to "help" you in some way. Resetting all "folders" fixed this and it began reading directories at normal speed again. Stupid Windows bug making it forget that I turned that crap off already, causing me to have to turn it off again. *sigh*

Has anyone else noticed Cache Directories does not seem to be working with unRAID 6.4.1? I've uninstalled it and reinstalled it just now to see if it begins working again, but before doing that today I've had a very sluggish directory browsing experience. Hopefully uninstalling and reinstalling the plugin will remedy this. Normally we do not need to uninstall/reinstall plugins after an unRAID update, is that correct?

That's yet more good info to chew over, thank you. I presume the Dynamix File Integrity plugin exists for just that reason. Just searched for 'hash' and found that plugin. edit: Ah, I see Squid has written a similar one, too.

ok, I believe I understand now. Thanks for the education.

I find this "write corrections to the parity disk" idea very, very confusing. The whole point of parity is to be able to fix errors in your data if any are found. Why would you want to update the parity disk with what you are currently reading if there are errors? You want to correct the errors, not write new parity so it passes with the current data. The way this is worded in the settings makes me believe that this is indeed what is happening, that parity is being incorrectly updated based on current data, and is only affirmed by the discussion in this thread. That being, a "correcting" parity check is actually just throwing parity out the window and completely ignoring it, and is simply rebuilding parity with whatever data is currently on the data drives. Why is this something you would want to do? This seems like an insanely bad idea. Have I actually got this wrong? Because the discussion here seems to say I've actually got it right. Given the feature's description and the discussion in this thread, this is what I think would happen if I took a disk to another machine, made corrupting changes to tons of files on it, and put it back into the unRAID machine and ran a correcting parity check. The corrupted files would cause a parity check failure, and the parity disk would be updated to contain new and current parity data based on the untouched disks and the intentionally corrupted disk. Why would anyone ever want that to happen? You should want the corrupted data on the intentionally corrupted disk to be returned to the pre-corrupted state. You want to update the array based on the existing parity data. You don't want to update the parity disk to reflect the current state. Please, please tell me I have this wrong. Because if I don't have this wrong, unRAID's parity check is completely useless. I must have this wrong. But it sure seems like I have it correct in my head, given what I've just read.

Thanks for the responses. Makes great sense!

What are possible reasons for wanting to delay updates for x amount of days? I don't understand why one might want to do so. Hopefully someone can enlighten me. Thanks.