nars

The problem is caused by you replacing menu.c32, as vmdk probably have an older syslinux version "installed" and it's not compatible with latest menu.c32 binary. Anyway you don't need to update menu.c32 to get safemode option, that was added on syslinux.cfg, not on menu.c32.

Flag file will need to be removed else it will always reboot on safe-mode... problem to get it from unmenu is to get out of safe-mode, but it may just tell user how to do it

Problem will be to get out of safe-mode But unmenu may tell user how to do it manually or how to manually run unmenu on safemode...

I guess you did already chkdsk it on a windows machine (or used dosfsck) and it returns to this problem? Anyway I would just try to backup all files on a windows machine and re-format it then restore files, if you didn't tried it yet.

Thank you, downloading now

Apparently the problem is with your 'sdb' hdd, though I'm not fully sure if these 'read dma' errors may be caused by communication problems with the hdd (data cable, controller, etc...) or an internal error on the hdd, you may try checking data cable anyway or just wait some expert to comment this.

To get smart status just telnet your unraid machine and use: smartctl -a /dev/sda smartctl -a /dev/sdb smartctl -a /dev/sdc ...

Could be better you post full syslog (Utils -> System Log)... if all errors refer to "ata2" device I guess it may be a problem with that hdd or data cable (you can identify what one by searching on syslog for ata2, first lines found, from system boot, should help you identify it). Posting smart status for your hdd's may also be useful.

There was another user with same problem and also with SF... I would try to disable it... or make sure you have the latest version of it... Packages on 'extra' folder doesn't seem the cause of the problem, I did tried it and can't reproduce it, installpkg seems to create /var/log/setup/tmp automatically when trying to install any packages, with no problem at all, I can only guess some plugin attempts to do something on that path... Anyway, Tom said it should be fixed on next version.

Tom knows it said it will be fixed on next version, anyway this is probably caused by some plugin... in the mean time if you want you either downgrade or you can try to disable your plugins and try to identify what one is causing it.

Sorry, what is the "trust array" procedure? I believe he is referring to this old procedure: http://lime-technology.com/wiki/index.php/Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily This forum post talks about it and what you can do instead with Release 5.0: http://lime-technology.com/forum/index.php?topic=19385.0 Yep that's the one but even that version 5 workaround is not working .... at least i never got it to work tried with and without page refresh or are we supposed to do it different way ? as you made a check thingie for trust parity ? Read from Joe L. post at http://lime-technology.com/forum/index.php?topic=19385.msg197921#msg197921 , the only way on latest versions seems using Utils->New Config and then "parity is correct" checkbox, but you need to manually reassign all drives on the right slots... Anyway that is not a thing you want to do often, I think...

Indeed I didn't noticed yesterday that WeeboTech's ST's where different sizes, then surely they should be very different on speeds etc... but well maybe controller related or something. One small thing I can also add re my system it's that my wd red's are connected on sata3 ports while greens on sata2. Btw, my final values (with rc11a, still using it on my 'production' server) are: parity WDC_WD20EFRX-68AX9N0_WD-WMC300050457 (sda) 1953514552 36°C 2 TB - 17038735 22 0 disk1 WDC_WD20EARX-00PASB0_WD-WCAZAE848879 (sdc) 1953514552 34°C 2 TB 389.08 GB 7871592 11 0 disk2 WDC_WD20EARX-00PASB0_WD-WCAZAE866220 (sdd) 1953514552 33°C 2 TB 1.61 TB 6798799 11 0 Concerning the '1' writes you are seeing... the kernel on rc14 is 3.4.x like on my rc11a, then there should be no huge changes on that... and I can tell you that on rc11a I don't get any writes at all exactly during parity check... but... I did always noticed that when I start array there is some immediate read/writes and... after some 15-30 seconds there is 1 write done to each hdd... this may be what you are seeing if you started array and then just started parity check before these 15-30 seconds? on rc15 these '1' writes 15-30 seconds after array start indeed doesn't exist (and in fact the count of the ones done immediately after starting array are also less, I did also noticed that on rc13) but I guess it may be most probably related to file system handling differences on latest kernels.

Maybe his ST's are more equal in speed then not causing such waits and I/O combining? Thanks for the clarification Tom.

or rc16 hehe hopefully not btw Tom, when possible.. if you could please give a quick look and comment something about this: http://lime-technology.com/forum/index.php?topic=27893.0 thanks.

