unRAID Server Release 5.0-rc16c Available

SlrG · July 7, 2013

@madburg:

The memory lines should be too early in the syslog to be caused by any plugin. They may not be real errors but falsely highlighted in red by unmenus syslog utility. So yes, this might be a plugin issue (false alert). Booting in safe mode will not make this lines vanish however, only unmenu won't be present anymore to show the syslog and hightlight them.

Sleep mode is no core feature AFAIK, so booting in safe mode will make the system not go to sleep anymore. The errors will vanish. They were not present in rc12a however and nothing was changed in the plugins on the machine, so it could be something unraid related. I don't know enough to tell myself.

Regarding the jumbo frames mtu 9000, yes this is intentional. I have setup all my systems and network cards to use this, as for me it made a big improvement in transfer rates from and to the unraid server. (around +20 MB/s i think - don't know for sure anymore, as it was quite some time ago, I was playing with this.) It should not be related to the other problems however.

Joe L. · July 7, 2013

@madburg:

The memory lines should be too early in the syslog to be caused by any plugin. They may not be real errors but falsely highlighted in red by unmenus syslog utility.

unMENU's syslog matching rules were updated on June 4th to not show those memory allocation lines as errors. You apparently have not used the "Check-for-Updates" button since then or those error lines would no longer be shown in red.

See here: http://code.google.com/p/unraid-unmenu/source/diff?spec=svn269&r=269&format=side&path=/trunk/syslog_match.conf

Joe L.

madburg · July 7, 2013

@madburg:

The memory lines should be too early in the syslog to be caused by any plugin. They may not be real errors but falsely highlighted in red by unmenus syslog utility. So yes, this might be a plugin issue (false alert). Booting in safe mode will not make this lines vanish however, only unmenu won't be present anymore to show the syslog and hightlight them.

I never stated there were any memory issues

Sleep mode is no core feature AFAIK, so booting in safe mode will make the system not go to sleep anymore. The errors will vanish. They were not present in rc12a however and nothing was changed in the plugins on the machine, so it could be something unraid related. I don't know enough to tell myself.

I never questioned sleep or your choice of plugins, just merely in thought not verbally, to boot in safe mode and manually issue a sleep or install the one plugin manually you require to put your system to sleep if its too complicated, and thereby leaves you with all other plugins not running . If it works at least you know, if it fails in the same way you ruled out another plugin and sleep for you in RC16c (I understand it was a non issue in RC12a for u, alot has changed since then). So without having to mess with your setup/plugins you could use safe mode (go-safe go file) to run some tests for yourself, to narrow things down.

Regarding the jumbo frames mtu 9000, yes this is intentional. I have setup all my systems and network cards to use this, as for me it made a big improvement in transfer rates from and to the unraid server. (around +20 MB/s i think - don't know for sure anymore, as it was quite some time ago, I was playing with this.) It should not be related to the other problems however.

Just curious, don't see many setup jumbo frames. Thanks.

speeding_ant · July 7, 2013

Latest version of hdparm and smartmontools made a difference to GUI load speed with lots of hard drives, my drive health plugin seems to load a lot faster too.

Tom, might be worth including those in the final release - if it's not a big deal.

madburg · July 7, 2013

Latest version of hdparm and smartmontools made a difference to GUI load speed with lots of hard drives, my drive health plugin seems to load a lot faster too.

Tom, might be worth including those in the final release - if it's not a big deal.

Its seriously retarded FAST! makes emhttp actually seems like its not junk.

Joe L. · July 7, 2013

Latest version of hdparm and smartmontools made a difference to GUI load speed with lots of hard drives, my drive health plugin seems to load a lot faster too.

Tom, might be worth including those in the final release - if it's not a big deal.

Its seriously retarded FAST! makes emhttp actually seems like its not junk.

Please continue this thread of updating utilities in a separate feature-request post in the feature-request forum.

There will always be a newer release of smart tools that will interpret the results for the newest disks. Other than your disk not reporting a temperature, I don't think this "compile me" set of requests belongs in this thread.

The links to compiled utilities is fine (as long as you trust the person supplying the compiled program) , just continue it in either the customizations or 5.Xrc.support sub-forum.

Joe L.

speeding_ant · July 7, 2013

Latest version of hdparm and smartmontools made a difference to GUI load speed with lots of hard drives, my drive health plugin seems to load a lot faster too.

Tom, might be worth including those in the final release - if it's not a big deal.

Mr. Ant, did you by any chance have time to reproduce those disconnects you were talking about with less than 4095MB of RAM?

I'll test in the next week or so.

madburg · July 7, 2013

@JoeL. please feel free to move anything u believe doesn't belong here. Even if all this is not my issue, its still something we stumbled across with BIG value for unRAID.

@xnas biggest thanks (again), these two updated components will be installed going forward for me.

I reported hdparm in the LSI card thread long ago (back when 5 was in Beta) and some mods pushed it to Tom, it still took forever (RC5) to get hdparm updated back in the days to its current version in use in unRAID.

Changes from 5.0-rc4 to 5.0-rc5
-------------------------------

- slack: update hdparm to version 9.37

Changes from 5.0-beta8b to 5.0-beta8c
-------------------------------------

- emhttp: enable SMART on drives along with reading temperatures while array is Stopped

Changes from 5.0-beta7 to 5.0-beta8

-----------------------------------

- emhttp: if SMART "Temperature_Celsius" not present, use "Airflow_Temperature_Cel" for disk temperature

Changes from 5.0-beta4 to 5.0-beta5

-----------------------------------

- webGui: use smartctl program to enable SMART and get disk temperatures instead of ioctl()'s.

- slack: update smartmontools to version: 5.40 2010-10-16 r3189.

So this is strange, if SMART is used to get the temp, I understand why under smartmon 5.40 its not read for this one drive, but once on version 6.1 the "Temperature_Celsius" is available but not displayed... almost seems its like unRAID code hardcoded/or loaded in memory and not utilizing the smartctl component itself??? NOt sure if my statement is all too clear, by what I mean there.

P.S. There is nothing bad being said about unRAID or Tom, just that it very much seems unRAID would benefit with having these components updated sooner than later.

WeeboTech · July 7, 2013

I've been following this thread sparsely. I figured if an updated smartmontools helped madburg, maybe it will help with unRAID under ESX.

Previously, unRAID did not detect the spin status or temperature under ESX with RDM/rdmp drives.

I updated smartmontools with pourko's version and I was able to see temps and the drives were not flashing any more.

I can't seem to determine if the drives spin up and down.

Thought i would add it here in case others want to test with it.

@pourko maybe you could open up a google code or google drive account and post the files there.

madburg · July 7, 2013

So this is strange, if SMART is used to get the temp, I understand why under smartmon 5.40 its not read for this one drive, but once on version 6.1 the "Temperature_Celsius" is available but not displayed... almost seems its like unRAID code hardcoded/or loaded in memory and not utilizing the smartctl component itself??? NOt sure if my statement is all too clear, by what I mean there.

Yes, unRaid is shelling out to /usr/sbin/smartctl for the temperatures. Nothing's "preloaded", it does it on demand, every time you refresh your webGui.

Confusion here then, so IF you are correct in that statement, once I upgraded smartmontools to 6.1 it should be displaying the Disk#17 drive temp, BUT its not

WeeboTech · July 7, 2013

Try and capture all the smartctl temperature lines.

smartctl -a /dev/sdc | grep -i 'emper'

root@unRAID1:/boot/packages# smartctl -a /dev/sdc | grep -i 'emper'

194 Temperature_Celsius 0x0022 117 113 000 Old_age Always - 33

It could be spelled or cased differently or a different attribute or number of fields then expected.

this might work better


for drive in /dev/sd[a-z]
do smartctl -a ${drive} | grep -i emper
done

190 Airflow_Temperature_Cel 0x0022 065 056 045 Old_age Always - 35 (Min/Max 28/36)

194 Temperature_Celsius 0x0022 035 044 000 Old_age Always - 35 (0 21 0 0 0)

194 Temperature_Celsius 0x0022 118 113 000 Old_age Always - 32

194 Temperature_Celsius 0x0022 118 111 000 Old_age Always - 32

194 Temperature_Celsius 0x0022 118 114 000 Old_age Always - 32

My other Machine.

194 Temperature_Celsius 0x0002 162 162 000 Old_age Always - 37 (Min/Max 17/39)

190 Airflow_Temperature_Cel 0x0022 064 060 045 Old_age Always - 36 (Min/Max 14/40)

194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 14 0 0)

190 Airflow_Temperature_Cel 0x0022 064 061 045 Old_age Always - 36 (Min/Max 15/39)

194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 15 0 0)

