Joe L.

Tom, Glad the fix to the management screen was easy. (add tzset() when timezone is changed) OK... (dumb, but OK) I checked a few more web-sites and at least one Linux distribution recommends NOT linking to the GMT timezone files as they are misleading.. That page in fact said: Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8. That make sense, the timezone rarely changes between calls to the localtime() routine and it would be pointless to re-read the file every time. Thanks for clearing up the confusion. It is still very confusing when looking at the output of the Linux "date" command to see GMT+5 when I know I'm GMT-5 and that is what it says on your management screen drop-down list. Perhaps a FAQ question/answer on your web-site is in order. Joe L.

The workaround is still a bit confusing... I set the timezone to GMT-5 and the datetime to 3/23 6:29:00 AM, set the time by pressing "Apply" then stopped the array and rebooted The management screen now shows GMT-5 (good) but it shows the time as 3/23 9:40:59 AM when I checked after the unRaid server rebooted. Logging in a telnet window as root I type "date" (a few minutes later) and get Tower login: root Linux 2.4.31. root@Tower:~# date Thu Mar 23 09:47:06 GMT+5 2006 Now, the time seems off by 3 hours from where I set it. The time-zone appears to be GMT PLUS 5 rather than GMT MINUS 5. So I still did not get the time set to where I wanted... As a final test I create a file on one of the unRaid disks and look at it from a windows box like this: date >/mnt/disk1/test_date.txt In windows explorer it shows a modified datetime of 3/23/2006 at 9:59 AM Opening it in notepad the contents of the file (the output of the unix date command I used to create it) are: Thu Mar 23 09:59:11 GMT+5 2006 looking in /etc I see the following: -rw-r--r-- 1 root root 58 Mar 23 09:33 localtime lrwxrwxrwx 1 root root 29 Mar 23 09:33 localtime-copied-from -> /usr/share/zoneinfo/Etc/GMT+5 This seems to confirm the PLUS 5 vs. the MINUS 5 hour offset I intended from UTC. Lastly since internally Lunix keeps UTC time and everything else is for display only.., root@Tower:/etc# date -u Thu Mar 23 15:17:41 UTC 2006 Looking on the web using a browser, the current UTC time is 12:17 PM on March 23rd. (about 3 hours off from my server's idea of UTC) Finally, from the telnet window I set the UTC time using the date command (this eliminates the timezone as a factor) root@Tower:/etc# date -u 03231250 Thu Mar 23 12:50:00 UTC 2006 and then see the effect by invoking the date command once more... root@Tower:/etc# date Thu Mar 23 07:50:09 GMT+5 2006 Looking at the management utility (pressing the refresh button on the browser) I see the correct time (finally) and even GMT-5 as the offset (finally) I'm so confused... (glad you were able to look at the source of localtime.c to figure it out) There appears to be more than one issue. The three hour difference from what I intended to set the time, and also the GMT offset from localtime of PLUS vs MINUS. Joe L.

I'm one of the beta-testers of release 2.060315. One of the new features is support for setting the time-zone from the unRaid web-based management utility. I don't think it is working properly. Now... I can test the effect of the management screen time and timezone fields by using a "date" command in a telnet window. So ... first I use the "date" command in the telnet window root@Tower:/var/log# date Wed Mar 22 00:27:55 GMT 2006 I then check the management screen. It shows GMT as the time zone, but shows 3/21/2006 4:27:43 PM as the current time. Now, GMT matches, but 4:27PM is 4 hours prior to the date shown in the telnet window. Why is there an offset? OK, now I change the timezone using the management screen to GMT-4 and press "APPLY" The screen refreshes, the timezone is now GMT-4 and now the datetime it shows is 3/21/2006 12:27:43 PM I'm a bit confused... the time shown on the management screen changed 8 hours, not 4. I then try the "date" command from the telnet window. root@Tower:/var/log# date Tue Mar 21 16:37:26 GMT+4 2006 OK... it changed... from 00:27 on the 22nd to 16:27 on the 21st. again a difference of 8 hours. Now All I did was change the time-zone. It appears as if the offset is being applied twice. OK.. lets leave the timezone alone and try to set the time from the management screen. Currently, the management screen shows 3/21/2006 12:39:14 PM with a timezone of GMT-4 The "date" command in the telnet window shows: root@Tower:/var/log# date Tue Mar 21 16:39:16 GMT+4 2006 the time differs by 4 hours. Is the management screen trying to show me UTC? Note that the date command shows GMT+4 while the management screen shows GMT-4 Ok, now I want to set the time and leave the timezone allone. I use the management utility to set the time field to 3/22/2006 09:19:00 PM and leave the timezone setting at GMT-4 and press "APPLY" The screen refreshes... the timezone stayed at GMT-4, but the "current time" now shows 3/22/2006 5:19:00 PM (4 hours earlier than where I just set it. I did NOT expect it to change from the value I just entered ) Lets see what the "date" comand shows in the telnet window... root@Tower:/var/log# date Wed Mar 22 21:19:34 GMT+4 2006 Seems to me the UNIX time is where I set it (9:19 PM) but the timezone is set to plus 4 rather than minus 4 hours. Tom, might this be a bug with the new timezone feature? I can't set the time from the management utility and have it show me the same value I set. Joe L.

