1 Odpowiedź przez mru

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Miałem kilka razy podobny problem z zapetlonym rebootem tuż po zainicjowaniu połączenia modemowego. Router tp-link mr3220 v1. System bez extrota. Dodanie swapa na karcie sd nie pomoglo, chociaż objawy wskazywały na problemy z pamiecią. Wszystko działało OK po wyjęciu modemu i reboocie. Nie robiłem testów z zapętlonym ps-em albo dmesg-iem. Nastepnym razem zrobie.

Za każdym razem pomagała mi jedna rzecz:  ponowne granie ROMu (tego samego lub nowszego). ROM wgrywam zawsze factory.bin, nigdy sysupgrade.bin.

Dziwna sprawa, bo niby ten same binarki (read-only) i ta sama podstawowa konfiguracja a mimo wszystko ponowne wgranie ROMu zawsze pomogało. A moze operwrt zapisuje gdzies w /var albo gdzies jakies informacje statystyczne, które przy wgraniu ROMu sa usuwane, a które mogą jakoś wpłynąć na nadmierne użycie pamięci? Nic innego mi nie przychodzi do głowy...

Idź do forum: Oprogramowanie / Software

2 Odpowiedź przez mru

(934 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Czyli: aby zrobić extroot na modemie 3G należy:
- mieć kartę w modemie (!)
- zrobić jej format na ext2
- opkg update; opkg install block-extroot-usb-modeswitch
- zmienić odpowiednio fstab aby na /dev/sda1 ustawić is_rootfs.

Tak, z tym że należy dodać, że instalacja block-extroot-usb-modeswitch nie zawsze jest konieczna. Instalujemy to tylko gdy:

1. Z jakiś powodów nie jesteśmy w stanie, nie możemy lub nie chcemy wyłączyć cdromu (osobiście nie znalazłem sposobu na wyłączenie cdromu w ZTE K3805-Z)

2. usb_modeswitch powoduje odłączenie karty pamięci.

Tu ciekawa historia z moim Huawei E353. Przedostatni raz robiłem upgrade openwrt ze 3 miesiące temu i wszystko mi śmigało pomimo tego, że cdrom był włączony. Po ostatnim upgrade jaki zrobiłem kilka dni temu, extroot na E353 przestał mi nagle działać. Wniosek: w ciągu ostatnich 3 miesiący zostało coś zmienione w którymś z driverów usb albo samym usb_modeswitchu, że karta pamięci jest odłączana przy przełączaniu trybu modemu.

Dodam, że extroot na innym modemie Huawei K3715 działa wyśmienicie zarówno kiedyś jak i dziś z włączonym cdromem...

Pozdrawiam

Idź do forum: Oprogramowanie / Software

3 Odpowiedź przez mru

(934 odpowiedzi, napisanych Oprogramowanie / Software)

dzięki Cezary za  zrobienie tego pakietu! też o tym myślałem ale nie starczyło mi już weny i zapału aby rozkminiać jak zrobić
pakiety na openwert. Specjalnie pisałem ten skrypt w taki sposób aby był uniwersalny i można to było łatwo spakietować.

Wiedze, ze pakiet zawiera tylko jeden plik: 

root@xxxxxxx:~$ opkg files block-extroot-usb-modeswitch
Package block-extroot-usb-modeswitch (1) is installed on root and has the following files:
/lib/preinit/49_usb_modeswitch

a instalacja pakietu dopisała kilka linijek do pliku /etc/hotplug2-init.rules zapewne za pomocą jakiegoś skryptu post-installation? Jednak gdy się usunie pakiet to wpis zostaje. Nie da się tego usunąć jakoś?

A może lepiej zrobić to w troche inny sposób:

1) wrzucić ten ten zmodyfikowany plik do pakietu block-extroot-usb-modeswitch ale pod inna nazwą np. /etc/hotplug2-init-modeswitch.rules

2) zmodifikować hotplug2 w 49_usb_modeswitch aby korzystał z tego nowego pliku:

    killall -q hotplug2
    cp /tmp/overlay/etc/hotplug2-init-modeswitch.rules /tmp
    [ -x /sbin/hotplug2 ] && /sbin/hotplug2 --override --persistent \
             --set-worker /lib/hotplug2/worker_fork.so \
             --set-rules-file /tmp/hotplug2-init-modeswitch.rules \
             --max-children 1 >/dev/null 2>&1 &

Co o tym myślisz? W ten sposób po deinstallacji pakietu wszystko by było ładnie posprzątane. No chyba, że można by usuwać te dodane linijki jakimś skryptem post-desinstallation? Ale nie wiem czy przy pomocy 'opkg remove' można uruchomić jakieś dodatkowe skrypty/polecenia?

BTW. Ciekawy jestem jak będzie to działać z innymi modemami....?

Pozdrawiam

Idź do forum: Oprogramowanie / Software

4 Odpowiedź przez mru

(934 odpowiedzi, napisanych Oprogramowanie / Software)

alekwisnia napisał/a:

Jest może jakaś sprawdzenia logread z poprzedniego uruchomienia? Nie mam pomysłu co w powyższym przypadku może być nie tak.