194 Temperature_Celsius 0x0002 166 166 000 Old_age Always - 36 (Min/Max 14/40)

MADBURG'S DISK 17

194 Temperature_Celsius 0x0002 206 206 --- Old_age Always - 29 (Min/Max 18/36)

TheDragon · July 7, 2013

Previously, unRAID did not detect the spin status or temperature under ESX with RDM/rdmp drives.

I updated smartmontools with pourko's version and I was able to see temps and the drives were not flashing any more.

I can't seem to determine if the drives spin up and down.

Thought i would add it here in case others want to test with it.

Thanks for pointing that out WeeboTech! I was previously planning to setup unRAID under ESXi, but since my motherboard and CPU combo don't support VT-d I had to back out - due to lack of temperatures and spindown support for RDM'd drives.

I'll give this a go tomorrow... will be great if this works!

Sent from my Nexus 7 using Tapatalk HD

Joe L. · July 7, 2013

So this is strange, if SMART is used to get the temp,

It was my understanding that unraid does not invoke smartctl to get the temperature, but performs the equivalent internally. I do not have any smartctl commands in my syslog on a stock unRAID on rc16c. (and I do show disk temperatures) Perhaps you are using SimpleFeatures or unMENU (I know unMENU uses smartctl to get the temps)

I understand why under smartmon 5.40 its not read for this one drive, but once on version 6.1 the "Temperature_Celsius" is available but not displayed... almost seems its like unRAID code hardcoded/or loaded in memory and not utilizing the smartctl component itself??? NOt sure if my statement is all too clear, by what I mean there.

