Best way to shutdown dockstar?

Given my problems with file corruption documented elsewhere, I'd be grateful for recommendations for best (safest) way to shut down dockstar. With no LED action, and using recommended ADATA flash drive with no read/write light, I'm never sure I am doing it correctly, and experience suggests I may not be.

Currently I have boot flash and storage hard drive attached. I umount /dev/sdb1 (attached hard drive), then do shutdown -h now.

Other suggestions?

Thanks in advance.

geodog Wrote:
-------------------------------------------------------
> Given my problems with file corruption documented
> elsewhere, I'd be grateful for recommendations for
> best (safest) way to shut down dockstar. With no
> LED action, and using recommended ADATA flash
> drive with no read/write light, I'm never sure I
> am doing it correctly, and experience suggests I
> may not be.
>
> Currently I have boot flash and storage hard drive
> attached. I umount /dev/sdb1 (attached hard
> drive), then do shutdown -h now.
>
> Other suggestions?
>
> Thanks in advance.



I can't guarantee this is the best way to do it, but here's what I do. (I also boot from an ADATA flash drive with no access light.)

As I understand it, when the Dockstar (DS) is first powered on, the LED flashes orange indicating that the bootloader has control, and then it goes out and doesn't shine at all, indicating that the linux kernel has taken control.

So to shut it down I issue the command

# shutdown -r now

After a while the LED will start flashing. I pull the power plug at that point while the LED is flashing. Then I power down the two attached usb hard disks. The DS is now powered down.

My reasoning: by the time the LED starts flashing, the DS has shutdown and rebooted but the kernel hasn't taken control yet, and so (presumably) all the applicable "safe unmount" commands have been issued and the attached drives have not been mounted again yet*.

My DS runs as a NAS and torrent/seedbox 24/7, so it's pretty rare that I shut it down, but when I do, I do as above.

*An extra-careful/paranoid step that I take is this: when I boot the DS, the attached drives are powered down. Those drives are not in /etc/fstab. I power up the DS, the LED flashes and then stops. I wait a minute or two and then ssh in to the DS. Then I power up the two attached drives. I wait for their access lights to stop flashing and then I manually mount the drives, e.g.:

# mount -t ext3 -L usb_1 /media/usb_1

etc.

This is pretty "manual", but it works well IME, and I've had no problems with data corruption. Every so often (couple of months), I'll power the DS down, hook the drives up to another machine and run fsck on them using gparted.

Isn't shutdown -r the option to reboot ?

Not sure if I'm right but I use shutdown -h now

-h = halt which stops the CPU at the end

Yes the '-r' option means reboot, but if you just do a 'shutdown' or a 'shutdown -h' (essentially the same thing on the Dockstar) you really have no visual feedback as to when it's safe to unplug the device. By using the '-r' option, you know when the kernel has ceded control and uBoot has again taken control, because the uBoot changes the LED to a flashing sequence, and therefore it is safe to remove power from the device, if you do so quickly. What hanker suggests seems sort of backwards, but it works.

I think both of you guys can stand to do it a little cleaner...

I personally do "sudo halt" for shutting down my system and it's never caused any problems.

However, you should strongly consider using the LED functions to indicate the state your system is in.

in /etc/rc.local

echo none > /sys/class/leds/dockstar:green:health/trigger
echo default-on > /sys/class/leds/dockstar:orange:misc/trigger

My Dockstar blinks green until it starts booting from USB, then it shuts off. When it is done booting and runs through rc.local, it turns the light on solid orange. After 10 seconds after the light goes solid orange, I am able to SSH into my Dockstar.

in /etc/rc0.d/K8halt

        log_action_msg "Will now halt"
        halt -d -f $netdown $poweroff $hddown
        echo none > /sys/class/leds/dockstar\:orange\:misc/trigger
}

Extra lines included to show placement.

When I halt/shut my system down, the USB ports remain powered, so my LCD stays on even when the system is fully shut down. So when I halt the system, have it set the LCD to off and I wait another 10 to 15 seconds before I pull the power plug.

Seems to work pretty well as I haven't had a single shutdown/power loss corruption to my filesystem yet.

rat-netbook Wrote:

> in /etc/rc0.d/K8halt
>
>
> log_action_msg "Will now halt"
> halt -d -f $netdown $poweroff $hddown
> echo none >
> /sys/class/leds/dockstar\:orange\:misc/trigger
> }


Thank you! I'd been wondering how to really use the LED but was too lazy to pursue it. ;)

I'd like to try this but I notice:

