Jak system ma bład na etapie preinit to przycisk nie zadziała.

Natomiast będzie działał failsafe - i wystarczy że uruchomisz go w tym trybie firstboot i masz czysty system.

Failsafe działa w moich obrazach.

PS. Jaki znów custom script zrobiłeś i po co?

1.5.4 w żaden sposób nie zmieniło systemu

Przy starcie naciskasz przycisk. Zobacz sobie failsafe na eko.one.pl. uruchomi się, bo nie uwzględnia wtedy zmian w jffs, więc o ile nie uszkodziłeś firmware to masz dalej normalnie działający system który da się odzyskać.

Działa i działał od zawsze. Nie wmawiaj mi tego.

Dowolny. Działa i reset i qos.

Działa prawidłowo. Nie masz trzymać qos przez 30s tylko wciskać go i puszczać. Zaraz po starcie wejdzie w failsafe.

Dioda musi zacząć szybko migać. Bez tego nie ma failsafe.

Nie, po prostu używam tego samego softu i sprawdziłem że działa.

Failsafe jest funkcją openwrt, nie gargoyle. I od początku w backfire działa popranie.

Zmieniając cokolwiek (np. w preinit) zmiany zapisywane są w jffs. Jak startuje system i wchodzisz w failsafe to jffs w ogóle nie jest montowany więc... nie ma zmian i żadnych problemów. Warunek - squashfs musi działać, nie może być uszkodzony.

PS. Tak, zrobiłem to i działa. I co teraz?
PS1. Kabel szeregowy skoro nie umiemiesz/nie możesz wejść w failsafe.

Bo chodzi. Dlatego właśnie używacie moich wersji, bo jest testowana właśnie na okoliczność tego żeby wszystko chodziło sprawnie.

Jeszcze raz - do failsafe jest potrzebny system który się uruchamia. Choć z tego co piszesz że się pinguje to znaczy że system się podnosi, tylko nie umiesz wejść w failsafe.

Cezary

Dokładny opis tego buga w Backfire dla mr3420 jest zamieszczony tutaj:

https://dev.openwrt.org/changeset/29661

Nie znam sie na budowaniu obrazow OpenWrt i nie wiem gdzie znajduje sie pliczek files/arch/mips/ar71xx/mach-tl-mr3420.c ale raczej nie na routerze i chyba jest to używane podczas kompilacji obrazu? Wydaje się, ze obsluga przyciskow jest gdzieś wkompilowa w kernel albo gdzies?

Z opisu w powyższym linku wynika, że przyciski były źle zdefiniowane.

Z jaką wersją obrazu robiłeś swoje testy? Czy to możliwe, że Ty testowałeś z najnowszą wersją zawierającą powyższego fixa, a wersja użytkownika mdx54 była bez tego fixa? Czy możesz potwierdzić kiedy powyższy fix został dołączony do Twoich obrazów?

Pozdrawiam

Nie, nie trzeba. Dzieki. Wierzymy Ci, ze to działa u Ciebie:)

Inne wytłumaczenie może być takie, ze przycisk QSS na tym routerze jest walnięty. Właśnie go testuje i mdx54 ma racje. Przyciskanie czy przytrzymywanie QSS czy resetu wogóle nic nie daje. Zupełnie tak jakby zdefiniowane były źle przyciski w Backfire.

Objawy też by się zgadzały z opisem mdx54 w jaki sposób został uszkodzony. Router jest pingowalny ale nie wstaje. Moze to sugerować, że 'zawiesił się' w fazie preinit. Wielokrotnie tak miałem podczas testowania skryptów do usb_modeswitcha w preinicie. Ale u mnie na mr3220 failsafe zawsze działał na Twoich obrazach:)

Cezary - Podaj może wersję routera z której korzystasz, może problem jest od niej zależny. Mój MR-3420 jest w rewizji 1.2.
Z informacji na http://wiki.openwrt.org/toh/tp-link/tl-mr3420 wynika że różne rewizje różnią się flash chip'em.

Czy Twoim zdaniem można ubić ten router zmianami w /overlay na routerze?

A jeśli system się wykłada po starcie to dlaczego? W jakich okolicznościach/sposób squashfs może ulec uszkodzeniu?

Może coś powiedzą Tobie okoliczności zaistnienia problemu:
Po zmianie zawartości wewnętrznego /overlaya (modem z extrootem był odpięty) i rebootem puściłem dla pewności sync a potem halt. Po tym odpiąłem i wpiąłem zasilanie, po czym router już niestety nie wstał. Odczekałem chwilę (router potrafił wstawać ze 2-3 minuty). Dioda SYS migała przez cały czas jednostajnie. Przeprowadziłem (nie udaną) próbę resetu firmware'u, odpinając zasilanie i pulsacyjne przyciskając QSS przez dobre 20 sekund od momentu wpięcia zasilania.