P.S. There is nothing bad being said about unRAID or Tom, just that it very much seems unRAID would benefit with having these components updated sooner than later.

I agree, but the attached versions would never be easily found in this thread dealing with this specific release candidate... That it is why they are better in the general support thread or in the customizations thread where more people will find them.

As far as trusting a compiled program, my advice stands for ANY compiled program. There is a risk involved as you are typically running the program as "root." I've never seen any malicious programs posted in these forums, but on occasion there have been coding errors in add-ons that changed /tmp to be read only, or removed programs that they should have left alone. (These were because of the user's inexperience in coding)

It is far less likely to have malicious code in a compiled object, but I remember one white-paper written by one of the authors of UNIX in 1984.

http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

After reading it, you'll understand my view-point. You'll need to trust the author(s) of any compiled code. 8) It is not even enough to inspect the source code and compile the object yourself...

Joe L.

madburg · July 7, 2013

I figured if an updated smartmontools helped madburg..

It will help everyone physical or virtual. I only have one setup so I do believe what speeding_ant said, the more drives you have the more you will notice the speed in the webgui and other background code that utilizes these components. Anyone can test with a smaller setup, time unRAID coming up, open the WebGui, (dont auto start array) start array, spin down drives, spin up drives, select various other WebGui tabs and sub selections and you will see the difference immediately.

WeeboTech · July 7, 2013

due to lack of temperatures and spindown support for RDM'd drives. I'll give this a go tomorrow... will be great if this works!

You will need to be near your machine to see if they spin down or spin up.

I cannot tell at the current moment, the AC is on, I'm blasting Santana and programming.

While the drives did not show spin up or spin down before in my HP micro server.

I could tell they were spinning down due to time to access and hearing them spin up.

Too much going on for me to verify this right now.

madburg · July 7, 2013

So this is strange, if SMART is used to get the temp,

It was my understanding that unraid does not invoke smartctl to get the temperature, but performs the equivalent internally. I do not have any smartctl commands in my syslog on a stock unRAID on rc16c. (and I do show disk temperatures) Perhaps you are using SimpleFeatures or unMENU (I know unMENU uses smartctl to get the temps)

