omv

I really like the N54L microserver, except for the lack of sleep. Having to do a full boot cycle to bring my machine out of a low power state is kinda a bummer. Anyone know if the new version fixes this limitation? Thanks!

Here's an updated version -- this one you'd have to background from the go script rather than cron-launch. It has a 15 minute (programmable) countdown from spindown to sleep. While the old one wouldn't corrupt anything, I feel its control mechanism is pretty clutzy - you could get weird cases where upon wakeup it might immediately re-sleep if the drives didn't spin up. Or you hit the spindown button on the gui and shortly after the whole thing shuts down. Now the time intervals are tightly tied together and more predictable for the user: EDIT: Threw in a dchp lease-renewal - my router box seems to forget about the lease (expires) and it doesn't seem like I'm getting an immediate renewal upon wakeup if the lease expired. This rectifies the situation #!/bin/bash drives="/dev/hda /dev/hdb /dev/sda /dev/sdb" timeout=15 count=15 while [ 1 ] do hdparm -C $drives | grep -q active if [ $? -eq 1 ] then count=$[$count-1] else count=$timeout fi if [ $count -le 0 ] then # Do pre-sleep activities sleep 5 # Go to sleep echo 3 > /proc/acpi/sleep # Do post-sleep activities # Force a DHCP renewal (shouldn't be used for static-ip boxes) /sbin/dhcpcd -n sleep 5 count=$timeout fi # Wait a minute echo COUNT $count sleep 60 done

I'm using a shuttle FN95 motherboard - SN25P box, which is a old socket 939 combo. I suspect there's not many (any?) other who use this, but it does require getting the very latest bios to get sleep to work. Previously it would sleep, but not wake up properly. The script does work, but it has some deficiencies. The worst is that there's a possibly of immediate sleep after the hard drives all spin down if cron happens to fire it off at that time. I'm going to rework this to instead have the script do a while loop, check every minute, and do a countdown to prevent the immediate sleep/spindown. Also need to figure out a more generic way of iterating the hard drives instead of hard coding it. And probably put it hooks so it will auto execute scripts right before sleep and right after wakeup. Magic-packet generation will probably be the biggest headache for most users. My OSX boxes have a handy WOL widget, but its not obvious how you'd do this from a TiVo or other media box.

Figured this out on my own - hadn't realized hdparm had a spindown test command. So its a simple matter of a crontab calling something like this: #!/bin/bash hdparm -C /dev/hda /dev/hdb /dev/sda /dev/sdb | grep -q active if [ $? -eq 1 ] then echo 3 >/proc/acpi/sleep fi

I noticed even with my hard drives all spun down, my box dissipates a good 30-40 watts of power. Fortunately, I've finally got my unRaid box correctly going into S3 suspend mode and waking back up with a WOL magic packet. Wooohoo! However, I haven't figured out a good way to actually put it to sleep yet - currently I telnet in and do the "echo 3 >/proc/acpi/sleep", but thats somewhat cumbersome. 1> Hit a URL that makes the machine go to sleep. Is it possible to have the built-in web server run scripts? 2> Have a cron job or background script that periodically sleeps the machine. Unfortunately, I don't know how to detect whether the machine is idle. Is the a way from the command line to detect if all disks are spun down? 3> Other suggestions? I did a bit of searching but couldn't find any posts that looked relevant. Apologies in advance if this is actually a FAQ.

There are some VPN setups like that - one of the vpn solutions we have at work just requires a web browser to be active and I believe uses java on the client side to do the connections. What about using a VPN router box (something like this: http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1115416833192&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=3319254480B03)? That should be a lot easier for a non-expert to configure and not exposure your entire network. Its been a while since I've toyed with these though, so not sure how easy they are to use these days. To echo the others though, I would seriously caution against exposing any services unless you *really* know what you're doing. A couple of my friends and I use to run mail & dns servers, and we all got hacked at least once, despite being relatively advanced users. Now we've all switched to google-mail & external dns so we don't have to worry about it. And if you do go through with it, at least chose a good, strong password. I'm pretty sure my last hacking happened because a user on my server had a weak password and a dictionary attack succeeded. ARGH!

Well, the kernel didn't complain about that option, but no change in behavior for me - my WD5000AAKS drives still won't come up. I also tried putting "option sata_nv swncq=0" in a modprobe.d/ file with the same results. Maybe I'll try building 2.6.27-rc8 and see what happens.

Is there a way to get the sata_nv.swncq=0 parameter to the sata_nv module without rebuilding the initrd filesystem or the kernel? Seems like the kernel rejects it as a option coming in from syslinux, unless sata_nv was built-in rather than a module - or so I infer from what I've read online. Sounds like this is whats causing my 4.4 woes as well (Thanks RobJ for the info)

Hmmm - I think I'm getting problems with the 2.6.26.5 kernel on my box. I got a bunch of messages like: ata1: link is slow to respond, please be patient (ready=0) ata3: link is slow to respond, please be patient (ready=0) ata1: COMRESET failed (errno=-16) ata1: hard resetting link ... When the boot finally finished, both of my Western digital 500GB green drivers were 'missing'. My maxtor SATA & WDC PATA drive did come up though.... Hmm - I removed the 1.5Gb/s link jumpers on one drive and it came up fine, though I'm a bit worried about long-term stability running the drives at full 3Gb/s - the motherboard is an older unit, and I used to get crashes under windows when I ran at full rate -- though with different cables. EDIT: Even with the drives at 3GB/s, they're not coming up reliably. Looks like I'm back to 4.3.3 for now, since the 2.6.24.4 kernel seems immune to whatever is afflicting me.