$ cat /etc/rc0.d/K8halt
$ cat: /etc/rc0.d/K8halt: No such file or directory

There is something called K09halt that has

	log_action_msg "Will now halt"
	halt -d -f $netdown $poweroff $hddown
}

So I guess I would edit K09halt to have

	log_action_msg "Will now halt"
	halt -d -f $netdown $poweroff $hddown
	echo none > /sys/class/leds/dockstar\:orange\:misc/trigger
}

Is that right?

Also:

/etc/rc.local currently has only some comments and then

exit 0

I assume I would put the

echo none > /sys/class/leds/dockstar:green:health/trigger
echo default-on > /sys/class/leds/dockstar:orange:misc/trigger

before the

exit 0

Is that right?

Thank you for your help! :)

hanker Wrote:
-------------------------------------------------------
> $ cat /etc/rc0.d/K8halt
> $ cat: /etc/rc0.d/K8halt: No such file or
> directory
>
>
> There is something called K09halt that has

The numbering order is less important than the filename itself, so K##halt would be the right file.


> So I guess I would edit K09halt to have
>
>
> log_action_msg "Will now halt"
> halt -d -f $netdown $poweroff $hddown
> echo none > /sys/class/leds/dockstar\:orange\:misc/trigger
> }
>
>
> Is that right?

That should do it. You'll have to edit the file as root, btw.

> Also:
> /etc/rc.local currently has only some comments and
> then
> exit 0

For rc.local, everything goes in before exit 0, as that is the last action of the script. Think of it as another way to say "end". (A bit oversimplified, but it doesn't need to be anything more complex for this situation)

rc.local is Debian's own version of an autoexec/startup script, so this is where you would put other lines in to manually run services that would be system wide. For example, it's how my UPS monitoring service is run:

# By default this script does nothing.

echo none > /sys/class/leds/dockstar:green:health/trigger
echo default-on > /sys/class/leds/dockstar:orange:misc/trigger
/etc/init.d/apcupsd start
exit 0

Pretty handy way to get things running automatically, especially on a system that has no monitor. ;) (rc.local is also where you would put the code in to start up s2205term if you did the keychain lcd hack)

rat-netbook Wrote:
-------------------------------------------------------
> hanker Wrote:
> --------------------------------------------------
> -----
> > $ cat /etc/rc0.d/K8halt
> > $ cat: /etc/rc0.d/K8halt: No such file or
> > directory
> >
> >
> > There is something called K09halt that has
>
> The numbering order is less important than the
> filename itself, so K##halt would be the right
> file.


Very helpful - thank you! :)