That is what I am thinking/seeing here, and why I asked xnars IF he's sure, because thats not what I am seeing... so thanks for chiming in Joe L.

Not sure why Tom choose going this route, maybe something to the effect it would spin-up a drive if he didnt do it his way... Tom would have to chime in here, would be interesting to know what his code is looking for. I mean it states in the release notes but clearly there is more to it, as the value is available.

I understand why under smartmon 5.40 its not read for this one drive, but once on version 6.1 the "Temperature_Celsius" is available but not displayed... almost seems its like unRAID code hardcoded/or loaded in memory and not utilizing the smartctl component itself??? NOt sure if my statement is all too clear, by what I mean there.

P.S. There is nothing bad being said about unRAID or Tom, just that it very much seems unRAID would benefit with having these components updated sooner than later.

I agree, but the attached versions would never be easily found in this thread dealing with this specific release candidate... That it is why they are better in the general support thread or in the customizations thread where more people will find them.

If you feel something should be moved, no problem. It seems some look at it two different ways, your a mod and empowered to make the decision.

As far as trusting a compiled program, my advice stands for ANY compiled program. There is a risk involved as you are typically running the program as "root." I've never seen any malicious programs posted in these forums, but on occasion there have been coding errors in add-ons that changed /tmp to be read only, or removed programs that they should have left alone. (These were because of the user's inexperience in coding)

It is far less likely to have malicious code in a compiled object, but I remember one white-paper written by one of the authors of UNIX in 1984.

http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

After reading it, you'll understand my view-point. You'll need to trust the author(s) of any compiled code. 8) It is not even enough to inspect the source code and compile the object yourself...

Joe L.

No discussion or arguments here. I reviewed the code to my best ability for anything blatin, and you are right it could be the source code itself. But thats the same for Toms source

So I am at a stalemate, xnars knows how to compile this stuff light years faster than I could, we are seeing eye to eye who the source code it coming from, so it is what it is.

RC15a could bite me in the butt since yesterday with the low voltage Con Edison has put my neighborhood on as of yesterday, my UPS are compensating for all my electronics in the home, but no UPS component to shut it down unRAID! if it goes lower than what it is already (105.1 VAC coming in). THus when I woke up this morning, my hesitation to go to RC15a to see if this drive behaves the same in that release (even though it had not previously), so I am trying to power thought this to see what's up with RC16c until this heat way and Con Edision get their act straight.

P.S. I am not using simplefeatures or unMenu.

madburg · July 7, 2013

So this is strange, if SMART is used to get the temp, I understand why under smartmon 5.40 its not read for this one drive, but once on version 6.1 the "Temperature_Celsius" is available but not displayed... almost seems its like unRAID code hardcoded/or loaded in memory and not utilizing the smartctl component itself??? NOt sure if my statement is all too clear, by what I mean there.

Yes, unRaid is shelling out to /usr/sbin/smartctl for the temperatures. Nothing's "preloaded", it does it on demand, every time you refresh your webGui.

Confusion here then, so IF you are correct in that statement, once I upgraded smartmontools to 6.1 it should be displaying the Disk#17 drive temp, BUT its not

I am pretty sure I am correct in that statement, but the logic of your conclusion breaks. Your "Disk#17" is a peculiar case. Tom only knows how he parses the strings he gets from smartctl. (And btw, a slight change in that string output -- like with a new version of smartctl -- carries the possibility to break unRaid's interpretation of those strings.)

I think you're wrong here, I have the output for smartctl from the other drive(s) and Disk #17 and the entire output is the same. He is not parsing out the output from smartctl at it seems right now its more to what Joe L. stated. Otherwise I would not have temps for any of the drives once I upgraded the smartmontools to 6.1, based on your statement.

speeding_ant · July 7, 2013

It was my understanding that unraid does not invoke smartctl to get the temperature, but performs the equivalent internally. I do not have any smartctl commands in my syslog on a stock unRAID on rc16c. (and I do show disk temperatures) Perhaps you are using SimpleFeatures or unMENU (I know unMENU uses smartctl to get the temps)

FYI, SimpleFeatures only uses smartctl for the Disk Health plugin. I agree, I believe Tom has his own implementation for temperature. Not sure why the webGUI is faster - perhaps placebo

madburg · July 7, 2013

Try and capture all the smartctl temperature lines.

You probably didn't have a chance to read through some of my posts. I posted all the results from smartctrl and hdparm on Disk #17 & #16 and got temp for disk#17 (once upgrading to smartmontools 6.1), but will execute your code to show as well.

194 Temperature_Celsius 0x0002 146 146 000 Old_age Always - 41 (Min/Max 18/43)

194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 17/40)

