Leistungsaufnahme: ca. 6-12W (ohne Erweiterungskarten)
120 GB mSATA Platte (Transcend)
Im vergangenen Sommer wurde das APU1D durch das o. g. ersetzt um die Anlage leistungstechnisch aufzuwerten (Video, Screensharing, etc). Für Arbeitsgruppen mit bis zu 8 Teilnehmern (Mischbetrieb) läuft das System prima und hat noch Reserven.
Das Image wurde funktionell auf die SSD geschrieben. Das Servermanagement ist erreichbar. Die Anlage startet aber nicht. Auch beim Installation/Bootvorgang ist auf der Console nichts außergewöhnliches zu sehen.
Nach erneuter Aktivierung der Version 19.11 ist die Welt wieder in Ordnung. Halt ohne die lang erwartete Screensharing Funktion vom WebClient.
Es sieht so aus als hätte das Problem mit dem Wechsel auf Ubuntu 18.08 lts zu tun.
Weiteres Troubleshooting kann ich aktuell nicht vornehmen um das Produktivsystem am Laufen zu halten.
Hallo @hertfeu,
offiziell wird die Hardware ja nicht mehr unterstützt, siehe hier.
Da du allerdings nach dem Update bis ins Management UI kommst, dürfte das nicht grundsätzlich kaputt sein. Vielleicht kannst du ja mal eine VM mit 19.12 installieren und das Datenbank-Backup dort einspielen (Vorsicht vor eventueller Doppelregistrierung des SIP-Amtes). Ist die Migration dort auch kaputt?
In dem Fall kannst du mir zur genaueren Analyse gerne die Logs der Instanz aus /var/log/jobs und /var/log/pascom/migration senden.
sorry, ich hatte nie etwas zu tun mit dem Pascom SOHO Geräten. Die APU/APU2 boards habe ich ohne Bezug zu Pascom in Betrieb für Firewalls, NAS, Router, usw. Nachdem ich von Askozia gewechselt bin, habe ich diese Boards auch für die Mobidick/Pascom genutzt. Das war zu keiner Zeit ein Problem. Habe als die v. 19 eingesetzt wurde das vorhandene APU1 (single core) mit dem neuen APU2/ Quad-Core + 4GB RAM ersetzt. Für kleine Arbeitsgruppen absolut ausreichend + Reserve.
Es gibt ja viele unterschiedliche Alix/APU Boards. Welches im Pascom SOHO verbaut war (keine Ahnung). OK, das ist aber auch nicht das Problem.
Es handelt sich auch nicht um ein Migrationsproblem. Nachdem ich nach dem ersten Migrationsversuch gedacht habe, dass irgendwas schiefgelaufen ist, habe ich das Image nochmal installiert, mit dem gleichen Ergebnis. Habe dann die Pascom 19.12 from the scratch per UsB Stick neu installiert. Mit dem gleichen Ergebnis. Das Management UI ist erreichbar, die Anlage startet nicht (jungfräulich ohne config). Aus Zeitmangel und Erreichbarkeitsgründen habe ich die 20.11, die davor lief (ohne Probleme) per Stick neu installiert, das Backup rein und alles war wieder ok.
Bekomme am Wochenende meine Leihanlage von einem Kunden wieder zurück. Die ist mit der gleichen Hardwarekonfiguration ausgerüstet im 19" Gehäuse. Kann mir dann die Sache mal genauer ansehen.
Was ich aus den letzten Erfahrungen noch berichten kann, es gibt auch ohne Migration kein Jobs die hängenbleiben oder fehlschlagen. Die Instanz/Anlage wird nicht gestartet. Irgendwann dann der Hilferuf von der Routine nach dem Support.
zeigt es im Fehlerfall mit lxc-ls -f alle container als “running” an?
Kannst du in dem Fall mal in den Telefonanlagen-Instanz (mit lxc-attach $instanzname) wechseln und mit systemctl -f nachsehen, ob alle Dienste laufen? Ggf. liefer auch journalctl -f etwas auswertbares.
das Problem war relativ schnell entdeckt, mit der zweiten Anlage. Die Anlage startet nur am Management Interface “1”. Hatte unsere Anlage hier auf dem Interface “2” seit der V. 18. Das hat immer gepasst bis V. 19.12. Um das Problem zu lösen, muss bei Nutzung eines APU2 Boards unbedingt als Management Interface “Interface1” genutzt werden.
Leider ist aber nicht alles in Ordnung. Es gabt doch Probleme bei der Migration von 19.11 -> 19.12. Es stehlt folgender kritischer Fehler an:
CRITICAL: Migration of md-cmd failed at md_cmd_71911_02.php.
Kannst du mir da bitte einen Workaround nennen? Ansonsten ist nun alles weitere OK.
Das Migrationsproblem hat wohl mit dem Cisco SPA-112 etwas zu tun, da dieser nicht sauber migriert wurde. War als generic Sip Device nicht zu nutzen. Wollte diesen nun löschen, da ein Grandstream GW eingesetzt werden soll. Der Cisco lässt sich aber nicht mal löschen. Es wird folgende SQL Fehlermeldung ausgegeben:
SQL Fehler
DELETE FROM “010device” WHERE “010device”.“010dev_id”=?
array(1) {
[0]=>
string(2) “10”
}
ex_sqlException: 23503; 7; ERROR: update or delete on table “010device” violates foreign key constraint “fk_010dev_id3” on table “053gateway”
DETAIL: Key (010dev_id)=(10) is still referenced from table “053gateway”. in /var/www/mobydickcmd/cmn/class/sql/ex_simpleSql.php:249
Stack trace: #0 /var/www/mobydickcmd/cmn/class/sql/ex_simpleSql.php(524): ex_simpleSql->executeStatement() #1 /var/www/mobydickcmd/cmn/class/sql/ex_simpleSql.php(1020): ex_simpleSql->deleteSql() #2 /var/www/mobydickcmd/cmn/class/sql/ex_sqlDao.php(101): ex_simpleSql->deleteByPk() #3 /var/www/mobydickcmd/module/device/mod_device.php(643): ex_sqlDao->deleteByPk() #4 /var/www/mobydickcmd/cmn/class/module/ex_moduleCallInterceptor.php(174): mod_device->deleteDevice() #5 /var/www/mobydickcmd/module/device/controller/ctl040704.php(24): ex_moduleCallInterceptor->__call() #6 /var/www/mobydickcmd/cmn/class/mvc/controller/ex_deleteController.php(26): ctl040704->delete() #7 /var/www/mobydickcmd/cmn/class/mvc/controller/ex_multiIdController.php(75): ex_deleteController->handleRecord() #8 /var/www/mobydickcmd/cmn/class/mvc/ex_frontController.php(162): ex_multiIdController->handleRequest() #9 /var/www/mobydickcmd/cmn/class/mvc/ex_frontController.php(97): ex_frontController->handleRequestInternal() #10 /var/www/mobydickcmd/cmn/layout/box_trc.inc.php(38): ex_frontController->handleRequest() #11 /var/www/mobydickcmd/index.php(282): include_once(’/var/www/mobydi…’) #12 /var/www/mobydickcmd/index.php(45): outputBodyLoggedIn() #13 {main}
Ansonsten war die Migration erfolgreich. Wie kann man den Cisco Adapter löschen?
die Datenbank benutzt Fremdschlüssel für die Verbindung zwischen den Tabellen. Somit kannst Du manuell nichts löschen, was noch in Verwendung ist. Laut Logfile wird angemeckert das der Cisco noch in der Tabelle Gateway vorhanden ist. Schau mal im Commander, ob der Cisco noch unter den Gateways auftaucht und lösche Ihn dort. Alternativ könntest Du auch versuchen ihn aus der Tabelle 053gateway via SQL zu löschen. Es kann aber sein, das Du dort ebenfalls eine Fehlermeldung bekommst und erst in einer weiteren Tabelle Ihn löschen musst.
ja, das sehe ich genauso wie du. Durch die Migration wurde das GW gelöscht. Es sind nur noch die umgewandelten “generic Devices” unter den Geräten übriggeblieben. Löschen der Geräte wird mit der SQL Fehlermeldung quittiert. Auf dem herkömmlichen Weg, GWs und Devices über den Commander zu löschen, ist leider nichts zu machen. An der SQL DB will ich keine Hand anlegen.
Habe nun die V. 19.11 hochgefahren. Dort das Komplette GW + die Devices vor der Migration gelöscht. Ein Backup erstellt und dieses in der V. 19.12 eingespielt. Nun ist alles wie es sein soll.
Die Empfehlung hier ganz klar. Erst das alte Zeugs, dass nicht mehr unterstützt wird, rauslöschen und dann migrieren. Mit der Verwendung des ersten Interfaces als Management-Interface “ifenp1s0” klappts dann auch mit dem APU2 Board.