Leaderboard

Upgraded from last stable as I had a spin-up problem with my Seagate Ironwolf parity drive under RC2. I see the same quirk again under the new kernel - this time having attached diagnostics. From what I can tell, it appears once the mover kicks in and forces the spin up of the parity. It tripped up once as you can see from the logs but came up and wrote fine. I've done repeated manual spin downs of the parity, writing into the array via the cache, and forcing a move hence bringing up the parity again. No errors as of yet. This is a new drive and under the same hardware setup completely as 6.8.3 so it is a software/timing issue buried deep. If this continues, I will move the parity off my 2116 controller (16 port) and over to my 2008 (8 port) to see if that relieves any issues. Past that, perhaps over to the motherboard connector to isolate the issue. FYI. Kev. Update: I've disabled the cache on all shares to force spin ups much faster. Just had another reset on spin up. I'll move to next controller now. Update 2: Drive dropped outright on my 2008 controller and Unraid dropped the parity and invalidated it: I'm going to replace the Seagate with a 8T WD unit and rebuild. Definitely an issue somewhere with timings between the 2 controllers. Update 3: After some testing offline with the unit and digging, it looks like the Ironwolf may be too aggressively set at the factory for a lazy spin up. This behavior must be tripping up some recent changes in the mpt2/3sas driver. Seagate does have advanced tools for setting internal parameters ("seachest"). I set the drive to disable the EPC (extended power conditions) which have a few stages of timers before various power-down states. I also for good measure disabled the low current spin-up to ensure a quick start. Initial tests didn't flag any opcodes in the log. I'm rebuilding with it and testing. For note, the commands are: SeaChest_PowerControl_xxxx -d /dev/sgYY --EPCfeature disable SeaChest_Configure_xxxx -d /dev/sgYY --lowCurrentSpinup disable Update 4: I've submitted all info to Seagate tech support citing the issue with the 10TB and my suspicions. Deeper testing today once my rebuild is done to see if the fixes clear the issue. Update 5: Full parity rebuild with Ironwolf. No issues. I've done repeated manual drive power downs and spin ups to force the kernel errors across both the controllers above and I have not seen any errors. Looks like the two tweaks above are holding. Kev.

Normally I would have, but I just didn't have a chance to yet. My life is still a bit of a mess after moving (I'm currently sitting on the floor while I type this because most of my furniture won't arrive for another week haha). I'm planning on incrementing the version later today though, but I wanted to get the quick and dirty fix out sooner rather than later.