194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 18/41)

194 Temperature_Celsius 0x0002 162 162 000 Old_age Always - 37 (Min/Max 17/41)

194 Temperature_Celsius 0x0002 157 157 000 Old_age Always - 38 (Min/Max 17/40)

194 Temperature_Celsius 0x0002 157 157 000 Old_age Always - 38 (Min/Max 17/40)

194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 17/41)

194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 17/40)

194 Temperature_Celsius 0x0002 157 157 000 Old_age Always - 38 (Min/Max 25/42)

190 Airflow_Temperature_Cel 0x0022 064 051 045 Old_age Always - 36 (Min/Max 29/37)

194 Temperature_Celsius 0x0022 036 049 000 Old_age Always - 36 (0 19 0 0)

194 Temperature_Celsius 0x0002 171 171 000 Old_age Always - 35 (Min/Max 14/37)

194 Temperature_Celsius 0x0002 176 176 000 Old_age Always - 34 (Min/Max 15/36)

194 Temperature_Celsius 0x0002 171 171 000 Old_age Always - 35 (Min/Max 15/37)

194 Temperature_Celsius 0x0002 176 176 000 Old_age Always - 34 (Min/Max 18/37)

194 Temperature_Celsius 0x0002 176 176 000 Old_age Always - 34 (Min/Max 18/36)

194 Temperature_Celsius 0x0002 171 171 000 Old_age Always - 35 (Min/Max 18/37)

madburg · July 7, 2013

... Not sure why the webGUI is faster - perhaps placebo

Its faster because https://sourceforge.net/apps/trac/smartmontools/ticket/93

RobJ · July 7, 2013

Upgraded from 5.0RC15a to RC16c

1) WebGUI dog slow to load.

2) Disk#17 (sdp) no temps once the WebGui came up, started array, still no temps.