logi mozna przekierowac do pliku zamiast trzymac w pamieci. Trzeba dodac te dwi linijki do /etc/config/system:

        option 'log_file' '/var/log/messages'
        option 'log_type' 'file'

problemem w powyższym rozwiązaniu jest to, ze na wczesnym etapie /dev/mtdblock3 (ktory jest rw) nie jest jeszcze podmontowany a dostepny jest tylko room (ktory jest read only). Rozwiązaniem może być pisanie logu do /tmp, tyle ze o ile pamiętam to log jest czyszczony za każdym rebootem:(

można tez bezpośrednio w skryptach startowych wypisywać informacje debugujace do /tmp albo albo na pewnym etapie do /tmp/overlay bo tam jest chwilo montowany /dev/mtdblock3

Idź do forum: Oprogramowanie / Software

5 Odpowiedź przez mru

(934 odpowiedzi, napisanych Oprogramowanie / Software)

mozesz sprobować mojego skryptu, który jest kompilacja funkcji do ladowania modułów z /lib/functions/extmount.sh oraz odpaleniem coldpluga z /etc/init.d/boot, co z kolei odpala usb_modeswitcha z odpowiednimi parametrami do kazdego modemu (warunkiem jest aby modem był obslugiwany przez usb_modeswitch).

poniższy skrypt trzeba wrzucic do /lib/preinit aby się uruchamiał przed 50_determine_usb_root, np. zapisać jako plik /lib/preinit/49_usb_modeswitch:

#!/bin/sh
# Copyright (C) 2010 Vertical Communications
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.


usbmodeswitch() {

    mkdir -p /tmp/modeswitch_modules/modules.d
    mkdir -p /tmp/modeswitch_modules/modules
    ln -sf /etc/modules.d/* /tmp/overlay/etc/modules.d/* /tmp/modeswitch_modules/modules.d
    ln -sf /lib/modules/*/* /tmp/overlay/lib/modules/*/* /tmp/modeswitch_modules/modules
    local modules="$(grep -l '# May be required for rootfs' /tmp/modeswitch_modules/modules.d/*)"
    cd /tmp/modeswitch_modules/modules && {
        module_suffix=ko
        case "$(uname -r)" in
            2.4.*) module_suffix=o ;;
        esac
        for m in $modules; do
            case $m in
                *usb-storage*) break;;
            esac
            cat $m | sed -e 's/^\([^#].*\)/insmod \.\/\1.'$module_suffix'/'| sh 2>&- || :
        done
    }
    rm -rf /tmp/modeswitch_modules
                                                                                                                                                                                                                                                                                                          
    mount -t usbfs none /proc/bus/usb 2>&1

    killall -q hotplug2
    cp /tmp/overlay/etc/hotplug2-init.rules /tmp
    [ -x /sbin/hotplug2 ] && /sbin/hotplug2 --override --persistent \
             --set-worker /lib/hotplug2/worker_fork.so \
             --set-rules-file /tmp/hotplug2-init.rules \
             --max-children 1 >/dev/null 2>&1 &

    sleep 5

    for dev in /sys/bus/usb/devices/*/uevent; do
            [ -e "$dev" ] && echo -n add > "$dev"
    done
    sleep 5
}

boot_hook_add preinit_mount_root usbmodeswitch

drugim krokiem jest update pliku /etc/hotplug2-init.rules. Trzeba dopisać sekcje dla usb, tak aby plik wyglądał w następujący sposób:

$include /etc/hotplug2-common.rules

SUBSYSTEM ~~ (usb) {
        exec /sbin/hotplug-call %SUBSYSTEM%
}

SUBSYSTEM ~~ button {
        exec kill -USR1 1
}

Powyższe zostało testowane na huawei e353-s2 oraz zte k3805-z. Powinno działać na innych modemach o ile są zdefiniowane i obsługiwane w usb_modeswitchu.

trik w powyższym skrypcie polega na tym aby odpalić usb_modeswitch przed załadowanie modułu usb-storage, który to rejestruje i montuje storege dla extroota. Nastepnie jest odpalenie hotplug2 z odpowiednio zmodyfikowanym plikiem konfiguracyjnym oraz zrobienie coldpluga. Te dwie ostatnie operacje są po to aby skrypt był bardziej uniwersalny i nie bylo potrzeby ręcznego odpalenia usb_modeswitcha z numerami device'a, który jest inny dla każdego modemu (równie dobrze można by to zastąpić ręcznym odpaleniem usb_modeswitcha z odpowiednimi parametrami).

Idź do forum: Oprogramowanie / Software

6 Odpowiedź przez mru

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Ok, /etc/preinit dziala w skrócie w nastepujacy sposob:

1. source'uje wszystkie pliki z /lib/preinit :

 for pi_source_file in /lib/preinit/*; do
    . $pi_source_file
done

2. po czym odpala na samym końcu wszystkie funckcje/procedury zdefiniowane w powyższych skryptach jako preinit_main

boot_run_hook preinit_main

3. poniżej widzimy kolejność w jakiej odpalane są te funkcje/procedury z kategorii preinit_main z powyższych skryptów:

root@xxx:/lib/preinit$ grep preinit_main *
05_enable_reset_button_ar71xx:boot_hook_add preinit_main preinit_enable_reset_button
05_set_iface_mac_ar71xx:boot_hook_add preinit_main preinit_set_mac_address
05_set_preinit_iface_ar71xx:boot_hook_add preinit_main set_preinit_iface
10_indicate_preinit:boot_hook_add preinit_main preinit_ip
10_indicate_preinit:boot_hook_add preinit_main pi_indicate_preinit
30_failsafe_wait:boot_hook_add preinit_main failsafe_wait
40_run_failsafe_hook:boot_hook_add preinit_main run_failsafe_hook
50_indicate_regular_preinit:boot_hook_add preinit_main indicate_regular_preinit
60_init_hotplug:boot_hook_add preinit_main init_hotplug
70_initramfs_test:boot_hook_add preinit_main initramfs_test
80_mount_root:boot_hook_add preinit_main do_mount_root
90_restore_config:boot_hook_add preinit_main restore_config
99_10_run_init:boot_hook_add preinit_main run_init
root@xxx:/lib/preinit$

4. widac z powyzszego, ze OS czeka na przyciski failsafe (30_failsafe_wait) duzo wczesniej zanim montowanie wszelakich file systemów (80_mount_root). Poniżej jeszcze pokazałem co jest robione przez 80_mount_root. Odpala wszystkie funkcje/procedury zdefiniowane jako preinit_mount_root:

root@xxx:/lib/preinit$ cat 80_mount_root
#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
# Copyright (C) 2010 Vertical Communications

do_mount_root() {
    boot_run_hook preinit_mount_root
}

boot_hook_add preinit_main do_mount_root

root@xxx:/lib/preinit$ grep preinit_mount_root *
10_check_for_mtd:boot_hook_add preinit_mount_root check_for_mtd
20_check_jffs2_ready:boot_hook_add preinit_mount_root check_for_jffs2
40_mount_jffs2:boot_hook_add preinit_mount_root do_mount_jffs2
41_merge_overlay_hooks:boot_hook_add preinit_mount_root merge_overlay_hooks
50_determine_usb_root:boot_hook_add preinit_mount_root determine_external_root
55_determine_extroot_sysupgrade:boot_hook_add preinit_mount_root determine_extroot_sysupgrade
60_pivot_usb_root:boot_hook_add preinit_mount_root external_root_pivot
70_pivot_jffs2_root:boot_hook_add preinit_mount_root rootfs_pivot
80_mount_root:    boot_run_hook preinit_mount_root
90_mount_no_jffs2:boot_hook_add preinit_mount_root do_mount_no_jffs2
99_10_mount_no_mtd:boot_hook_add preinit_mount_root do_mount_no_mtd
root@xxx:/lib/preinit$

Wniosek z powyższego jest taki, że obsługa failsafe jest robiona dużo dużo wcześniej zanim jeszcze podmontowany jest jffs2 ( /dev/mtdblock3 najpierw w /tmp/overlay a pozniej w zależności czy jest extroot czy nie, to /tmp/overlay jest odmontowany całkowicie i montowany extroot, albo zrobiony pivot do /overlay). Czyli failsafe jest robiony całkowicie z squashfs, wiec albo w obrazie Backfire jest bug albo wydarzyło się to co napisał Cezary:

Cezary napisał/a:

1.1 wg obudowy.

Nie można, bo to zwykła zmiana w jffs jest. Natomiast zdarzały się przypadki na innych modelach, że zrobienie czegoś w systemie powodowało uszkodzenie obrazów ze squashfs.

Innych możliwości niestety nie ma skoro system jest pingowalny wiec się musiał w jakimś stopniu załadować i przynajmniej początkowa część preinita musiała się wykonać (chociażby aby ustawić defaultowe IP i uruchomic sieć)....

Idź do forum: Oprogramowanie / Software

7 Odpowiedź przez mru

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Panowie - ma takiego problemu. Failsafe dla MR3420 działa i szukajcie na siłę prób wyjaśnienia czegoś, co w ogóle nie ma miejsca. Mam zrobić tak jak @daniel napisał żeby sami zobaczyli?

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:)

Idź do forum: Oprogramowanie / Software

8 Odpowiedź przez mru

(46 odpowiedzi, napisanych Oprogramowanie / Software)

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

Idź do forum: Oprogramowanie / Software

9 Odpowiedź przez mru

(9 odpowiedzi, napisanych Oprogramowanie / Software)

Dzieki isadjuk za rozwiazanie!!!

A czy udało Ci sie może lub komukolwiek na tym forum uruchomić extroota na tym modemie? Niestety ale podczas przelanczania modemu karta microSD jest na chwile odłanczana. No i oczywiście standardowe komendy dla ZTE do wylaczenia zerocd nie działają na tym modemie

AT+ZCDRUN=8/9 daje ERORR


Pozdrawiam

Idź do forum: Oprogramowanie / Software