Nachdem meine zweite Horstbox endlich frei zum Experimentieren ist, hier die Erfahrungen mit den fertigen Images V0.1.0-r62 bzw mit Selbstkompiliertem / SVN-Stand vom 26.07.2009.
Falls das Nachfolgende zu negativ klingt: über die vielen funktionierenden Sachen schreibt man halt nicht
![Smile :) :)](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
.
Grüße, von Arny
1) Das Selbsterstellen der Images ist grausam. Bis zum ersten erfolgreichen Durchgang bleibt das Buildsystem immer wieder stehen, weil irgendwelche Software fehlt. Beim nächsten "make" wird wieder sehr sehr viel (uClib, Kernel etc etc) neu gebaut.
Folgende Pakete musste ich nachinstallieren (Debian-Testing-System):
flex, bison, zlib1g-dev, unzip, automake, libtool, libtiff4-dev (unsicher, ob wirklich gebraucht), libgtk2.0-dev, java-compiler, sox, libsox-fmt-all, mtd-utils, fakeroot
Ziemlich früh tauchte mal ein Fehler auf, weil beim Bauen von busybox ein Verzeichnis /tmp/ccache-2.4/ fehlte (offensichtlich für das
ccache-Programm). Manuelles Anlegen dieses Verzeichnisses löste das Problem. Bei späteren make-Aufrufen, als schon Einiges fertig war, wurde dieses Verzeichnis nicht mehr gebraucht.
2) Beim Laden irgendeines Kernelmoduls (war wohl ixp425_ledman.ko) gabs die Fehlermeldung, dass das Modul (2.6.30.1) nicht zum Kernel (2.6.30.2) passt. Mit den selbsterstellten Images trat dies nicht mehr auf.
3)
- ... das alte Frontend auf Port 443 (https)
bei mir gibts auf Port 443 keine Reaktion. Hat das was damit zu tun, dass ich eigene Firmware auf Herta habe? Ist aber nicht wirklich wichtig.
4) Einrichten/Experimentieren mit Asterisk-Konfigurationsdateien auf /etc/asterisk (=/mnt/asterisk): beim Laden des Asterisk-Moduls chan_lcr gibts diesen Fehler (sowohl mit dem von Euch verteilten bzImage und main-fs als auch mit Selbsterstellten):
Code:
Module 'chan_lcr.so' was not compiled with the same compile-time options as this version of Asterisk.
Module 'chan_lcr.so' will not be initialized as it may cause instability.
Module 'chan_lcr.so' could not be loaded.
5) Ließe sich das einrichten, dass der Asterisk auch chan_misdn.so baut? Das mISDNuser-Paket ist ja vorhanden. Ich hatte auf die Schnelle nicht rausgekriegt, wie man das Asterisk-Bauen dazu überredet. In build_env/asterisk-1.6.0.11-rc1/config.log steht:
Code:
configure:35797: checking for mISDN_open in -lmISDN
configure:35832: armeb-linux-gcc -o conftest -g -O2 conftest.c -lmISDN >&5
/media/sda8/HorstBox/horst/ippf/svn/trunk/build_env/toolchain/usr/bin/../lib/gcc/armeb-linux-uclibc/4.4.0/../../../../armeb-linux-uclibc/bin/ld: cannot find -lmISDN
6) Sehe ich das richtig (habs noch nicht soweit geschafft): Der NT-Modus sollte doch eigentlich funktionieren (zumindest ohne Telefon-Spannungsversorgung), weil das die mISDN-Treiber erledigen?!? Und funktioniert mittlererweile evtl. sogar die Spannungsversorgung?
7) Noch ein Vergleich mit OpenWrt auf Horst, mit dem ich früher Erfahrungen sammeln konnte:
- Das OpenWrt-Bauen erfordert ähnlich viel Geduld.
- OpenWrt überlagert für das Root-System ein Squashfs und ein Jffs2-System (wie UnionFS bei Knoppix, aber mit einem einfacheren Treiber "MiniFO"). Zur Laufzeit kann man also wild ändern, und die Änderungen sind persistent. Sehr bequem, um Dinge auszuprobieren.
- OpenWrt hat eine Paketverwaltung. Relativ viele Pakete sind von Haus aus unterstützt. Sehr bequem, um Dinge temporär oder dauerhaft nachzuinstallieren.
- OpenWrt unterstützt weniger Treiber für Horst als dieses Projekt hier.