Stopped array and rebooted just incase (should not be the case but didn't hurt), same issue no temp for Drive #17 (sdp).

Moving (clicking) around the WebGui dog slow to load anything.

So the drive is definitely spun up (data accessible).

Looks like something wrong with either Drive 17 (sdp) or its port. All of the other drives are found and setup in the normal time, and sdp begins like the others, but fails to complete the initialization until well after the first inventory. In fact Disk 17 shows as missing in the first array import section. Then sdp completes its setup and its MBR is read:

Jul 6 22:38:59 Tower avahi-daemon[2471]: Service "Tower" (/services/afp.service) successfully established.
Jul 6 22:39:22 Tower sshd[2485]: Accepted password for root from 192.168.0.5 port 59944 ssh2

Jul 6 22:39:22 Tower sshd[2489]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory

Jul 6 22:39:22 Tower sshd[2489]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory

Jul 6 22:39:35 Tower kernel: sd 0:0:13:0: [sdp] Write Protect is off

Jul 6 22:39:35 Tower kernel: sd 0:0:13:0: [sdp] Mode Sense: 00 00 00 00

Jul 6 22:39:35 Tower kernel: sd 0:0:13:0: [sdp] Write cache: enabled, read cache: enabled, supports DPO and FUA

Jul 6 22:39:35 Tower emhttp: shcmd (13): rmmod md-mod |& logger

Jul 6 22:39:35 Tower kernel: md: unRAID driver removed

Jul 6 22:40:14 Tower kernel: sdp: sdp1

Jul 6 22:40:54 Tower emhttp: shcmd (14): modprobe md-mod super=/boot/config/super.dat slots=24 |& logger

The next inventory shows sdp, and the next array import list shows Disk 17, so it all starts as normal from then on. BUT! The mode sense values above are all zero, so something is still wrong. Below is an example of the mode sense values for ALL of your other drives:

sd 0:0:12:0: [sdo] Mode Sense: 7f 00 10 08

If you have another empty port, try moving Disk 17 to it, in order to determine whether it is the port or the drive. If no other port, then swap ports with another drive and Disk 17, and see if the issue moves with the drive or stays with the port. There are no disk errors present, so probably not a problem with the cable. Before you ask, I have no further understanding of the mode sense values, just that they don't match any other drive, and that the drive took far too long to initialize.

WeeboTech · July 7, 2013

You probably didn't have a chance to read through some of my posts. I posted all the results from smartctrl and hdparm on Disk #17 & #16 and got temp for disk#17 (once upgrading to smartmontools 6.1), but will execute your code to show as well.

I was looking to see if there was a pattern on all the drives.

root@unRAID2:/# cat /etc/unraid-version

version=5.0-rc16b

Here's what I saw when I refereshed the gui.

root@unRAID2:/# while true; do ps -ef | grep smart | egrep -v grep; sleep .5; done

root 4062 2415 0 18:16 ? 00:00:00 /usr/sbin/smartctl -n standby -A /dev/sdc

root 4063 2415 0 18:16 ? 00:00:00 /usr/sbin/smartctl -n standby -A /dev/sdd

root 4064 2415 0 18:16 ? 00:00:00 /usr/sbin/smartctl -n standby -A /dev/sde

root 4065 2415 0 18:16 ? 00:00:00 /usr/sbin/smartctl -n standby -A /dev/sdf

Joe L. · July 7, 2013

So this is strange, if SMART is used to get the temp,

It was my understanding that unraid does not invoke smartctl

That is what I am thinking/seeing here, and why I asked xnas IF he's sure

Just for fun...
0 root@VBox-v5-RC:~#
0 root@VBox-v5-RC:~# strings /usr/local/sbin/emhttp | grep smart
/usr/sbin/smartctl -n standby %s -A /dev/%s
0 root@VBox-v5-RC:~#
Of course, I admit, that may mean nothing. It may be an old string just left there.

You beat me to it... (I was eating dinner)

It appears as if Tom is using a belt-and-suspenders approach. First try using an IOCTL call (the belt), then, if that does not work, see if smartctl can return something (the suspenders).

madburg · July 7, 2013

OK, sooo much brain power here and linux is not my thing :-[

I have to go have dinner with the family, which is a good thing so I can step back and think this through.

@RobJ thats what was bugging me, and why I want to go back to 15a so badly and see if this drive, cable or connection, etc... went south at a bad time. Stuff does happen unfortunately. And I am starting to feel as good as all this was/is with stumbling on trying new updates to components it is not the the root cause for this drive issue. I am going to come up with a complete plan to find the drive slot (kicking my self I never got around to labeling the hotswap tray's, probably will start a large file copy to the drive and see which it is). Stop the array, remove and re-insert, and see if it comes back good or not. If not then move to another empty slot for now (like your idea to swap with other drive, but in the current state don't want to subject another drive to that port, just incase). Its on a norco backplane (5 in total) like all the drives, so agree doesn't look like a cable and if its a port, I would think all drive on that backplane would be acting up, but we will see. Will post update on this.

@WeeboTech, @xnars, @JoeL. I didn't understand which linux command I should have ran from those posted, and can an explaination be given, having a hard time understanding what each is doing exactly. I appreciate all the suggestions but you guys have me lost on these last two and believe it or not don't feel comfortable unless I do understand. If you have a moment to explain one or both., great, if not no worries.

My main goal should be what RobJ pointed out, and get to the root cause of what's going on with this drive/sas cable/sata port/backplane. Suck because I know I didnt touch anything physically for the upgrade, actually haven't touch the server in the rack for well over a month +... :'(

mr-hexen · July 7, 2013

upgraded 5.0-rc15a to 5.0-rc16c yesterday. woke up this morning and server was crashed.

webgui - dead

addons (cp, SB, transmission) - dead

telnet - dead

console - dead

was forced to perform a unclean reboot.

rieserfs replayed 300 or so entries and parcheck started.

its @ 97% now and 0 errors were corrected/detected.

could not capture a syslog as it was frozen and I had no means to do it.

unRAID Server Release 5.0-rc16c Available

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment