Jak coś, to napisałem kawałek artykułu na temat tego całego AdGuard. Może się komuś przyda.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez morfik
Jak coś, to napisałem kawałek artykułu na temat tego całego AdGuard. Może się komuś przyda.
1. Robisz nową "zone" na WAN-ie o nazwie "lte" więc przydałoby się w pliku 01-config.sh dopisać jeszcze zasady firewalla dla strefy o tej nazwie. Wyglądałoby to bardziej profesjonalnie, bo nie każdy na szybko skapnie się, że tak trzeba lub po prostu zapomni.
No ja u siebie w skrypcie mam konfigurację FW:
uci del firewall.@zone[1].network
uci set firewall.@zone[1].network='wan wan6 lte'
Dopiszę zaraz tam do artykułu -- zapomniałem o tym. Jakby nie patrzeć ten mój skrypt ma trochę tych poleceń.
2. Dodałbym jeszcze ustawienie strefy czasowej. Ładnie wygląda gdy router ma prawidłowy czas zamiast UTC.
No te ustawienia można mnożyć dlatego podałem w zasadzie dwa przykłady -- na WiFi i LTE, a reszta to już zależy od usera co sobie tam ustawi.
No to mniej więcej dobre miałem zrozumienie tego jak to działa.
W sumie temat już wyczerpałem, bo udało mi się ten obraz dostosować do swoich potrzeb. Jak coś to tutaj skrobnąłem kawałek artykułu, może się komuś przyda.
Czyli ten openwrt-19.07 to nie jest stable? Bo ja myślałem, że w master robią zmiany i w pewnym momencie robią dajmy na to openwrt-19.07 i mamy wydanie stabilne. A później to wydanie stabilne jest utrzymywane przez jakiś czas i poprawki do niego trafiają, a jednocześnie w master rozwój idzie osobno by za jakiś czas przygotować nowe wydanie stabilne. To tak nie jest w przypadku OpenWRT?
Wydanie stabilne w określonej wersji (tag) nie zmienia się. Jeżeli zaś wybraliśmy całą gałąź wersji stabilnej to są tam wprowadzane poprawki dopóki jest ona utrzymywana (to z niej właśnie kiedyś może powstać następna wersja stabilna oznaczona określonym numerem). Aktualizację tej gałęzi można wykonać poleceniami (będąc w katalogu ze źródłami):
To po co jest w takim razie master?
No możesz wywalić, choć pewnie ludzie tak jak ja poszukują bardziej aktualnego stable niż jedynie określonego release.
Chyba wyłapałem lekką nieścisłość w tym twoim arcie o kompilacji.
Piszesz coś takiego:
$ cd ~
$ git clone https://github.com/openwrt/openwrt.git
$ cd openwrt
$ git fetch --tags
$ git checkout v19.07.2
A później coś takiego:
Aktualizacja
...$ git pull
$ make package/symlinks
$ make defconfig
To tak nie zadziała. Jak się wyda po pobraniu źródeł git checkout v19.07.2, to się dostanie HEAD detached at v19.07.2.
Z tego co wyczytałem to nie jest zbyt miły stan, bo można stracić bardzo łatwo wszystkie zmiany, które się w tych źródłach wprowadzi (nie że bym coś zmieniał ale lepiej tego unikać).
Do tego problem jest z aktualizacją. Dla przykładu, tuż po wydaniu polecenia git checkout v19.07.2, mam taki log:
$ git log
commit 33732f4a9c17921b782167a0dcaba9703d4e6753 (HEAD, tag: v19.07.2)
Author: Jo-Philipp Wich <jo@mein.io>
Date: Thu Feb 27 22:34:09 2020 +0100
OpenWrt v19.07.2: adjust config defaults
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
To jest najnowszy commit. Jak widzisz, data jego wskazuje na Feb 27. Jak się teraz wyda polecenie zaktualizowania remotki:
$ git remote update && git status
Fetching origin
HEAD detached at v19.07.2
nothing to commit, working tree clean
To nie ma żadnego nowego commit'a. Z kolei jak wejdziesz na git'a OpenWRT, to zobaczysz coś takiego:
29 hours ago Adrian Schmutzler Revert "ramips: disable ZyXel Keenetic by default" openwrt-19.07 commit | commitdiff | tree | snapshot
29 hours ago Alexey Dobrovolsky ramips: use full 8MB flash on ZyXEL Keenetic commit | commitdiff | tree | snapshot
6 days ago Dan Haab bcm53xx: add support for Luxul FullMAC WiFi devices commit | commitdiff | tree | snapshot
6 days ago Rafał Miłecki bcm53xx: refactor board.d code in 02_network commit | commitdiff | tree | snapshot
6 days ago Rafał Miłecki bcm53xx: sysupgrade: optimize building UBI image commit | commitdiff | tree | snapshot
...
To są commit'y z gałęzi openwrt-19.07 . Jeśli teraz zamiast git checkout v19.07.2 wydasz, git checkout openwrt-19.07 ,to:
$ git checkout openwrt-19.07
Updating files: 100% (7970/7970), done.
Branch 'openwrt-19.07' set up to track remote branch 'openwrt-19.07' from 'origin'.
Switched to a new branch 'openwrt-19.07'
oraz
$ git remote update && git status
Fetching origin
On branch openwrt-19.07
Your branch is up to date with 'origin/openwrt-19.07'.
nothing to commit, working tree clean
i jeszcze log:
$ git log
commit 01b624e28ec7e45573e6c501125510c19f64c257 (HEAD -> openwrt-19.07, origin/openwrt-19.07)
Author: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Date: Wed Apr 8 22:08:46 2020 +0200
Revert "ramips: disable ZyXel Keenetic by default"
This reverts commit c38074de929e6f7c089e2cb7f81746ba90ddf16b.
Since ZyXEL Keenetic has actually 8 MiB flash as fixed in the
previous patch, we can re-enable it.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
I jak widzisz, commit w tej gałęzi jest z Apr 8 i gdyby teraz wyszły jakieś nowe commit'y to git remote update by je dostrzegł i można by je było pobrać via git pull.
Także chyba trochę musisz ten artykuł przerobić.
już sprawdź sobie który jest który bo nie pamiętam
Ten root-ath79 ma dodane pliki z katalogu files/
No to jeszcze takie pytanie, bo tam są dwa root. Czym się różni root.orig-ath79 od root-ath79 ?
Albo po prostu rozpakuj (w zależności od routera albo unsquashfs albo extract plików z ubifs), albo spójrz do build_dir, tam jest katalog rootfs* którzy zawiera system plików przez spakowaniem do obrazu.
Nie do końca to rozumiem.
$ unsquashfs openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin
Can't find a SQUASHFS superblock on openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin
Czyli unsquashfs odpada?
Co do tego extract, to w debianie jest w zasadzie tylko taki extract:
# aptitude show extract
Package: extract
Version: 1:1.9-3+b1
State: not installed
Priority: optional
Section: utils
Maintainer: Bertrand Marc <bmarc@debian.org>
Architecture: amd64
Uncompressed Size: 453 k
Depends: libc6 (>= 2.4), libextractor3 (>= 0.6.3)
Description: displays meta-data from files of arbitrary type
Similar to the well-known "file" command, extract can display meta-data from a file and print the results to stdout.
Currently, libextractor supports the following formats: HTML, MAN, PS, DVI, OLE2 (DOC, XLS, PPT), OpenOffice (sxw), StarOffice (sdw), FLAC, MP3 (ID3v1 and
ID3v2), OGG, WAV, S3M (Scream Tracker 3), XM (eXtended Module), IT (Impulse Tracker), NSF(E) (NES music), SID (C64 music), EXIV2, JPEG, GIF, PNG, TIFF, DEB,
RPM, TAR(.GZ), LZH, LHA, RAR, ZIP, CAB, 7-ZIP, AR, MTREE, PAX, CPIO, ISO9660, SHAR, RAW, XAR FLV, REAL, RIFF (AVI), MPEG, QT and ASF.
Also, various additional MIME types are detected. It can also be used to compute hash functions (SHA-1, MD5, ripemd160).
Homepage: http://www.gnu.org/software/libextractor/
Tags: interface::commandline, role::program, scope::utility, use::scanning, works-with::file
Jeśli to jest to, to:
$ extract openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin
'openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin' cannot be extracted via >extract<
No i chodzi jeszcze o ten katalog rootfs w build_dir/ -- u mnie w build_dir/ chyba tego nie ma. Jedyne co to jest coś takiego:
$ find . -name "*rootfs*" -type d
./build_dir/target-mips_24kc_musl/collectd-5.10.0/contrib/docker/rootfs_prefix
./build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-4.14.171/include/config/mtd/rootfs
./build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-4.14.171/include/config/mtd/rootfs
./build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/collectd-5.10.0/contrib/docker/rootfs_prefix
Dołączony i podmieniony jeżeli o takiej nazwie w danym katalogu już był. To akurat mogłeś sprawdzić
No mogłem, ale już mi się nie chciało ponownie budować obrazu i podłączać tego testowego routera.
Co do tego wypakowania obrazu to chyba tym.
https://github.com/ReFirmLabs/binwalk
Zostały mi w sumie chyba ostatnie pytania już.
Chodzi o tę edycję plików w obrazie za sprawą katalogu files/ :
A następnie umieszczamy w nim pliki lub katalogi które mają znaleźć się w docelowym obrazie. Cała struktura katalogów zostanie przeniesiona w identyczny sposób, więc np. jeżeli chcemy podmienić plik /etc/banner w obrazie wynikowym na swój, to w katalogu files robimy podkatalog etc a w nim umieszczamy plik banner z własną zawartością:
Czy tak utworzony plik zostanie dołączony do tego w obrazie czy podmieniony?
To co ja chciałbym zrobić, to skonfigurować sobie parametry połączenia LTE i WiFi, które w zasadzie pozostają takie same. I pytanie jest jak się do tego zabrać? Skopiować gotowe pliki z /etc/config/ po skonfigurowaniu routera czy jakoś inaczej?
Da radę jakoś wypakować ten obraz, tak by podejrzeć jego zawartość i upewnić się, że wszystkie pliki są na swoim miejscu?
Widziałem, że wrzuciłeś paczkę na git'a i nasunęło mi się pytanie. Jak mam kilka różnych środowisk kompilacji utworzonych via ./scripts/env new to czy po aktualizowaniu feeds'ów trzeba się przełaczyć do każdego z tych środowisk i zaktualizować plik .config, czy istnieje może jakiś prostszy sposób by ten dodatkowy pakiet (lub inne zmiany) dodać dla wszystkich konfiguracji naraz?
@Cezary, w tym artykule o kompilacji openwrt piszesz tak:
Czasami (w bardzo rzadkich przypadkach) może przydać się zmiana opcji kompilacji kernela. Można to zrobić poleceniem (po uprzedniej kompilacji systemu!)
$ make kernel_menuconfig
zaznaczyć niezbędne opcje, zapisać a potem jeszcze raz skompilować cały system poleceniem make.
O co chodzi z tą uprzednią kompilacją? Pobrałem właśnie czyste źródła i wydałem to polecenie -- parę rzeczy skompilował, kilka innych dociągnął i po dłuższej chwili od wydania tego polecenia pojawiło się okienko z konfiguracja kernela.
BTW: zapomnieli dać odpowiednika w stylu make kernel_xconfig ?
A odnośnie tego skryptu od statystyk routerów. Nie wrzuciłbyś na swojego git również i luci-app-ekooneplstat ?
To jeszcze parę pytań.
Jak już ma się te osobne środowiska kompilacji dla każdego z targetów, to czy istnieje jakieś narzędzie, które te obrazy zbuduje w jednym podejściu czy trzeba sobie to ogarnąć skryptem we własnym zakresie?
Próbowałem zbudować obraz bezpośrednio z gałęzi master ale widać coś LuCI ma jakieś defekty (coś dodawanie interfejsów sieciowych z poziomu www nie działa jak należy) i wróciłem do v19.07.2. W tej gałęzi master jest nowszy kernel. Czy istnieje jakiś sposób by ten kernel przerzucić do tego starszego wydania? Chodzi generalnie o to by mieć starsze wydanie z nowszym kernelem.
No to są dwa różne targety (jeden dla archer c7v2, a drugi dla archer c2600).
Czyli w sumie to trzeba zrobić dwie osobne konfiguracje
$ ./scripts/env new archer_c7_v2
$ ./scripts/env new archer_c2600
Porobić zmiany w nich (przestawić targety) i zapsiać:
$ ./scripts/env diff
$ ./scripts/env save
A później przy budowaniu wystarczy zmienić config:
$ ./scripts/env switch archer_c7_v2
Switched to branch 'archer_c7_v2'
$ ./scripts/env switch archer_c2600
Switched to branch 'archer_c2600'
3. albo sobie dodaj pakiety z mojego githuba do feedsów albo w files umieść już gotowy plik
Jeśli dobrze rozumiem to, to mam skopiować plik openwrt/feeds.conf.default do openwrt/feeds.conf i w nim dopisać coś w poniższym stylu?
src-git obsy_packages https://github.com/obsy/packages.git
No i niby działa ale coś chyba nie do końca:
$ make package/symlinks
Updating feed 'packages' from 'https://git.openwrt.org/feed/packages.git^99efce0cd27adfcc53384fba93f37e5ee2e517de' ...
Create index file './feeds/packages.index'
Updating feed 'luci' from 'https://git.openwrt.org/project/luci.git^13dd17fca148965d38f0d4e578b19679a7c4daa2' ...
Create index file './feeds/luci.index'
Updating feed 'routing' from 'https://git.openwrt.org/feed/routing.git^efa6e5445adda9c6545f551808829ec927cbade8' ...
Create index file './feeds/routing.index'
Updating feed 'telephony' from 'https://git.openwrt.org/feed/telephony.git^6f95d6ab3f359ee2ce81c20522700937424d1591' ...
Create index file './feeds/telephony.index'
Updating feed 'obsy_packages' from 'https://github.com/obsy/packages.git' ...
Already up to date.
Create index file './feeds/obsy_packages.index'
/bin/sh: 1: 8: Bad file descriptor
Collecting package info: done
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-3ginfo/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-apcups/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-iradio/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-management/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-msg/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-smsbox/Makefile' has a dependency on 'gargoyle', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-smsbox/Makefile' has a dependency on 'gnokii', which does not exist
WARNING: Makefile 'package/feeds/obsy_packages/plugin-gargoyle-usbrelay/Makefile' has a dependency on 'gargoyle', which does not exist
Installing all packages from feed packages.
Installing all packages from feed luci.
Installing all packages from feed routing.
Installing all packages from feed telephony.
Installing all packages from feed obsy_packages.
Mam się martwić tymi ostrzeżeniami w logu?
I jeszcze takie pytanie. Jak mam parę routerów i chciałbym dla każdego z nich budować obraz, to czy jest jakiś bardziej cywilizowany sposób na ogarnięcie procesu budowania niż ciągła ręczna zmiana targetu?
No ale ja nie wiem co mam zobaczyć w tamtym wyjściu. Coś więcej niż tutaj (w make xconfig też można użyć szukajki )?
Nie widzę tam nic o make oldconfig/defconfig.
Ok, jak coś to dopisz info o tym tutaj, bo ciężko trochę to wywnioskować.
To też. Aczkolwiek czasami jak masz wybrane dużo pakietów a to zdarza się że coś w zależnościach nie wyłapie, buduje równolegle i coś się wywali bo coś jeszcze się nie skompilowało. Wtedy musisz raz jedyny uruchomić nie wielowątkowo żeby wszytko przetrawiło się w dobrej kolejności.
Ok, będę miał to na uwadze.
@ad2014 , coś to wyjście trochę nieczytelne.
BTW: nie lepiej używać make xconfig?
Mam jeszcze jedno pytanie. Jak się będzie robić aktualizację źródeł w późniejszym czasie, to trzeba pobrać nowe commit'y z git'a via:
$ git remote update && git status
$ git pull
Czy do tego trzeba coś jeszcze robić? Przykładowo, czy make package/symlinks trzeba jeszcze raz wykonać? Podobnie z make oldconfig lub make defconfig -- czy je też trzeba wpisywać po każdej aktualizacji źródeł?
1. akurat make package/symlinks woła dokładnie dwa w/w polecenia. To to samo.
Ok, właśnie wyłapałem to w pliku openwrt/include/toplevel.mk .
package/symlinks:
./scripts/feeds update -a
./scripts/feeds install -a
7. jak się wywaliło i robisz debug to robisz bez wielu wątków. Jak pakiety mają zrąbane zależności i nie chce się zbudować to robisz bez wielu wątków. W pozostałych przypadkach możesz budować wielowątkowo. To zależy co robisz a nie ze nie jest zalecane.
Generalnie to wyczytałem, że większość błędów przy make -j x można fix'nąć przez make download .
initramfs zwykle można wyłączyć w opcjach
Chodzi o TARGET_ROOTFS_INITRAMFS ?
Ok, to ta opcja.
eko.one.pl → Posty przez morfik
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc