unRAID Server Release 6.2.0-rc3 Available


191 posts in this topic Last Reply

Recommended Posts

Did anyone succeed to get preclear script/plugin to work with RC3? There is a beta plugin, which I didn't get to work at all. The "standard" plugin appears to potentially work when doing some edits with sed (see https://lime-technology.com/forum/index.php?topic=13054.msg481622#msg481622 for context).

 

Any experience what is working for you?

I've never had any issue with the beta plugin on preclearing drives on the RC's. You may want to bring up your issues with the support thread for the plugin.

 

Thanks. The last three comments (incl. one from me) in the plugin support thread mention the same issue that I am experiencing (http://lime-technology.com/forum/index.php?topic=39985.750). There are several threads (script support, customization support, plugin support). I was hoping that users or developers in this thread will be able to comment what is working for them (if it is). Preclear is recommended by everyone, so I'd anticipated that the preclear plugin/scrip is close to a default/native feature.

Link to post
  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Did anyone succeed to get preclear script/plugin to work with RC3? There is a beta plugin, which I didn't get to work at all. The "standard" plugin appears to potentially work when doing some edits with sed (see https://lime-technology.com/forum/index.php?topic=13054.msg481622#msg481622 for context).

 

Any experience what is working for you?

I've never had any issue with the beta plugin on preclearing drives on the RC's. You may want to bring up your issues with the support thread for the plugin.

 

Thanks. The last three comments (incl. one from me) in the plugin support thread mention the same issue that I am experiencing (http://lime-technology.com/forum/index.php?topic=39985.750). There are several threads (script support, customization support, plugin support). I was hoping that users or developers in this thread will be able to comment what is working for them (if it is). Preclear is recommended by everyone, so I'd anticipated that the preclear plugin/scrip is close to a default/native feature.

Clearing without taking the array offline is already implemented. That was the primary purpose of the preclear utility.

 

The extra drive testing and smart documentation offered by the preclear script is a nice bonus, but the functionality can be accomplished with other utilities, in any current OS.

 

I'm not disputing that the preclear function is a nice addon, but it's not needed as part of the core functionality since online clearing has been implemented.

Link to post

Thanks, this is helpful. So, it is no longer recommended to preclear, but instead online clearing is the recommended approach by the development team? If that's the case, I am indeed more than happy just to completely stop using the plugin/script.

Link to post

Thanks, this is helpful. So, it is no longer recommended to preclear, but instead online clearing is the recommended approach by the development team? If that's the case, I am indeed more than happy just to completely stop using the plugin/script.

As long as the drive is thoroughly and completely tested before you use it in the server, yes. Either use the drive manufacturers testing software, or one of the many testing suites available. Preclear is a very good drive testing utility, but not the only option.

 

 

Link to post

Thanks, this is helpful. So, it is no longer recommended to preclear, but instead online clearing is the recommended approach by the development team? If that's the case, I am indeed more than happy just to completely stop using the plugin/script.

No. To keep things simple, I will still recommend users to use the external preclear functionality. That is because it does actual tests of the drives before trusting it with your data. The built in clearing, while having the drive array online, does no such tests.

 

Link to post

I have upgraded to this release candidate (from 6.1.9) and I now have a sluggish/slow webui where page can take 20-30 seconds or more to load. 

I am seeing this error over and over again in the logs.  Did I miss something in the upgrade steps (which I thought I followed)?  I turned off docker and VM's, but it had no effect.  The user shares work just fine as well, it's basically just the Web UI.

 

Aug  5 13:52:02 DarkTower emhttp: shcmd (20782): /etc/rc.d/rc.avahidaemon start |& logger
Aug  5 13:52:02 DarkTower root: Starting Avahi mDNS/DNS-SD Daemon:  /usr/sbin/avahi-daemon -D
Aug  5 13:52:02 DarkTower avahi-daemon[20325]: Failed to find user 'avahi'.
Aug  5 13:52:22 DarkTower root: Timeout reached while wating for return value
Aug  5 13:52:22 DarkTower root: Could not receive return value from daemon process.
Aug  5 13:52:22 DarkTower emhttp: shcmd (20783): /etc/rc.d/rc.avahidnsconfd start |& logger
Aug  5 13:52:22 DarkTower root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon:  /usr/sbin/avahi-dnsconfd -D
Aug  5 13:52:22 DarkTower avahi-dnsconfd[20428]: connect(): No such file or directory
Aug  5 13:52:22 DarkTower avahi-dnsconfd[20428]: Failed to connect to the daemon. This probably means that you
Aug  5 13:52:22 DarkTower avahi-dnsconfd[20428]: didn't start avahi-daemon before avahi-dnsconfd.

I noticed someone posted the same issue in the RC2 thread but there was no response.  I can usually resolve issues from other people posting, google, etc, but this has stumped me for the past 2 days.

Any Ideas?

 

On my system, which doesn't have your problem, I have:

 

root@Lapulapu:~# ps aux | grep avahi    
avahi    15421  0.0  0.0  34496  3188 ?        S    Jul28   0:47 avahi-daemon: running [Lapulapu.local]
avahi    15422  0.0  0.0  34236   260 ?        S    Jul28   0:00 avahi-daemon: chroot helper
root     15430  0.0  0.0  12752   112 ?        S    Jul28   0:00 /usr/sbin/avahi-dnsconfd -D
root     27979  0.0  0.0   9656  1860 pts/1    S+   13:50   0:00 grep avahi

 

root@Lapulapu:~# grep avahi /etc/passwd 
avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/false
avahi-autoipd:x:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false

 

Notice that the avahi-daemon is running under the avahi UID. According to the third line of your syslog your system can't find the avahi user. What output do those two commands give on your system? Perhaps your /etc/passwd file has got corrupted, which is odd as it's loaded fresh with each reboot. Perhaps your flash device has got corrupted or your download of unRAID was damaged.

Link to post

 

On my system, which doesn't have your problem, I have:

 

root@Lapulapu:~# ps aux | grep avahi    
avahi    15421  0.0  0.0  34496  3188 ?        S    Jul28   0:47 avahi-daemon: running [Lapulapu.local]
avahi    15422  0.0  0.0  34236   260 ?        S    Jul28   0:00 avahi-daemon: chroot helper
root     15430  0.0  0.0  12752   112 ?        S    Jul28   0:00 /usr/sbin/avahi-dnsconfd -D
root     27979  0.0  0.0   9656  1860 pts/1    S+   13:50   0:00 grep avahi

 

root@Lapulapu:~# grep avahi /etc/passwd 
avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/false
avahi-autoipd:x:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false

 

Notice that the avahi-daemon is running under the avahi UID. According to the third line of your syslog your system can't find the avahi user. What output do those two commands give on your system? Perhaps your /etc/passwd file has got corrupted, which is odd as it's loaded fresh with each reboot. Perhaps your flash device has got corrupted or your download of unRAID was damaged.

 

Thanks John_M, you hit the nail on the head.  My grep output returned no process running under the avahi user and my passwd file did not have the 2 users listed, so I just copied them from your output and added them, then rebooted.  Everything runs super smooth now an dmy errors are gone.  My grep output looks just like yours as well.

 

I am a little confused though, do you know if this was just added for 6.2, because none of my previous config backups listed avahi as a user in the passwd file either and I didn't have this problem.

Anyway, thanks for the help!

Link to post

 

On my system, which doesn't have your problem, I have:

 

root@Lapulapu:~# ps aux | grep avahi    
avahi    15421  0.0  0.0  34496  3188 ?        S    Jul28   0:47 avahi-daemon: running [Lapulapu.local]
avahi    15422  0.0  0.0  34236   260 ?        S    Jul28   0:00 avahi-daemon: chroot helper
root     15430  0.0  0.0  12752   112 ?        S    Jul28   0:00 /usr/sbin/avahi-dnsconfd -D
root     27979  0.0  0.0   9656  1860 pts/1    S+   13:50   0:00 grep avahi

 

root@Lapulapu:~# grep avahi /etc/passwd 
avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/false
avahi-autoipd:x:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false

 

Notice that the avahi-daemon is running under the avahi UID. According to the third line of your syslog your system can't find the avahi user. What output do those two commands give on your system? Perhaps your /etc/passwd file has got corrupted, which is odd as it's loaded fresh with each reboot. Perhaps your flash device has got corrupted or your download of unRAID was damaged.

 

Thanks John_M, you hit the nail on the head.  My grep output returned no process running under the avahi user and my passwd file did not have the 2 users listed, so I just copied them from your output and added them, then rebooted.  Everything runs super smooth now an dmy errors are gone.  My grep output looks just like yours as well.

 

I am a little confused though, do you know if this was just added for 6.2, because none of my previous config backups listed avahi as a user in the passwd file either and I didn't have this problem.

Anyway, thanks for the help!

 

The Avahi users are not unraid 6.2 specific. They exist even in 6.1.x systems.

Link to post

I do know avahi was in previous versions, I just meant I never saw that user specifically listed in the passwd file.  So I was just curious if 6.2 upgrade was suppsed to add it or something.  It might have been my download being corrupted , but I was just trying to figure what I might have did wrong to have it missing now.

Link to post

Everything was working perfectly with CA's appdata backup to user shares until I wound up installing a new container just to test that it installed ok.

 

Now I'm getting this error:

 

2016/08/02 12:44:34 [6720] rsync: mknod "/mnt/user/Backups/Docker Appdata/2016-08-02@12.43/gitlab-ce/data/gitlab-rails/sockets/gitlab.socket" failed: Function not implemented (38)
2016/08/02 12:44:34 [6720] rsync: mknod "/mnt/user/Backups/Docker Appdata/2016-08-02@12.43/gitlab-ce/data/gitlab-workhorse/socket" failed: Function not implemented (38)
2016/08/02 12:44:34 [6720] rsync: mknod "/mnt/user/Backups/Docker Appdata/2016-08-02@12.43/gitlab-ce/data/postgresql/.s.PGSQL.5432" failed: Function not implemented (38)

  (lots of fun finding 3 errors in a log composed of 200K lines  :)  )

 

Going directly to a disk share instead of a user share works perfectly.  TBH not sure how commonly used this function is (I suspect its very rarely used in appdata)

 

Those are Unix Sockets and are probably pretty rare.  I'll need to check with Tom to see if SHFS (FUSE) is capable of storing unix sockets -- poor guy just got hardlink support in  :P

Only 2 containers I'm aware of at this moment:  Gitlab-CE and dropbox
Link to post

I do know avahi was in previous versions, I just meant I never saw that user specifically listed in the passwd file.  So I was just curious if 6.2 upgrade was suppsed to add it or something.  It might have been my download being corrupted , but I was just trying to figure what I might have did wrong to have it missing now.

 

Right, and I explained that those 2 users are indeed in 6.1.x and not new for 6.2 series.

 

# cat /etc/unraid-version
version="6.1.9"

# grep avahi /etc/passwd 
avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/flase
avahi-autoipd:x:62:62:Avahi AutoIp Daemon User:/dev/null:/bin/false

Link to post

I don't know if this started with rc3 but I noticed something that I don't think happened before, when clicking a disk in standby from the main page, the disk spins up to get SMART info, it then stays spun up but unRAID still shows a grey ball, temp is displayed and it never spins down again unless you click the spin up or access it to turn it green, only then it will spin down after your selected time.

 

P.S.: same happens when getting the diagnostics to any standby disk, that's how I noticed this.

Screenshot_2016-08-06_21_18_24.png.675d70025b9e3ae3442d46da81b37f8d.png

Link to post

Interesting result Johnnie => I just tried that and I get different behavior.    If I double-click on a disk in the Main page, I get the disk info page, but for the Last SMART test results it shows "Unavailable - disk must be spun up"

 

... and the disk isn't spun up.

 

The different behavior could be due to different drives (my 6.2 system uses all older 2TB WD and Hitachi drives); different chipsets (my 6.2 system is on an old SuperMicro C2SEA board); or some other configuration difference.

 

 

Link to post

Interesting result Johnnie => I just tried that and I get different behavior.    If I double-click on a disk in the Main page, I get the disk info page, but for the Last SMART test results it shows "Unavailable - disk must be spun up"

 

... and the disk isn't spun up.

 

The different behavior could be due to different drives (my 6.2 system uses all older 2TB WD and Hitachi drives); different chipsets (my 6.2 system is on an old SuperMicro C2SEA board); or some other configuration difference.

 

I tried in two different servers with different disks and get the same, at first I also see "Unavailable - disk must be spun up", but after a few seconds, after it spins up, it show the SMART info and if you go back to main and click the same disk it already spun up and no more "Unavailable - disk must be spun up".

Link to post

Well ... based on your post I went back and had a look at the server status.  VERY interesting result ...

 

When I tried this a bit ago, I had tried it on 3 different disks [2 WD's -- an EARX and an EADS;  and a Hitachi HDS732020BLA642 ].  Just for grins I took another look at the server status, and indeed the Hitachi now shows the temp, and was clearly already spun up, although the page didn't show that [i determined this by copying a file from it, and the copy started instantly at full Gb speed].

 

Interestingly, once I started the copy, the status on the Main page changed to a green ball and the Dashboard now indicates it's spinning (neither of these was true until I did the copy).

 

But neither of the WD's had these symptoms.

 

Link to post

Hi I have a quick Question about "Your server must have access to the Internet to use the unRAID 6.2-rc"

 

I am using the trial and I think it is great.I am about to buy a licence but I am a bit concerned about always having an active internet connection to verify the licence.

Will this be the case when the final release come out?

 

I might be moving to a house with no internet access for a few months and I am concerned that I wont be able to use my server? :(

 

 

Link to post

Hi I have a quick Question about "Your server must have access to the Internet to use the unRAID 6.2-rc"

 

I am using the trial and I think it is great.I am about to buy a licence but I am a bit concerned about always having an active internet connection to verify the licence.

Will this be the case when the final release come out?

 

I might be moving to a house with no internet access for a few months and I am concerned that I wont be able to use my server? :(

 

For -beta and -rc releases, of all key types, the server must validate at boot time.  The reason is that this lets us "invalidate" a beta release.  That is, if a beta gets out there with a major snafu we can prevent it being run by new users who stumble upon the release zip file.  For example, if there is a bug in P+Q handling.  Remember the reiserfs snafu last year?  We want to minimize that.

 

For stable releases, Basic/Plus/Pro keys do not validate at boot time, that is, works the same as it always has.

 

Starting with 6.2, Trials will require validation with key server.  This is in preparation for making the Trial experience easier.

Link to post

But neither of the WD's had these symptoms.

 

Can confirm that this issue doesn't happen with WD, it does happen on all Toshiba, Seagate and Samsung HDDs I tested.

 

S  T  R  A  N  G  E  :) :)

Link to post

Since the advanced network configuration introduction unRAID is no more hardware-agnostic regarding NICs, replacing a motherboard (should be the same replacing just the NIC) results in no network.

 

This happens even if the board replaced is the exact same model as in the example below.

 

I really like and need the advanced net config, but if it's not possible to make unRAID detect a NIC change I believe it should be mentioned in the release notes that network-rules.cfg needs to be deleted after a NIC change. 

Screenshot_2016-08-07_09_34_09.png.f51dec3d2bf608824578502d4ec6096b.png

diagnostics-before.zip

diagnostics-after.zip

Link to post

Definitely agree this should be highlighted => that's a fairly major change in UnRAID's behavior ... one of the BIG advantages of this nifty little guy has always been that you could just move all your disks to a new system; boot to the flash drive ... and life was good  :)

 

... for that to be no longer the case -- especially even on the same make/model motherboard -- is a pretty big change in behavior !!

 

Link to post

Since the advanced network configuration introduction unRAID is no more hardware-agnostic regarding NICs, replacing a motherboard (should be the same replacing just the NIC) results in no network.

 

This happens even if the board replaced is the exact same model as in the example below.

 

I really like and need the advanced net config, but if it's not possible to make unRAID detect a NIC change I believe it should be mentioned in the release notes that network-rules.cfg needs to be deleted after a NIC change.

 

Just to add to my previous report, today I've done a lot of upgrading and trading boards on my servers and this issue doesn't always happens, didn't pin the reason down but maybe only when the board has multiple NICs, I traded some single NIC boards without issue, maybe the logs I uploaded before can provide some clues.

Link to post

Since the advanced network configuration introduction unRAID is no more hardware-agnostic regarding NICs, replacing a motherboard (should be the same replacing just the NIC) results in no network.

 

This happens even if the board replaced is the exact same model as in the example below.

 

I really like and need the advanced net config, but if it's not possible to make unRAID detect a NIC change I believe it should be mentioned in the release notes that network-rules.cfg needs to be deleted after a NIC change.

 

The file "network-rules.cfg" is only created when more than one NIC is present in your system and is used to make interface assignments persistent across system boots.

 

There is a detection mechanism in place which deletes the file when a change in the number of NICs occurs.

 

As you observed this is not 100% full-proof. In case a system has multiple NICs and these are changed, without the number of NICs changing, it goes undetected. Though one port will become eth0, and it might be necessary to move cables to restore connectivity. This will depend on how the network is configured (bonding, bridging).

 

Link to post

Since the advanced network configuration introduction unRAID is no more hardware-agnostic regarding NICs, replacing a motherboard (should be the same replacing just the NIC) results in no network.

 

This happens even if the board replaced is the exact same model as in the example below.

 

I really like and need the advanced net config, but if it's not possible to make unRAID detect a NIC change I believe it should be mentioned in the release notes that network-rules.cfg needs to be deleted after a NIC change.

 

The file "network-rules.cfg" is only created when more than one NIC is present in your system and is used to make interface assignments persistent across system boots.

 

There is a detection mechanism in place which deletes the file when a change in the number of NICs occurs.

 

As you observed this is not 100% full-proof. In case a system has multiple NICs and these are changed, without the number of NICs changing, it goes undetected. Though one port will become eth0, and it might be necessary to move cables to restore connectivity. This will depend on how the network is configured (bonding, bridging).

Would it maybe be a better to have the change detection rely on not finding any of the original MAC Addresses instead of just the number of NICs?

Link to post
Guest
This topic is now closed to further replies.