Debian on NSA325 V1/V2

New install, new hope.
Did all as i did before. Now i get this error while
"apt-get upgrade"

Processing triggers for man-db ...
fopen: Permission denied

Is there anybody using an NSA325v2 with an working install of OMV?

@addy75,

Whatever software you have installed, do some research on this. It's not standard behavior. Perhaps what you've been seeing have something to do with this.

[   30.106761] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I have a nsa325v2 with stock U-boot and set it up with the 3.16 debian rootfs with the watchdog fixed.
Installation on a 60GB Sata drive (old 2.5" hdd).

Everything was fine. Everything is still fine with a barebones debian in a USB drive.

Installed OMV + some plugins that have nothing to do with watchdogs.

Now the dumb watchdog kicks in at around 35 or so seconds after boot, and reboots the box.

The workaround I found to make it boot is to connect UART and prevent autoboot, stay there a bit, and then write boot to boot manually.


I have the strong feeling that all the stuff OMV installed is somehow displacing the watchdog-stopping script or whatever you use to stop the watchdog. What are you using? Is there a way to make sure it runs FIRST before any other debian/OMV startup thing?

otherwise, is it possible to write in the bootargs "prevent autoboot, wait a few seconds and then boot" as that seems to buy more time or disable the dog?

@bobafetthotmail,

> I have a nsa325v2 with stock U-boot and set it up
> with the 3.16 debian rootfs with the watchdog
> fixed.

Make sure you run 3.16.0-kirkwood-tld-2 with stock U-Boot. The fix in 3.16.0-kirkwood-tld-3 works with new U-Boot.

>
> Installed OMV + some plugins that have nothing to
> do with watchdogs.
>
> Now the dumb watchdog kicks in at around 35 or so
> seconds after boot, and reboots the box.
>
> The workaround I found to make it boot is to
> connect UART and prevent autoboot, stay there a
> bit, and then write boot to boot manually.
>
>
> I have the strong feeling that all the stuff OMV
> installed is somehow displacing the
> watchdog-stopping script or whatever you use to
> stop the watchdog. What are you using? Is there a
> way to make sure it runs FIRST before any other
> debian/OMV startup thing?

The fix was in latest U-Boot. So I removed the watchdog stopper in 3.16.0-kirkwood-tld-3. This is so that it does not toggle it back, i.e. turn it back on.

However, if you are running stock u-boot then you must use 3.16.0-kirkwood-tld-2 or earlier (the watchdog stopper is needed to toggle the bit when kernel starts).

> otherwise, is it possible to write in the bootargs
> "prevent autoboot, wait a few seconds and then
> boot" as that seems to buy more time or disable
> the dog?

You could. If you have figured out the correct delay. Some users reported that setting bootdelay env to 20 seconds did the trick. But I'm not sure if it is going to work with OMV which "seems" to resurrect the watchdog (don't know if it's true).

@WarheadsSE,

I'm thinking if this is reported by too many OMV users, I'll look into creating a script to monitor the watchdog GPIO and kill it if the kernel still booting. It might be doable. Perhaps you can comment on this?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/03/2014 03:30AM by bodhi.

In case you were wondering, I nuked "softdog" process you pointed out above for addy75.
Blacklisted its kernel module and disabled the daemon from its config (see here https://tools.bitfolk.com/wiki/Softdog ).

No difference. Reboot at around 30-35 sec from start.

@bobafetthotmail,

> In case you were wondering, I nuked "softdog"
> process you pointed out above for addy75.
> Blacklisted its kernel module and disabled the
> daemon from its config (see here
> https://tools.bitfolk.com/wiki/Softdog ).
>
> No difference. Reboot at around 30-35 sec from
> start.

Thanks for the info. Good to know this for a fact!

If you try UART, stop u-boot and wait at the prompt for longer than 30 seconds. That proved the wathcdog was killed properly. And then you would boot with kernel 3.16 tld-3. See if you still have the watchdog. If you did, then it's good to see the log (i.e. the system time at various points).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/03/2014 03:59AM by bodhi.

@bodhi
The problem is you can not probe for the state of the hardware watchdog.



Edited 1 time(s). Last edit at 11/03/2014 12:46PM by WarheadsSE.

@WarheadsSE,

Thanks for confirming. Not a watchcat, but this watchdog has nine lives :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

sorry for confusion, i have kernel 3.16 tdl-2.

setting bootdelay to 20 works, after the countdown ends it can boot wthout rebooting. Ty a lot for the tip.

You mean UART booting the experimental U-boot? With current kernel first or only with 3.16 tdl-3?
Can try this evening.

bobafetthotmail,

Yes, with the new pre-release u-boot. It is quite stable now, no long experimental. And with kernel 3.16 tdl-3 only.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Need to get that sorted, and merged.

However, due to this "behavior" of the watchdog, it has to be very well documented. I still think that with the NSA325's implementation, we should disable it once uboot has loaded, and then enable it prior to boot. This might even be best to leave as the enable/disable via a well documented environment(!!) command to use with run

@WarheadsSE,

> This might even be best to leave
> as the enable/disable via a well documented
> environment(!!) command to use with run

That's a great idea while u-boot is running! But the problem is once u-boot hand it off to the kernel (starting uImage) we can't run it anymore.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Right. What I am saying is We either need to be determinate that
- when booting we disable it
- before starting the kernel (bootm xxxx) we re-enable it
-- unless we're told not to (aka, a kernel doesn't know to turn it off)

Reasoning being: if your kernel hangs, you might wish the system would reboot. If it takes 30 seconds to get to the kernel board bring up (early system init, board.c) then.. you've got a much larger issue.



Edited 1 time(s). Last edit at 11/05/2014 02:28PM by WarheadsSE.

I see what you meant. I think it is a good approach. So to recap:

Quote

- when booting we disable it
- before starting the kernel (bootm xxxx) we re-enable it according to the following env:

watchdog_enable = 0 disabled
watchdog_enable = 1 enabled

I can add this env to u-boot and make it available only to NSA325.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi: Tried uart booting, but the darn thing keeps erroring at 94-97% saying "protocol error". It takes a bit of skill and timing because the box powers up for a couple seconds, and can begin uart boot, but then reboots. So I need to time the key presses to start sending after this "two-second boot then reboot" moment.
Any ideas on how to pull it off?

Not a fan of flashing the u-boot without some safety net, but anyway, is there anything I need to do before doing it? Does the debian rootfs you provide have the flash_erase and nandwrite?

On the bright side, I'm running with stock Uboot and kernel 3.16 tld-3, the bootdelay of 20 seconds seems to silence the watchdog even after I boot a system that does not kill it.

WarheadsSE Wrote:
-------------------------------------------------------
> Reasoning being: if your kernel hangs, you might
> wish the system would reboot. If it takes 30
> seconds to get to the kernel board bring up (early
> system init, board.c) then.. you've got a much
> larger issue.

As long as it is an option it's ok.

I think that if your board hangs on boot having the watchdog reboot could be pointless (at least in my personal experience, not only with this box), as it will very likely hang again (if your boot fails there is a big issue, not a random lockup) and then will bootloop till someone comes investigating anyway.

Watchdog is useful mostly during operation, when something random can hang the box and a reboot can solve the issue.
So imho the Uboot should keep the watchdog offline then it's the kernel that should (= could, if the user asks for it) give a signal to awaken the dog and then reset the timer every X seconds.

bobafetthotmail,

> @bodhi: Tried uart booting, but the darn thing
> keeps erroring at 94-97% saying "protocol error".
> It takes a bit of skill and timing because the box
> powers up for a couple seconds, and can begin uart
> boot, but then reboots. So I need to time the key
> presses to start sending after this "two-second
> boot then reboot" moment.
> Any ideas on how to pull it off?

Try this smaller UART version. It does not have all features, but works fine as a rescue mechanism. And yes, with the NSA325, we must wait for the initial reset and start UART.

> I think that if your board hangs on boot having
> the watchdog reboot could be pointless (at least
> in my personal experience, not only with this
> box), as it will very likely hang again (if your
> boot fails there is a big issue, not a random
> lockup) and then will bootloop till someone comes
> investigating anyway.
>
> Watchdog is useful mostly during operation, when
> something random can hang the box and a reboot can
> solve the issue.
> So imho the Uboot should keep the watchdog offline
> then it's the kernel that should (= could, if the
> user asks for it) give a signal to awaken the dog
> and then reset the timer every X seconds.

The watchdog is very useful for embedded systems where you have the kernel and rootfs on NAND. I think that's really the goal. For servers, probably useful only in some cases. If your rootfs take too long to mount because of errors, it would make the problem worse! So I agree with WarheadsSE that let users have full control is much better than not. It is depending on your installation that you want to use it or not.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hello,

i got my system working. omv, owncloud, twonky all's working good. Kernel is 3.17.
The only thing not working are the LEDs. I tried to use the settings from davidedg but all leds stay dark only the power led is getting green.

Any idea what to do?

addy75,

Check your /sys/class/leds, and your settings of the LEDS. Some of the LED names were changed in 3.17 in DTS.

# ls /sys/class/leds/ -1
.
..
nsa325:green:copy
nsa325:green:sata1
nsa325:green:sata2
nsa325:green:sys
nsa325:green:usb
nsa325:orange:sys
nsa325:red:copy
nsa325:red:sata1
nsa325:red:sata2

In 3.16 they were set like this:

if [ -d /sys/class/leds/nsa325:green:sys ]; then
   echo default-on  > /sys/class/leds/nsa325:green:sys/trigger 
   echo none        > /sys/class/leds/nsa325:orange:sys/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325:green:hdd1/trigger 
fi
if [ -d /sys/class/leds/nsa325:green:hdd2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325:green:hdd2/trigger 
fi

Adjust them to:

if [ -d /sys/class/leds/nsa325:green:sys ]; then
   echo default-on  > /sys/class/leds/nsa325:green:sys/trigger 
   echo none        > /sys/class/leds/nsa325:orange:sys/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325:green:sata1/trigger 
fi
if [ -d /sys/class/leds/nsa325:green:hdd2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325:green:sata2/trigger 
fi

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/14/2014 07:06PM by bodhi.

@addy75,

Are you running the new u-boot, or stock? sounds like you overcame the watchdog while using OMV.

It would be helpful to other users if you could briefly describe which u-boot image you are using, which kernel version, and what storage devices you are using (USB, HDD, ...) and where is the rootfs resides (USB or HDD).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hello bodhi

thank you a lot for your help in advance.

I'm working with kernel 3.17.0-kirkwood-tld-1 and uboot uboot.2013.10-tld-1.
The system (rootfs) is installed an an ssd, my data-disk is an 4TB WD Red.
System works goods (little problems with the mysql-server for owncloud but i will fixit ;-) )

I adjusted the settings in rc.local. I hope it was the right way but
(I tried to set up as i read on davidedg's home page)
LEDs are not working.
ls /sys/class/leds/ -1

.
..
nsa325:green:copy
nsa325:green:sata1
nsa325:green:sata2
nsa325:green:sys
nsa325:green:usb
nsa325:orange:sys
nsa325:red:copy
nsa325:red:sata1
nsa325:red:sata2

Another question:
wakeonlan -> The only mac i've seen on my router was 00:50:43:00:02:02. The strange thing, i've seen this mac severaltimes here. How can it be? Until now i thougt that macs are unique.
I've found another Mac written under the box 10:7B:EF:..... should i put it in uboot to make wakeonlan working?

Hi addy75,

> I'm working with kernel 3.17.0-kirkwood-tld-1 and
> uboot uboot.2013.10-tld-1.
> The system (rootfs) is installed an an ssd, my
> data-disk is an 4TB WD Red.
> System works goods (little problems with the
> mysql-server for owncloud but i will fixit ;-) )

Thanks! these information are very helpful.

> I adjusted the settings in rc.local.

Yes. rc.local is where they should be. You can also test it at command line to see how they behave:

echo none > /sys/class/leds/nsa325:green:sata1/trigger 
 echo default-on > /sys/class/leds/nsa325:green:sata1/trigger

NOTE: please try again these 2 commands above. I just realized there was an extra space in the middle of the commands (corrected now).

> Another question:
> wakeonlan -> The only mac i've seen on my router
> was 00:50:43:00:02:02. The strange thing, i've
> seen this mac severaltimes here. How can it be?
> Until now i thougt that macs are unique.
> I've found another Mac written under the box
> 10:7B:EF:..... should i put it in uboot to make
> wakeonlan working?

Yes, Zyxel changed it to 00:50:43:00:02:02, but WOL only works with the 10:7B:EF:... MAC address. You should change u-boot env ethaddr to 10:7B:EF...

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/14/2014 07:08PM by bodhi.

I set the 10:BF..... MAC and now WOL works :-)


LEDs aren't working, only system- led is green.

rc.local is

if [ -d /sys/class/leds/nsa325:green:sys ]; then
        echo default-on > /sys/class/leds/nsa325:green:sys/trigger
        echo none       > /sys/class/leds/nsa325:orange:sys/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325: green:sata1/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325: green:sata2/trigger
fi
....
exit 0

should i uninstall esekeyd or it doesn't matter?

Other question:
When is restart the nas the webinterface from owncloud brings the following error "[2002] SQLSTATE[HY000] [2002] No such file or directory"

Then i restart the msqlserver and it works. Can it be an "timing" problem, that the nginx service comes up faster then the sql server? Is there any chance to delay the start on nginx that it starts after the sql server?

addy75,

There was an extra space in the these 2 commands I posted before! (I've modified the post). pls try again:

if [ -d /sys/class/leds/nsa325:green:sys ]; then
        echo default-on > /sys/class/leds/nsa325:green:sys/trigger
        echo none       > /sys/class/leds/nsa325:orange:sys/trigger
fi
if [ -d /sys/class/leds/nsa325:green:sata1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325:green:sata1/trigger
fi
if [ -d /sys/class/leds/nsa325:green:sata2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325:green:sata2/trigger
fi

UPDATE:
The commands were corrected for typos (see addy questions below).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/15/2014 05:51PM by bodhi.

Sorry, maybe i forgot to save.

I've "cleaned" rc.local and putted in

if [ -d /sys/class/leds/nsa325:green:sys ]; then
        echo default-on > /sys/class/leds/nsa325:green:sys/trigger
        echo none       > /sys/class/leds/nsa325:orange:sys/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325:green:sata1/trigger
fi
if [ -d /sys/class/leds/nsa325:green:hdd2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325:green:sata2/trigger
fi

exit 0

but it doesn't work :-(

@addy,

Try execute it at command line:

echo default-on  > /sys/class/leds/nsa325:green:sata2/trigger
echo none > /sys/class/leds/nsa325:green:sata2/trigger

Do you see the SATA2 LED light turned on/off with these 2 commands?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/15/2014 03:17PM by bodhi.

Yes, it turns on and off

Addy,

Oops, typos in the if statements :) But you get the idea? hdd1 and hdd2 were the old settings. Corrected commands should be:

Quote

if [ -d /sys/class/leds/nsa325:green:sata1 ]; then
echo ide-disk1 > /sys/class/leds/nsa325:green:sata1/trigger
fi
if [ -d /sys/class/leds/nsa325:green:sata2 ]; then
echo ide-disk2 > /sys/class/leds/nsa325:green:sata2/trigger
fi

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/15/2014 05:52PM by bodhi.

Is it possible to get USB read/write status on any of the LEDs?

SomeoneOnLine Wrote:
-------------------------------------------------------
> Is it possible to get USB read/write status on any
> of the LEDs?

Not currently. But there is an upcoming kernel patch that will have triggers just like for SATAs. I have not tried to backport it, but it seems doable to incorporate into the kernel 3.17.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

i thought about hdd <->sata .... but then i thougt when you write it, it will be correct.

I'm sorry to say, it doesn't work. The leds stay dark :-(