Pink Pogo (v2) E02 - What arcNumber?

[LavaChild]

Just followed the PogoPlug v2 instructions and changed UBoot. The script output:

Setting arcNumber to 2097 (SheevaPlug)
Note: if you have a kernel that supports your platform, you should use the proper arcNumber.
You can set the correct arcNumber by running the following command:
/usr/sbin/fw_setenv arcNumber 2998

However, I read the following thread on this forum: viewtopic.php?f=18&t=2101

This suggests 3542. So, do I go with 2097, 2998 or 3542? Obviously there has to be Kernel support... Is there Kernel support for all of these arcNumbers, such that if I were to reboot without the USB ALARM drive the Pogo OS would boot fine?

Thanks!

[kmihelich]

There is kernel support for all of them in our latest kernels. The only difference you will see is NAND partitioning (which will be a problem if you're using that for anything) and whether or not LEDs work or are addressed properly.

2097 = Sheeva, 2998 = Dockstar, 3542 = Pogo v2.

[moonman]

3542 is the one you need. The only difference is that LED will be proper color now.

[LavaChild]

Thank you for your prompt replies!

[PogoDancer]

3542 is the one you need. The only difference is that LED will be proper color now.

Could you define "proper", i.e. which color it ought to show in which state?
While the original POGO-E02 firmware is using a green LED (on black "pinkpogos" sold off mislabelled as P24s lately), following

Code: Select all

/usr/sbin/fw_setenv arcNumber 3542

as per this thread (on Linux alarm 3.1.10-13-ARCH these days) rather than

set the correct arcNumber by running the following command:
/usr/sbin/fw_setenv arcNumber 2998

the LED now blinks amber during boot, then stays lit this way, even after "shutdown -h now" which this Pogoplug never seems to complete.

[agillis]

If you add this to /etc/rc.local the LED should turn green after boot.

Code: Select all

echo none > /sys/class/leds/status\:blue\:health/trigger
echo default-on > /sys/class/leds/status\:green\:health/trigger

If your really clever you could add some if condition to this script to make sure the system is really working before you turn the LED green.

[moonman]

Good find, although rc.local won't work with systemd.

[WarheadsSE]

Not without adding the needed bits, but it can be done.

[byteme]

If you add this to /etc/rc.local the LED should turn green after boot.

Code: Select all

#!/bin/sh
echo none > /sys/class/leds/status\:blue\:health/trigger
echo default-on > /sys/class/leds/status\:green\:health/trigger

If your really clever you could add some if condition to this script to make sure the system is really working before you turn the LED green.

Put that in a script (I used /usr/local/bin/ledboot.sh) and make a service file for systemd

Code: Select all

nano /usr/lib/systemd/system/ledboot.service

PASTE THIS:

Code: Select all

[Unit]
Description=LED Turn Off
After=syslog.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/ledboot.sh &

[Install]
WantedBy=multi-user.target


then:

Code: Select all

systemctl enable ledboot

reboot and enjoy

As a side note, I like my lights off.

Code: Select all

#!/bin/sh
echo "none" > /sys/class/leds/status\:blue\:health/trigger
echo "none" > /sys/class/leds/status\:green\:health/trigger

And this will make the LED blink on hard drive access. iostat will accept specific partitions. check the man page. You can use vnstat and do the same for network (use a little math to set a threshold), blink on web server access, etc. You can use each led for a different function.

Code: Select all

echo "timer" > /sys/class/leds/status\:blue\:health/trigger
iostat -z -d 1 | sed -u -e '1d' -e 's/Device.*/0/' -e 's/sd.*/100/' -e '/^$/d' > /sys/class/leds/status\:blue\:health/delay_on &