Do the scripts above only apply if you have a special kernel, (I've seen some mention of special LED enabled kernel), or will they work for the the standard Jeff script install?

Thanks for all the helpful information.

geodog Wrote:
-------------------------------------------------------
> Do the scripts above only apply if you have a
> special kernel, (I've seen some mention of special
> LED enabled kernel), or will they work for the the
> standard Jeff script install?
>
> Thanks for all the helpful information.


They're not scripts, but more commands you can actually use on the command line in superuser mode.

The led support for the dockstar is in the kernel itself now. You can check now for what led modes are supported on your current kernel by:

cd /sys/class/leds

rat@redstone:~$ cd /sys
rat@redstone:/sys$ cd class
rat@redstone:/sys/class$ cd leds
rat@redstone:/sys/class/leds$ ls
dockstar:green:health dockstar:orange:misc
rat@redstone:/sys/class/leds$

and you'll see what is in there. Sometimes it's plug:green:misc or a variation on that, when it's dockstar specific and recognized (by setting the arcNumber, explained here: http://forum.doozan.com/read.php?2,524,2749#msg-2749 ) ... the entire string, including the colons, is a directory. CD to name:color:type and you'll see a "file" in there called "trigger" - My kernel is the kirkwood one, the naming can be slightly different depending on if it's the standard debian linux kernel or the heavy kernel that a user on this forums is compiling for dockstar users, so check the directory to see what your LED light switch is named as before you add the lines to halt and rc.local.

rat@redstone:/sys/class/leds$ cd dockstar:orange:misc
rat@redstone:/sys/class/leds/dockstar:orange:misc$ ls
brightness device max_brightness power subsystem trigger uevent
rat@redstone:/sys/class/leds/dockstar:orange:misc$

The reason I put "file" in quotes is because it's not really a file, but a toggle.

rat@redstone:/sys/class/leds/dockstar:orange:misc$ cat trigger
none nand-disk timer [default-on]
rat@redstone:/sys/class/leds/dockstar:orange:misc$

Listing the contents of trigger will show you what options you have and what the state it is currently in. My orange light is set to stay on when the system is up and running.

You can ONLY echo, as superuser, the available triggers listed to you when you "cat trigger"...

You'll just be denied if you try to do it as a regular user:

rat@redstone:/sys/class/leds/dockstar:orange:misc$ echo default-on > trigger
-bash: trigger: Permission denied
rat@redstone:/sys/class/leds/dockstar:orange:misc$ su
Password:
root@redstone:/sys/class/leds/dockstar:orange:misc# echo none > trigger

Caused my dockstar led to turn off.

root@redstone:/sys/class/leds/dockstar:orange:misc# echo hfhidihds > trigger
bash: echo: write error: Invalid argument
root@redstone:/sys/class/leds/dockstar:orange:misc# echo default-on > trigger

Turned my light back on after typing gibberish to show you what happens when you give it an invalid trigger setting.

All of the above can be condensed into this:

echo default-on > /sys/class/leds/dockstar:orange:misc/trigger

Which is the line that sets my dockstar light to solid orange in rc.local and that runs on startup.

Wow! I think I am getting way out of my depth here, and a little far afield of best way to shutdown, but it is fun. Thanks for teaching.

So, I have

Quote

root@debian:/sys/class/leds# ls plug:green:health

no dockstar, no orange. Wonder what that means?

Kernel info

Quote

uname -a Linux debian 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux

Tried

Quote

echo default-on > /sys/class/leds/plug:green:health/trigger

command completed successfully,

Quote

cat trigger none nand-disk timer [default-on] mmc0

but no evident change to LED.

geodog Wrote:
-------------------------------------------------------
> Wow! I think I am getting way out of my depth
> here, and a little far afield of best way to
> shutdown, but it is fun. Thanks for teaching.

Heh. I honestly think the Dockstar and Debian are both perfect learning setups. Tinker with both and learn a lot in the process. There's a bit that is unique to using Debian on the Dockstar, but everything I learned about Linux has helped me here, and a few things I learned about Debian on Dockstar has helped me elsewhere. It IS all part of the fun.

> So, I have root@debian:/sys/class/leds# ls
> plug:green:health
> no dockstar, no orange. Wonder what that means?

make sure you typed "ls" by itself. Your quoted section makes it appear that you typed "ls plug:green:health"

rat@redstone:~$ cd /sys/class/leds

rat@redstone:/sys/class/leds$ ls

dockstar:green:health  dockstar:orange:misc

rat@redstone:/sys/class/leds$

> Kernel info
> uname -a Linux debian 2.6.32-5-kirkwood #1 Wed
> Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux
>
> Tried echo default-on >
> /sys/class/leds/plug:green:health/trigger
>
> command completed successfully, cat trigger none
> nand-disk timer mmc0
>
> but no evident change to LED.

If the LED was already on solid, then there's going to be no change anyway, as default-on just means it stays lit. But because you typed plug:green:health, I'm going to take back my previous assumption about your mistyping the LS command and guess that your arcNumber may not be properly set... I had this issue a little while back (the thread I linked in the previous post) that resulted in the same broken-ness of the led controls.

as root:

su
cd /usr/sbin
fw_setenv arcNumber 2998

Reboot. (shutdown -r)

Check your LED directory again...

cd /sys/class/leds
ls

and hopefully you'll see two directories, one for each color.

If so, by that point, it's just a matter of superusering the echo command to the correct whole directory structure.

The arcNumber variable tells the kernel that the machine is a PogoPlug or a Dockstar, thus allowing you the ability to control the LEDs. Rereading the thread, someone else also had the exact same issue I had and that you are describing now... So I think this is the way you need to go. http://forum.doozan.com/read.php?2,524,2761#msg-2761

Follow the codeboxes I typed in above and you should be able to control both orange and green.

Thanks, I was successful in getting the more full featured LED entries after I did fw_setenv arcNumber 2998 as you suggested. However, I am not not able to boot from my new FreeAgentGO drive http://forum.doozan.com/read.php?2,3568 Could it be related? Suggestions?

rat-netbook Wrote:
-------------------------------------------------------
> I think both of you guys can stand to do it a
> little cleaner...
>
> I personally do "sudo halt" for shutting down my
> system and it's never caused any problems.
>
> However, you should strongly consider using the
> LED functions to indicate the state your system is
> in.
>
> in /etc/rc.local
>
> echo none >
> /sys/class/leds/dockstar:green:health/trigger
> echo default-on >
> /sys/class/leds/dockstar:orange:misc/trigger
>
>
> My Dockstar blinks green until it starts booting
> from USB, then it shuts off. When it is done
> booting and runs through rc.local, it turns the
> light on solid orange. After 10 seconds after the
> light goes solid orange, I am able to SSH into my
> Dockstar.
>
> in /etc/rc0.d/K8halt
>
>
> log_action_msg "Will now halt"
> halt -d -f $netdown $poweroff $hddown
> echo none >
> /sys/class/leds/dockstar\:orange\:misc/trigger
> }
>
>
> Extra lines included to show placement.
>
> When I halt/shut my system down, the USB ports
> remain powered, so my LCD stays on even when the
> system is fully shut down. So when I halt the
> system, have it set the LCD to off and I wait
> another 10 to 15 seconds before I pull the power
> plug.
>
> Seems to work pretty well as I haven't had a
> single shutdown/power loss corruption to my
> filesystem yet.