garycase you are not mad, I notice same... and I'm sure it's not any reads from anything else done at same time as parity check... I know that when I start array there are some (very few) reads/writes at mounting file systems (a fixed amount for all hdd's, something like 22/11 or similar, I can't see exact numbers now as I'm doing full parity check but it's near that) however after that I can leave it running for hours that they will not increase for sure, also I have near stock unraid, no plugins, no unmenu. When doing parity check my parity drive (wd red) shows about double reads of my data drives (wd green), and even wd green ones show some considerable difference between them. I would also like to know a reason for this... maybe because there is differences on drive speeds (green near 120MB/s and red near 150MB/s at start of hdd, also access times different, etc) that cause some weird read ahead or some synchronization scheme that may eventually need to re-read data or something similar to get on sync while trying to achieve best possible performance? Maybe only Tom may reply this... 85% parity check (sorry I can't wait it finish now, will post finished values tomorrow): parity WDC_WD20EFRX-68AX9N0_WD-WMC300050457 (sda) 1953514552 31°C 2 TB - 14259728 22 0 disk1 WDC_WD20EARX-00PASB0_WD-WCAZAE848879 (sdc) 1953514552 34°C 2 TB 389.08 GB 6868085 11 0 disk2 WDC_WD20EARX-00PASB0_WD-WCAZAE866220 (sdd) 1953514552 31°C 2 TB 1.61 TB 5873243 11 0

Loading it on my test system, thank you and hope it solves all problems

@jaybee: ... or if you are not comfortable with editing it just get syslinux.cfg file from rc13, rc12, ... as it defaulted to no memory limit on these versions (in fact mem option doesn't limit but force that memory amount, that's why you can't boot with 2GB, then the problem you get it's normal and others got it too, don't mess with bios options ).

I did started reading calypsocowboy posts and also thought if maybe the problem may not be related to that "new" 10s timeout to wait usb flash to be mounted on init script, as on some tests I made recently to get unraid running from an hdd, on one boot attempt I did without an UNRAID partition available I did see the lines and wondered myself... damn it only waits this and ceases? what if for some reason, on some system (not sure if possible but... sometimes all it's possible ) things take some more time to get ready? maybe increasing it to 20 or 30 seconds could be an idea to be safer that it is really enough?

Just for eventually pushing Tom#1 you are already doing an wonderful job

If I was you I would update it... maybe we will get rc15 soon but apparently Tom is still trying to get netatalk issue sorted before that, rc13 haves some more problems as you may have read (incl the crashs when stoping array). All you need to do on your 2GB system to have no problems with rc14 is just don't update syslinux.cfg then you will not get the mem=4095M param on it... i.e. just update bzimage and bzroot and you will be ok.

Thank you for the update, glad to see things moving and to know that 64-bit version is on the way And besides sync issue I would not hurry to get to very latest kernel, 3.4 is lts and seems very stable/mature thing... that is the most important after all...

As I said I don't see that needing extra work, just automate it to compile kernel twice and get two files ready, simple and easy, that's why I suggested it else I would not do it. But surely it's down to him. As for the four years... I can't comment, despite I did read a LOT on forum, I'm on the "boat" only since September of last year... my 1st version was rc8 (and I did purchased it with such status and knowing how much time it was rc, etc) I did see a few rc's since then, sorting multiple problems, new problems coming, some getting hard to get a solution and eventually waiting kernel or other opensource developers to get them fixed, realtek issues, etc... etc... but now... other than the slowdown issue, that can be sorted easily, we seem to have a pretty stable version, right? Tom did recently invested on new site, Tom#2, new servers for sale, etc... then... the time to get a stable 5.0 final PROPERLY released must be now. Anyway I don't want to get on this kind of discussion as I don't think it will help on anything... I did just posted my humble opinion on what I think would be the best option nothing more

Getting back to the pills from the other topic... - Red Pill: I guess Tom surely haves some kind of script to automate release, packing, etc... so... I don't really see a big big problem to provide 2 kernels or even two independent download packages (maybe even better, easier for users, smaller download... just explain on site the difference of both...), just add a couple of lines to release packing script to compile kernel twice (PAE and non-PAE), automatically, pack two versions instead of one, that probably will mean just 10-20 extra minutes (processing time) to finish a release of the two flavors, am I wrong? (if you followed the sync thread a few days ago you may have read that I did compiled and repacked unraid with near 10 kernel versions in one day for testing sync issue, I did it with minimal effort with a small poorly written script that did all the job for each kernel version and I ended with a lot of bzimage_x.x.x/bzroot_x.x.x files to test... 20 min to fully prepare each version... minimal manual work... that's why I don't see why not provide 2 kernels on each release?) IMO this would be probably the best option possible, a real solution, that should ensure stability/compatibility for who requires non-PAE and PAE for who wants/needs it, if and only if I'm correct that Tom can fully automate it (I don't really see why not) and that it will not mean more work for him... - Blue Pill: This is the easier and faster option, release just PAE enabled and the affected users will add mem option, rename sysconfig.4gb to sysconfig.cfg file as said above, or whatever to WORKAROUND it with the mem option. Only Tom can select what one to "take", what one is viable for him... and I guess it's no sense to start an "your chance to chime in" topic here again for two months about this... That's just my two cents.

This should do it: sed -i " s/ show_disk / \$show_disk /" /usr/local/emhttp/plugins/indexer/Browse.php You can put it at the end of your "config/go" script or just run it each time you reboot. It specifically looks for show_disk proceeded by a space, si it does no harm if run multiple times or on a subsequent repaired file. Or just run it once in terminal??? EDIT: I suppose not huh? /usr/ is in ram isn't it? So this NEEDS to be run each boot to patch the file in ram? correct.