Have you a active internet connection on boot? The plugin will automatically download the new version for you, but you need to have a internet connection on boot otherwise it will fail. No, you only need a active internet connection on boot and it will download the new driver (keep in mind that the boot will take a little longer since it's downloading the new driver ~130MB). As @tjb_altf4 said if you don't have a Internet connection the worst thing can happen is that you have to reinstall the Plugin and also disable and enable the Docker Daemon or reboot once more. Hopefully the next time a update is released this won't happen again. I check for new versions now every 15 minutes and have everything automated so that about 1 hour and 15 minutes after a release the Plugins are updated, even if I'm sleeping...

Personally and I do mean personally I always do the following: Stop all Dockers Spin up all Drives (below does it anyways, but......) Stop the Array Shutdown/Reboot I do that simply because if a docker hangs I can wait for it to shutdown vs wondering what's hung and why my machine isn't shutting down. So I assume control of each step because I don't like unclean shutdowns and having to wait for a parity check to fire up if something goes sideways. I've not done that a few times and had good results, but there was a few times in the past when I had to eventually login and pray when I forced it to shutdown nothing would go wrong.

Yeah just a min, actually about 15. I put it on the wrong branch 😆 Ok good to go now, sheesh

This release contains bug fixes and minor improvements. Refer to Summary of New Features for an overview of changes since version 6.8. To upgrade: First create a backup of your USB flash boot device: Main/Flash/Flash Backup If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Thank you to all Moderators, Community Developers and Community Members for reporting bugs, providing information and posting workarounds. Please remember to make a flash backup.

Hey plugin authors! I am trying to prevent a class of errors related to ownership and permissions on files/dirs installed by plugins. We want to make sure that all files/dirs are owned by root:root and have perms of 755 or 644. This applies to files installed in the operating system, not user files you place on the flash or array. Unraid itself does not yet enforce these rules, but I'd like to get there. I've written a small script that detects problems, you can see it here: https://gist.github.com/ljm42/d612bcfbc071d854baba53c482fd64e4 To run it on your system and detect issues with the plugins you have installed: cd /tmp wget https://gist.github.com/ljm42/d612bcfbc071d854baba53c482fd64e4/raw -O plgcheck bash plgcheck It will run through the txz files on your flash drive and flag any ownership issues or permission issues. Please update your plugin's txz files so they are not flagged by this test. Or let me know if you think it is flagging something unnecessarily. Thanks! p.s. please don't feel personally attacked by this, my plugin fails this test currently too

Probably will work ok (as that's how you've got it now).

This seems to be very difficult to achieve, although I can fully understand your "wish". Keep in mind that even an 80 plus titanium psu has 10% loss on 10% load. ARM sbc's are very low on idle usage, but they're not super powerful.

No, but you then have to manage everything yourself instead of the OS You do the stubbing via system devices Either there or in Settings - CPU pinning. Doesn't matter as CPU Pinning writes the entries to syslinux. no

已经解决了，我更换了银行卡，可以成功付款

是的，这样更准确

That's always my first go-to. I'm not an expert in any of this stuff. 2) I double checked that before pulling the plug this morning... I HAVE done that before and spent an hour scratching my head going WTF... !! But not this time. The UPS does have both, but I'm plugged into the "backup" section with for both power supplies. 1) will test tomorrow with the other UPS... it's old too, so it won't necessarily be conclusive. But it will be an indication!

I edited your first post and title to reflect that, it will be better for clarity in the future.

That's because I'm an idiot. I don't mean wireshark, I mean wireguard 🤯

Good ideas. Hmm, until you are confident that reboots work, I'd suggest stopping the array manually before you shutdown or reboot. Array status is stored on the flash, so if the array stops successfully before the system hangs then you can avoid unclean shutdowns and forced parity checks.

My script now looks like this: #!/bin/bash cat /mnt/user/<share>/<file>; With 1 line per disk, that just outputs the file to the console, or in that case the log. So same as before, script as cronjob for the time that you want them to keep spinning, spindown settings for the rest of the time. Yeah, that remains to be seen, my script will start soon and I'll report back if it kept working through the evening. Still this is a clunky workaround, there has got to be something lke the old version with 'sdspin'

@Gico Do you know which client on your network is 192.168.168.10? its connecting to your server repeatedly via /login and nginx is complaining about it.

No these are host keys - what the server uses to identify itself to the user - and all the files in /boot/config/ssh will be installed into /etc/ssh upon startup of the ssh server. If the ssh server starts up and cannot find these host keys, it will generate new ones and scare anybody trying to ssh in with a warning message about possible Man in the Middle Attacks due to host key mismatch. Needless to say, the new ones will be saved to /boot/config/ssh as well. For those who use the ssh plugin or know what they are doing, the configuration of the ssh service can be changed and persisted by copying the modified /etc/ssh/sshd_config file here.

wow, that was quick, update went smooth from 6.9.0 to 6.9.1. Now bring on 7.0.0

@binhex, please accept my apology as I go jump off a bridge for not RTFM!. Thanks for all of your great work.

According to wiki max Reiser FS volume size is 16TiB, so likely why you're running into trouble, best to upgrade to Unraid V6 and convert to XFS.

Thanks for the fix Trouble though with what you've done is that many users may not be aware of the issue (ie: the plugin may have auto updated), and if at some point when they do check out the webUI they'll have the issues on a version of the plugin which is already fixed. Why not bump the version of the plugin so that every version to avoid any issues?

