-
Posts
49 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by -MacGyver-
-
-
Years ago when using two CPU's the two had to be "matched" (same family, stepping, etc) as to not mess up clocks or add other interference to the system. Not the same, but it made me think of that when you mentioned the 4600's were not supported on that MB.
Might be a stretch, but maybe the MB can operate with the 46xx but only as a single in an unofficial capacity. Would agree that if those 4600 are not approved for dual configuration the bios should refuse to allow an OS to boot.
Here is to hoping you get an answer to the issue soon. -
Maybe one cpu is bad. Try with one cpu at a time and see if it goes beyond the 20 minutes?
-
Prime95 or OCCT to stress test? Basically treat it like you overclocked it and want to test for stability...
If thermals, other thermals could be memory or onboard controllers/chipsets.
-
Are the voltages at system working or after crash?
They all look ok, and seem to be in range. The 5v, 5VSB, and 12v show the most variability in the images (distance between the 2 red lines).
My 5v and 5VSB are 5 and 5.02 respectively. And for reference my 12v is 11.75.
Each board is different, your voltages for those three should be ok.
If I happen think of anything else I'll offer. Sorry what I've suggested so far hasn't been fruitful.
-
Can you see voltages in your IPMI? I can on my X10 board, but not sure on the X9. If so have a login to the IPMI voltages (or the plugin) and monitor the 3,5, and 12v and see if any dip (or drop) under load.
-
"...while under heavy load." - possible its the PSU failing under load?
And sorry, I cannot remember if you mentioned it being replaced or not in the thread. -
Maybe setup another USB key with a different distro, like Slackware (since that is what unraid is based on) and see what it does for a few hours/days. Use a live install versus an Installer install to the USB drive.
If it works then I'm not sure what that means. Could be tied to one of the kernel parameters that Lime it using to compile this kernel with that is incompatible with your hardware. Getting ahead of things though with this thinking...
-
Not sure if this still works, or if macvlan issues will cause server crashes, but here is a post from another member that figured this out (or so it seems). Sharing in the event there might be some info in this post to get you further along.
-
1
-
-
+1, 1, and -1 also +0, 0, -0 all mean different things for mtime. But +0 will not make the mtime statement true, and will not return any files to the -exec command. Try below to see what I mean.
use this and test what changing the -mtime to those six values above. Then when this -exec ls -ltr {} \; brings back what you need then use that for the -mtime value. Test to be sure that it is doing *exactly* what you want before updating the script and and running for rm.
find /mnt/user/downloads/incomplete/* -mtime <your test # here> -exec ls -ltr {} \;*** Use at your own risk, not responsible for you using an incorrect -mtime value and removing more files than you intend. Be sure the ls -ltr {} \; is doing what you expect. ***
-
Either the dir= line should end in a / - look like this dir=/mnt/user/downloads/incomplete/ , OR the find command should include the slash: $dir/* and look like - find $dir/* -mtime +1 -exec rm -rfv {} \;
Currently find is looking for files that start with incomplete in the downloads directory - in reality this: /mnt/user/downloads/incomplete* , notice the incomplete*. You have the two choices I mentioned to fix, do not use both.
give either of those a try, that should make it work. -
There is documentation located at this link for 6.9.x on where to go to set the root password. There are no screenshots, just words for the navigation.
https://wiki.unraid.net/Manual/Security#Set_a_strong_root_password
-
FYI - its this page:
https://wiki.unraid.net/Manual/Release_Notes/Unraid_OS_6.9.0
And this comment specifically from that link at the top (Bold and Red highlight I added):
Note: A pre-6.9.0 cache disk/pool is now simply a pool named "cache". When you upgrade a server which has a cache disk/pool defined, a backup of config/disk.cfg will be saved to config/disk.cfg.bak, and then cache device assignment settings are moved out of config/disk.cfg and into a new file, config/pools/cache.cfg. If later you revert back to a pre-6.9.0 Unraid OS release you will lose your cache device assignments and you will have to manually re-assign devices to cache. As long as you reassign the correct devices, data should remain intact.
-
Like JorgeB mentioned in your other post, think you missed it, go back to the release notes for 6.9.x on how to revert back to 6.8.3.
When reverting back to 6.8.3 from 6.9.x the cache won't be assigned you have to reassign cache. -
To be clear it was that moving the USB allowed it to boot before fast boot was disabled. Was offering that as a symptom. If you move the USB to a different port and it boots, before updating the bios that, to me, is a good indicator of the fast boot enabled causing the issue. 🙂
-
Don't have an MSI board, so apologies. But a few days ago I had seen some other forum posts about a similar issue. It seemed that the fast boot on MSI boards causes this issue.
Also from what I've read there can be two fast boot options. But not having an MSI I can't confirm that.
Another symptom is moving the USB drive to another port allows boot to succeed also.
Long story short, go into the bios and disable fast boot, look for two just in case (but there could only be one). Then try a few reboots to see what happens.
-
Busy work week last week. Glad to hear those worked for you @Masterwishx. I need to update the steps as the speedtest script was updated by the original developer (thanks for the pull request shiftlilbastrd) to present the version the way it had been.
Yes, have noticed the same, seems to be 10% lower than what was previously reported. My latest speed test was 210Mb, and I know to add 10%, which means an older script version would have registered as 231Mb.
Did notice that this version of the speedtest script has many more lines of code than previous ones. Have not compared it to a prior version to see if something was added that is causing the lower speed test results.
-
1
-
-
This was a change on the ookla side, and not related to the 6.9.x series updates. My unraid software is a few versions older, and this issue started April 7th for me as well.
Did install the henrywhitaker3/speedtest-tracker after this plugin broke. Still prefer the plugin because it can highlight speed tests below thresholds for both down and up tests, and why I spent some time this weekend looking at the code for the speedtest plugin. It seems someone else here noticed a new version of the script and asked if dmacias could update the plugin. After looking at the code more I found the repository for the speedtest-cli update that is used within this plugin. That file, as of now, was last updated on April 8th to version 2.1.3 by the maintainer of that repo. Applied this version to my system and the speedtest plugin works again. Providing here for others, if so interested.
** Notice: Not claiming to be the creator of the plugin, or the creator of the speedtest.py script the plugin uses. Providing a workaround to get the plugin back up and operational.
** Disclaimer: Follow these steps at your own risk. This info is provided as-is. Understand and know what these steps are doing. If you do not know, then don’t run them!
Downloading and modifying this file in /tmp to not cause issues with real data, this was done via ssh to the unraid server.cd /tmp mkdir speedtest-new cd speedtest-new
Now we grab the new version of the script (raw repository location):wget https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
The downloaded file, when viewed on the speedtest plugin settings tab will show a lot more “version” info. like this image. Updating the "def versoin():" function will change from this image on the setting page to showing just 2.1.3. This is optional.
Open speedtest.py and look for “def version():” and update this function to look like below::Quotedef version():
"""Print the version"""printer(__version__)
#printer('Python %s' % sys.version.replace('\n', ''))
sys.exit(0)Save and exit your editor once this section looks like above.
Changing the name of the file, to know what version it is. Currently still in our download location, in this example: /tmp/speedtest-new
mv speedtest.py speedtest-2.1.3.pyNow that we have the file, updated the version function (if you did that) and renamed we can place in the speedtest plugin location.
Use this command to copy to the speedtest plugin location:
cp speedtest-2.1.3.py /usr/local/emhttp/plugins/speedtest/scriptsChange into the speedtest scripts location, backup the current script. Then rename the new version file to the speedtest.py file name and lastly make our new script executable:
cd /usr/local/emhttp/plugins/speedtest/scripts ls -ltrverify you see “speedtest-2.1.3.py”. If not go back to the location you downloaded and copy to this location again.
Now backup the old 2.0.0 version file, I’m assuming that is the latest version you had working:
cp speedtest.py speedtest-2.0.0.pyCopy the new file over and make executable:
cp speedtest-2.1.3.py speedtest.py chmod 755 speedtest.pyverify rwxr-xr-x for speedtest.py:
ls -ltr
Change to the webui settings page for the speedtest plugin. Refresh the page and the version drop down should now show 2.1.3 (or like the image above with more detailed version info). Hit the apply button. Now hit the Begin Test button to verify speedtest plugin is working again for you.
The last thing to do is to make this survive a reboot. For me that was making a custom directory in the /boot location (this is your flash device, take care when executing commands here. You can wipe your unraid flash device or make unintended change If you do not know what you are doing). Then copy the speedtest-2.1.3py file from tmp to here. Either in the “go” file or from the “user scripts” add-on you can copy the file (and rename in one step) to the speedtest scripts location above. Be sure to include a step to chmod the file in your go or user scripts. Please note the copy, and chmod, need to be done after plugins have been installed, otherwise the change will be overwritten – or the copy could fail since the directory wouldn’t exist.
You could copy the plugin .tgz file to another computer, unzip (7zip works) find the file and replace it. Then re-zip as (as a TAR archive compresses in GNU Zip) replace the file in the plugins folder on the flash (/boot).
-
1
-
1
-
-
Updated Local Master plugin on Dec 31st at 12:05pm. Encountered the same warning about "DefaultPageLayout.php". Confirming that the bug is still present in the 2015.12.30 version as fireplex reported.
Following the steps in post #885 has fixed the issue and the GUI has returned. Thank you to kyis for posting the fix
dot in root PATH
in General Support
Posted
By having . in the $PATH ./ does not need to prepend an executable command/script that is not in the path.
For example you have myscript.sh located in a directory not in the path, maybe your home directory.
To run the script without . in the $PATH you type this way:
./myscript.sh
To run the script with . in the $PATH you can type this way:
myscript.sh