Thanks for the instruction. I've set it up just like you've described. The LED turn green and orange correctly. However, the last step some how did not turn off the orange LED when I do "shutdown" (I did not see the message "Will now halt"). Then I restarted and shutdown again using the halt script directly, and the orange LED was turned off.

geodog Wrote:
-------------------------------------------------------
> Thanks, I was successful in getting the more full
> featured LED entries after I did fw_setenv
> arcNumber 2998 as you suggested. However, I am not
> not able to boot from my new FreeAgentGO drive
> http://forum.doozan.com/read.php?2,3568 Could it
> be related? Suggestions?

Fortunately, it wasn't related to setting the arcNumber, though it shouldn't have been anyway. Partitioning is a little tricky, as you found out. ;) I run into boot issues if I leave my LCD screen plugged in during reboots, so yeah... another lesson learned. ;)

bodhi Wrote:
-------------------------------------------------------
> Thanks for the instruction. I've set it up just
> like you've described. The LED turn green and
> orange correctly. However, the last step some how
> did not turn off the orange LED when I do
> "shutdown" (I did not see the message "Will now
> halt"). Then I restarted and shutdown again using
> the halt script directly, and the orange LED was
> turned off.

Ah yeah, forgot to mention, the shutdown actions are script dependent. Since you added the line to halt, you'd have to do a "sudo halt" to get the LED off indicator that the system is shutting down properly. I try to separate commands so that I don't end up mistyping via muscle memory as easily... so I do shutdown exclusively for rebooting (with -r) and sudo halt for turning off.

Keep playing with it and find places where you can insert the led toggle command for your benefit. Mail waiting, ethernet activity, etc.

Hi,

I had similar idea with using real remote, here is great description (this is for mpd):

http://www.musicpd.org/mpd-lirc-howto/mpd-lirc-miniHOWTO.html

Regards,
Adam.

> -----
> > Thanks for the instruction. I've set it up just
> > like you've described. The LED turn green and
> > orange correctly. However, the last step some
> how
> > did not turn off the orange LED when I do
> > "shutdown" (I did not see the message "Will now
> > halt"). Then I restarted and shutdown again
> using
> > the halt script directly, and the orange LED
> was
> > turned off.
>
> Ah yeah, forgot to mention, the shutdown actions
> are script dependent. Since you added the line to
> halt, you'd have to do a "sudo halt" to get the
> LED off indicator that the system is shutting down
> properly. I try to separate commands so that I
> don't end up mistyping via muscle memory as
> easily... so I do shutdown exclusively for
> rebooting (with -r) and sudo halt for turning
> off.

I guess it's important that the "led part" is executed before the "halt part".

e.g. in my case (GoFlex Net, modified /etc/init.d/halt )

log_action_msg "Will now halt"
halt -d -f $netdown $poweroff $hddown
echo none > /sys/class/leds/status\:green\:health/trigger

doesn't work, but

log_action_msg "Will now halt"
echo none > /sys/class/leds/status\:green\:health/trigger
halt -d -f $netdown $poweroff $hddown

does. BTW, I'd rather use "shutdown -h now" instead of "halt". Although, according to
http://unix.stackexchange.com/questions/8690/what-is-the-difference-between-halt-and-shutdown-commands
halt still executes shutdown when called directly .

Vlad Wrote:
-------------------------------------------------------
> I guess it's important that the "led part" is
> executed before the "halt part".

Considering 'halt' effectively stops the CPU, yes, anything you want performed before the system is completely stopped will have to be before the halt command in the file.