Quick update: Everything's back to normal, without any issues:)

Ich laste laut CrystalDiskMark 10G mit 1175 MB/s aus. Windows zeigt im Schnitt 1.05 "GB/s" an. Da Windows in Wirklichkeit Gibibyte anzeigt, sind das also 1127 MB/s. Maximal sind es sogar 1.09 GiB/s, also 1170 MB/s. 10Gbit sind 1250 MB/s. Der Durchsatz von Ethernet ist 94%, also 1175 MB/s. Demnach sollte MTU 9000 mir irgendwas zwischen 0 und 50 MB/s bringen. Ich habe es nie zum Laufen bekommen und daher schlussendlich auf 15⁰ gelassen. EDIT: Ich habe gerade herausgefunden, dass der Durchsatz genau das ist, was man mit der MTU erhöht. Nämlich 99% mit 9000. Demnach könnte ich doch noch was rausholen. 1249 MB/s wären möglich.

Make sure you're booting using legacy BIOS/CSM, memtest doesn't support UEFI boot.

This is one way: https://forums.unraid.net/topic/93846-btrfs-error-with-new-system-m2-ssd/?tab=comments#comment-867992

Thanks for your reply, i've literally just finished using the kernel helper for 6.9.1 stable. I think I know where I was going wrong, a long time ago I was using the linuxserver.io unraid Nvidia, and Unraid DVB Plugins. They overwrote each other not your drivers. Re-looking just now I see there are two plugins I need in your Repo, Nvidia Driver, and DVB Driver. Thanks for your efforts! I'll try them next build rather than the Kernel Builder. p.s the Kernel Builder has been amazing.

Okay danke für die Info. Hab ich leider nicht mitbekommen. @mgutt Vielleicht kannst du das ja bei dem Topic "Häufig gestellte Fragen" ergänzen, dass dies ab 6.9 nicht mehr benötigt wird.

That did the trick, thanks for the help!

Good deal. The -delete option uses extra memory. Let’s eliminate the variables one at a time. Just for the sake of troubleshooting, remove that option and try running again. Also, add -P and -h. Those will make the output a little easier to read for you.

Don't touch those as they are the SSh host keys (deleting them will regenerate them on sshd restart) If they are regenerated, you'll get warning about Man In The Middle attacks (ssh will consider your Unraid host as never before seen)

Hi @coblck, can you advise on how much ram your system running rsync has? also, what is the file format for the external hd? sometimes using the -a tag for rsync between different file formats can cause problems. so i'm wondering if using -r and -t, and maybe some other options would help solve the problem of using -a. there could be a few different things to try here

Well as it stands, you should enable root as that's the supported unraid way.

According to ethtool and ifconfig in your diagnostics you have eth0 and eth1. However your network.cfg file references eth0 and eth3 instead and they are both on the same network. # Generated settings: IFNAME[0]="eth0" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.1.6" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.1.1" METRIC[0]="1" DNS_SERVER1="8.8.8.8" DNS_SERVER2="8.8.4.4" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" IFNAME[1]="eth3" PROTOCOL[1]="ipv4" USE_DHCP[1]="no" IPADDR[1]="192.168.1.119" NETMASK[1]="255.255.255.0" GATEWAY[1]="192.168.1.1" SYSNICS="2" I'm not sure what you aim to achieve but you probably want to recreate the network.cfg file. If you have a DHCP server you could simply delete the /boot/config/network.cfg file and reboot. It will then be recreated with safe DHCP settings. You can then edit it via the GUI Settings -> Network.

Done as you wrote and with all default settings everything works. Public posting to server list and stable for a few hours. I'm going to start changing the server name, world name, password, one by one to see what happens. I did make sure the password was not the world name. Will report back if with results.