You will need to make the parity drive the first drive on the main IDE controller and, as already described, it must be as big or bigger than any of the other drives. It does not need to have a file system on it. I would disconnect all the other drives initially until I got the unRaid software to where it could boot from the flash drive. Don't know if your motherboard will boot from the USB port, don't know if the built in networking chipset is supported, don't know if performance is as good as the recommended motherboard, but other than that, you should be in fine shape and as Tom has said, you can mail the unRaid flash back to him if not satisfied and get your money back (you must pay to mail it back, but that won't be much...) You do realize that you will be switching from a full version of Linux to one stripped down to act as network file sorage. If you are looking for xwindows, desktop, email, etc you will not find them in unRaid. If you are looking for network storage, and not much else, it might be exactly what you are looking for. Joe L.

Tom, I looked in /etc/samba/smb.conf on my server and it looks like SO_RCVBUF and SO_SNDBUF are not both set to 65535. The line in my config file set them like this SO_RCVBUF=66535 SO_SNDBUF=65535 Could this be a typo and you intended to enter 65535 instead of 66535 for SO_RVCBUF? Might it work better with the 65535 you might have intended as the receive buffer size? Joe L. Contents of /etc/samba/smb.conf follow: root@Tower:/etc/samba# cat smb.conf [global] # configurable identification include = /etc/samba/smb.names log level = 1 log file = /var/log/samba.%m max log size = 2000 socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=66535 SO_SNDBUF=65535 disable spoolss = Yes show add printer wizard = No security = SHARE guest account = root guest ok = Yes guest only = Yes read only = No map archive = Yes map system = Yes map hidden = Yes [flash] path = /boot # auto-configured shares include = /etc/samba/smb.shares

This is good news... the fix is far easier than some obscure programming bug. I might offer that using the words "Rebuilding Data on Disk" or "Restoring Data on Disk" might be more correct than "upgrading" since under many conditions you will be replacing a failed drive with one of the same size. Joe L.

Didn't you once post that your development systems also ran unRaid? I've always said there are only two kinds of hard-disks... (no, not IDE and SATA) The two kinds are Hard disks that have already crashed Hard disks that have not yet crashed It is only a matter of time. Joe L. Waiting patiently... as Tom feverishly does his pre-release testing.

Tom, I'm going to take a wild-guess at something here... based on my own programming experience and how the unRaid array has occasionally acted for some folks. The issue with replacing a small drive with a larger one, and where it works for you Tom, but not for Richard, almost sounds like it could be related to a class of coding error where memory is allocated, but not properly initialized before use. In some systems, depending on the specific ram, memory used by programs might start out with zeros. In others, the contents could be random and result in the error Richard is seeing. It might explain why the error does not show up in your test machine. Back when I was coding in "C" on AT&T based UNIX there was a command "lint" that would check and report on this class of error. In other words, it would warn developers of variables referenced before their contents are initialized and/or set. I remember having to do "memset" on allocated memory prior to using it to ensure its contents were in a known state. In other words, perhaps no error actually occurred, and nothing explicitly set the disk "invalid" flag, but it was implicitly set because it originally had a non-zero value when allocated and nothing initialized it to zero in your code. I think I may have seen evidence of this myself the last time I re-booted my unRaid server when I added a UPS, but in a slightly different fashion. After adding the UPS I re-started my unRaid array and it started my small "check_unraid.sh" script to monitor its status. (the shell script was posted to the AVS thread months ago) The script then reported that my unRaid array had experienced a failure. Looking at the management page showed nothing odd. Typing "cat /proc/mdcmd" showed the normal status values, but also showed segments of the same check_unraid.sh shell script interspersed with the status values... including the "grep command" line from my shell script within it scanning for abnormal disk status Now, it was looking for specific status values and found them (it found itself), it reported an error, even though one had not occurred. It almost seemed that memory used by the virtual file "mdcmd" under the /proc directory had not been initialized when it had originally been allocated. Now, I can't really know if this is what is happening, but it sure would explain why some people have this issue and others do not. If your management utility opens /proc/mdcmd to read the array status it might be fooled into thinking the array is invalid if it does not find the values it expected. It might also explain why it works when the array is reset. Again Tom, if I'm off base and you already checked for this class of bug, ignore this post and keep looking. I know I have accidentally made this class of coding error (at least once or twice in my programming carreer ) and have occasionally found errors like it in my code reviews of developers work on my project teams over the years. I figure if nothing else, it might give you an idea or two if nothing shows up in the syslog Richard sends to you. Joe L.

