Finka

Why? 3.10 is the latest LTS, while 3.12 will be EOL pretty soon, just like we dead ended with the 3.9 EOL in unRAID v.5. Unless there is some veery good reason to move to 3.12, I would much rather we stick to the LTS kernels.

Exactly! --- BTW, I'm still waiting to see Tom clearly state -- one way or the other -- if he endorses other people including and distributing emhttp with other distros.

I don't think unRAID is stupid. Nor do I think it's Hell vs Heaven. This is the third time I've seen this exact same HUGE post copied/pasted in this forum. Posting it three times doesn't make it more convincing. That's what I meant when I compared this thread to a shouting match.

Just because you disagree with someone's opinion is not a good reason to move their posts to "bilge". Quite a few people have quit this forum over such bs in the past. You don't benefit much if you leave just the groupies.

Oh, I've donated too. That's not the point. It's just amusing how they're dancing around it.

So, we finally come to the bottom of it. I guess, that is why it was clearly said in the begining of this thread that there will be no how-to guide on this? You're thying to access if there's money to be made if one cooks up his own distro with emhttp included in it? Want us to make a commitment of some sort, preorder maybe? And, this whole thread turns into a big shouting match "Slackware sux!" when one and the same poster keeps repeating it in numerous posts thruought this thread (scoring more points if he somehow works in the phrase "Fortune 500 Companies" in it). Personally I think Tom made a great decision going with Slackware! Keep it nice and simple. If someone wants a full blown distro, they can always run it in a VM.

Agreed but symbolic linking all the 64 libraries to what emhttp is looking for isn't what I would consider a "good time". Makes managing updates a nightmare to support. You misunderstood. I booted my freshly compiled 64-bit kernel with the stock 32-bit unRAID userspace -- no modifications to unRAID's bzroot whatsoever. (apart from inserting the newly compiled kernel modules in it of course.) This way I can use more than 4GB RAM without a crappy PAE kernel, and at the same time not worry about ugly multilib packages. It's still the same unRAID, booting from the same USB stick, but only with the additional choice of using the 64-bit kernel in the boot menu.

Speed what exactly, and how? Normally emhttp just sits there doing nothing, until you click something in your web browser, then it serves you a web page, and goes back to doing nothing. How is that speed-critical for anything? unRAID in a 64 Bit Linux Kernel is a no brainer. However, emhttp is a 32 bit program so it require you running multilib (64Bit and 32Bit). Linux can do that no problems but its not ideal. Keeping 64 and 32 Bit libraries is unneeded. Even the Linux Kernel dropped i386 support from the Kernel. Anyone bought a 32Bit processor in the last 3 or 4 years? I get that. I've been runnung the last few months my own unRAID build with 64-bit kernel without the need of any multilib (64-bit kernel with the stock 32-bit userspace), and it's been rock-solid. My comment was only to ironicbadger that he can not possibly expect any speed improvements to come from emhttp, as emhttp is not affecting the speed of anything.

Speed what exactly, and how? Normally emhttp just sits there doing nothing, until you click something in your web browser, then it serves you a web page, and goes back to doing nothing. How is that speed-critical for anything?

This is all so very exciting! I take it you dont feel like writing a how-to guide on this. But how about at least writing up the changes in the kernel config? That would be immensely useful for future reference. Also, maybe attach the actual .config file from that compile? I wonder, did you have to make any changes in the unraid driver sources so they could compile in the 3.12.x kernel? Or did they compile just the way they are? (I presume you used the sources that are in 5.0.4, right?) I can't wait to test what you have done there! Please let me know if I can help.

On my server I've observed that md5sum does the job about 50% faster than cksfv. So I keep cksfv only for stuff that comes accompanied by .sfv files from the original publishers, so I can verify that the stuff got to me without any corruption in transit. But for checksums that I create I naturally use md5sum.

LOL that coming from your hosting service! That killed me! I had some problem starting my new car the last few mornings... Maybe the car dealership will advise me that I can simply take the bus to work.

Their servers are randomly aborting the connections. This "working for some" is misleading the investigation. Such reports came from people with faster connections who managed to get the file in full before the server aborted their connection. ~30MB is a small size for a fast conection -- give those people a larger file, and I'm sure they'll notice the disconnects too. And maybe you should.

Suppose you have one data disk which has 5 particular sectors that return random garbage. First, try to find out if such a disk exists. If you're lucky -- those 5 sectors return random garbage ALL the time -- then you can catch it easily: Restart the server WITHOUT emhttp (don't mount any disks) and do something like this: passes=2 for i in /dev/[sh]d? ;do ( for j in `seq 1 $passes` ;do md5sum $i >>/root/${i}.md5 done echo $i ; cat /root/${i}.md5 ) & done wait Observe if the md5 summs change between the passes. If they do, then you've cought the offending disk. Then next step would be try to overwrite the 5 sectors on that disk, and see if the reallocated sectors number changes before and after the overwriting. Note that the above script may take a few days to finish, depending on the number and the size of the disks in the server, so you may want to run the script in `screen`, or at the console. Now, if you're less lucky -- those 5 sectors return random garbage only some of the time -- then the offending disk will be much harder to catch. You may have to increase the number of passes in the script to a bigger number, and that can take a really really long time. Or, you may not be able to catch such a disk, and the problem may turn out to be something completely different, but for lack of any better ideas this exercise is worth the shot. Good luck! Edit: On further thought, since you have the numbers of those 5 sectors, you may write a simpler script which reads multiple times only those 5 sectors on each disk, instead of reading the whole disks, and that will finish the job much faster. But still it doesn't hurt to do a whole read if you have the time.

Could have as well upgraded Samba to the latest in the 3.6.x series. (3.6.20 as of now). For me personally Samba is the most important part of unRAID.