I did indeed get another crash since, I saw there was a new unraid release today so I tried that but still another crash since. I went to try safe mode but then found most of my disks don't show because I assume it's not loading the drivers for my LSI card so for now I've reverted to normal boot but with Docker engine turned off. Will see how that goes. Will also see if theres a way for me to just load the drivers for my LSI card so i can use safe mode but still access plex on a 2nd box using the files on the crashing one.

FCP supports this on 6.9

Next point release can you update docker to 20.10.5 It patches 3 CVE's including these 2 ugly ones: https://github.com/moby/moby/security/advisories/GHSA-6fj5-m822-rqx8 https://github.com/moby/moby/security/advisories/GHSA-7452-xqpj-6rpc

IIRC GPU stats plugin can cause this.

Looks like its time to close my feature request now.

I like to request NordVPN client docker from bubuntux Its designed to provide connection to other containers via --net=container:vpn And the advantage front normal openvpn clients its that uses the NordLynx connection so you get better performance with this when using this vpn. Tried to create a docker template my self and but it dockerman/templates-user, but can't get it to work. Thanks for your time.

I like to request Remotely would be very nice to use it for customer remote support for Windows, linux or maybe vm access. This Youtube video (hope its okay to post) got me interested and it can be selfhosted. https://github.com/lucent-sea/Remotely

I added a Cyberpower UPS ValuePRO VP700ELCD Green Power UPS 700VA/390W which was detected immediatly by the integrated APC deamon. Approx. runtime on battery is 40 mins.

well summarized and worth a PIN. I think I'll redo the math. As written in my initial post, the 45W config on surface looks like a sweet spot, without getting to technical with math and numbers.

I was able to pull bubuntux/nordvpn, which is a Nord VPN service utilizing Wireguard, as an ordinary docker from Docker hub. I was able to modify the config file and get it to run using docker-compose. I have to launch it from the command line, and while its running I can pause it and stop it. from the Unraid interface. I haven't yet figured out how to configure it for other dockers that might want to use the tunnel. I think more than anything, it needs a docker menu to help reconfigure the service, but I haven't figured out how to create a menu file. Any tips of borrowing another apps docker menu and modifying it to work for bubuntux/nordvpn would be appreciated.

My suggestion is to update your BIOS, change to Legacy boot if currently UEFI (if possible), or switch the physical slot your GPU is in and see if the problem goes away. The issue is your build parameters, not my plugin. The only other option would be to figure out a way to squelch that log. Maybe a combination of using this script and creating a custom .conf file to remove the offending log messages. If anyone wants to try it, create a file (02-barmappingblock.conf) in /etc/rsyslog.d/ that contains: :msg,contains,"mapping multiple BARs" stop :msg,contains,"which spans more than PCI Bus" stop Then do a: /etc/rc.d/rc.rsyslogd restart > /dev/null If it works, then copy that .conf file to the location the script suggestions, and then add it to your startup scripts when UnRAID boots. It's not a 'fix' per se, but a kernel/driver issue can't be fixed by myself or the linuxserver folks.

Try this From a windows command prompt (run as administrator) mklink /d "c:\WhateverFolderYouWantItCalled" "\\unRaidServer\unRaidShareName" Your share will wind up being mounted within that folder on an existing windows drive Should be close enough to what you need.

SOLVED! Solved solved solved! I can across this post from MHzTweaker: http://lime-technology.com/forum/index.php?topic=28727.msg256252#msg256252. In turn, he had posted this link: http://yannickdekoeijer.blogspot.com/2012/04/modding-dell-perc-6-sas-raidcontroller.html Sure enough, after sticking a piece of electrical tape over pins B5 and B6, the card now boots on all of my systems. Attached is a picture. Once I had flashed the card, literally the electrical tape was the thing to get it to work. I've attached a picture of the card, and below is a link to the zip file I used to flash the card. Instructions are in the file. I'll also update the LSI controller thread. https://www.dropbox.com/s/l4kadyukkh2w497/Flash%20Dell%20PERC%20H310%20for%20unRAID.zip