That was exactly 4 months ago. Hopefully you can understand the lack of patience in my tone... So I'll ask the question again. When can we expect the driver source to be available? I'm certain Tom understands his obligations under the GPL... He has been inactive and missing for those same 4 months due to some personal issues... yes, ignoring his unRaid product, his prior customers, and everything, including the GPL obligations. I am very happy to see Tom active again and getting back to where he can support the unRaid product. This forum is a great first step, addressing/fixing bugs in unRaid and addressing concerns of the current customers is a close second. You could argue that GPL compliance should be first, but most of us are happy to see Tom active again, in any way. Without his involvement and support, the unRaid product is dead. At this point it will take a steady commitment from Tom to make things right and restore confidence in him and his product. I see signs of that commitment and want to give Tom some time to "catch up" (as he phrased it) With Tom's participation the unRaid product can live and be improved, and comply with the GPL. From my limited understanding of the GPL Tom must do the following to be compliant: 1. Include the GPL license text as a file on the flash drive. 2. Include the GPL license text on his web-site. 3. Provide a way to request the source code to the unRaid driver he developed under the GPL. Since the unRaid is not available as a "download" he is not under an obligation to provide a link to "download" the source, although he could, but that must not be the primary method of distribution since some do not have the ability to download files. He must however, provide the source "at cost" via mail upon request. (the fee to only cover reasonable duplication and postage costs) Basically, a geek like me could then compile the code under a Linux 2.4 kernel. Since Tom is in the process of supplying an "upgrade" (any hour now ) he has the first opportunity to add the GPL text file to the download comprising the upgrade. Once he does that, and makes the corresponding changes to his web-site, he will be well under way towards compliance. We have been waiting for this upgrade since last October when it was initially promissed/scheduled. I personally am very happy Tom is back and slowly getting things organized, even if not as fast as you would like. I hope he gets his personal issues resolved quickly so he can focus on the unRaid product. Like you, I will be making my request for the driver source code as permitted under the GPL and will probably set up a development box to play with compiling too. I have a LOT of experience in improving performance of programs, I would love to look at the code to see if I could make suggestions to improve it for everyone's benefit, myself included. Joe L.

Actually the unRaid management page is using port 80. It must for your browser to work without having to specify a port. ie http:\\tower:12345 So, you could configure your home firewall/access point to pass port 80 of tower out to the real world, but... since ANYONE could then administer your unRaid array since the page has no built in security, it would probably not be a good idea. Wait for Tom to add security in some future release, only then, and only if the admin page requires a password,would I open it up to the outside.

Tom, Not sure if these links will give you any clues, but I did a bit of searching with google and perhaps one of them might help. This following message from a Linux kernel mailing list seems to describe the issue some are having with lockups. It specifically mentions the 20265 and 20267 chipset on the Promise controller, but the file it is being applied to is named pcd202XX so it may apply to the 20268 chipset on the current Promise cards. http://marc.theaimsgroup.com/?l=linux-kernel&m=104250818527780&w=2 This following link is to a very long thread of messages that describe a similar patch for the 20265 thru 20270 chipsets http://kerneltrap.org/node/3040 It contains links to various patches including proposed patches to the 2.4 and 2.6 kernels. Another thread describes how the Promise card ends up in an infinite loop, waiting for an interrupt that never occurs because interrupts have been disabled. http://www.uwsg.iu.edu/hypermail/linux/kernel/0102.0/1334.html It suggests replacing a "while" loop with a call to a timer. This unsigned long timeout = jiffies + ((HZ + 19)/20) + 1; while (0 < (signed long)(timeout - jiffies)); gets replaced with this mdelay(50); Notice nothing in the "while loop" decrements the counter. Apparently, the counter is decremented in an interrupt driver routine. If the interrupt never occurs, the loop runs forever. (These new 3GHz machines run infinite loops reallllllly fast, but they still seem to take forever to run :() It mentions that if you have the NMI Watchdog enabled, you will get nice "oopses." NMI (non-maskable interrupt) watchdog can be enabled as shown on this link http://slacksite.com/slackware/nmi.html by adding "nmi_watchdog=1" to the boot parameters in the grub menu. This does not fix the Promise controller bug, but it will apparently reboot the system if it gets hung. Might this be something an unRaid user could try. Do we have support for the NMI watchdog in our kernels? Joe L.

This is mentioned in the "browser based tutorial" on the main unRaid site, but it does not go into detail and it refers to the process using slightly different terminology... it mentions "initialize the array" and the button is actually labeled as "reset the array" [pre] >Suppose I want to remove a hard disk and I don't plan on replacing it? In this case you should initialize the array configuration data so that the system can generate new parity information. [/pre] Stop the unRaid array using the "Stop" button on the bottom of the unRaid admin page and then power down. After powering down, removing the drive, and reboot... Again stop the unRaid array using the "Stop" button on the bottom of the unRaid admin page Click on the "Tools" link at the top of that same page once the array is stopped. Once on the "Tools" page check the box to indicate you are sure you want to reset the array configuration, and then press the button. It will take a while (4 or more hours if you have large drives) to rebuild the parity drive, and then you will be back to normal, but without the drive you removed. Joe L. (I've never done this, just reading and interpreting what I've read, so Tom... correct me if I did not get this right )