Neutrino-Images

Moin,

ich wollte mal meine Neo2 auf aktuellen Stand bringen und habe ein Online Softwareupdate (28.07.2023) gemacht.
Nach dem reboot kam dann "boot Kernel", dann das CST Logo und dann Update Kernel. das machte sie dann in einer Dauerschleife.

Daraufhin habe ich das USB Notflash Programm nach coolstream-hd1-f47/hd1-recovery-von-ker ... t1923.html
durchgeführt genau das gleiche wieder. Habe dann auch das Image von gestern genommen, wieder die Kernel update Bootschleife.
Bin dann weiter zurück auf das Image vom 15.07.2023 10.07 und 5.07 auch das gleiche.

Das Image vom 03.07.2023 läuft dagegen. (einmal Kernelupdate und die Kiste fährt hoch.

Irgendwas muss da beim Image bauen "kaputt" gegangen sein.

.. ich kenne dies Probleme schon länger, deswegen flashe ich nur noch alte Versionen, das reicht zu TV klotzen.
Leider sind die aktuellen Images, speziell für die HD1 Serie, sehr oft völlig unbrauchbar und die Boxen booten dann nicht mehr. Echt mühsam dann wieder mit den Wiederherstellungs-Tools zu werkeln.
Hatte das Problem gestern 2x beim versuch eine Zee HD1 ohne Netzschalter auf Stand zu bringen, kein Erfolg, bin dann bei der 3.4 geblieben, reicht für TV schauen.

Verstehen kann ich das nicht wirklich, früher hat es ja auch funktioniert, und wenn man Platz braucht, dann sollte man den unnötigen Schrott weglassen und sich auf das wesentliche konzentrieren.
Mir kommt es so vor als wenn hier die alten CST-User gar nicht erwünscht wären.

Am besten vanhofen nimmt die nevis Images nach dem 3.07.2023 alle raus.
Dann gibts auch keine solchen Unfälle mehr.
Mit meiner neo2 geht das Flashen per USB ja noch recht einfach, aber die von meinen Brüdern muss ich dann an den PC hängen da das flashen per USB bei den wegen dem älteren Booloader nicht funktioniert.

stefanx hat geschrieben: ↑Sa 29. Jul 2023, 08:56 Mir kommt es so vor als wenn hier die alten CST-User gar nicht erwünscht wären.

kann ich mir nicht vorstellen .. laut umfrage
viewtopic.php?f=4&t=6734&p=36935
halten die cst user 44% zusammen .. das sollte gewicht haben
vllt. könnt ihr das mal ein bisschen eingrenzen .. in puncto abstriche
damit im image bzw. der box nicht der speicher ausgeht.

Die Box ist allerdings für fiele Sachen schon vollkommen überfordert. Die Mediathek funktioniert größtenteils auch nicht mehr da die ÖR auf 1080p/50 umgestellt haben und das von der CPU nicht unterstützt wird. Nur die Auflösung runter nehmen bringt dort aber auch nichts.

Ich habe immer die satellites.xml auf Null gesetzt ebenso terrestrial.xml und samba. Die Dateien habe ich in der tobackup.conf eingetragen so das beim widerherstellen die Dateien keinen Platz mehr benötigen.

Aber ob das in diesem Fall zu der Kernel update Schleife kommt kann ich nicht sagen.

Auch wenn ich die Boxen nicht habe, aber Du solltest da eher mal ein Log machen. Das Kernel selbst hat erstmal nichts mit dem System selbst zu tun, somit auch nicht mit den xml etc., das kennt das Kernel alles nicht. Nach dem Kernel kommt eine "init" in welcher Form auch immer, also das Grundsystem wird dann gestartet. Aber auch das kennt die xml nicht wirklich, die kennt nur Neutrino.

Hi,
ich bin grad dran mit dem Log:

Code: Alles auswählen

...
Freeing init memory: 104K
INIT: version  booting
Jan 01 01:00:11 (none) user.info rcS[42]: start
Jan 01 01:00:11 (none) user.info rcS[42]: creating and mounting system directories ...
Sun Jan  1 00:00:00 CET 2023
rootdir=/dev
table=<stdin>
/etc/init.d/hostname: line 10: can't create /etc/hostname: No space left on device
hostname: can't open '/etc/hostname': No such file or directory
Jan  1 00:00:00 (none) syslog.info syslogd started: BusyBox v1.36.1
Jan  1 00:00:00 (none) user.info service[98]: running /etc/init.d/sysctl start 
* Applying /etc/sysctl.conf ...
Jan  1 00:00:00 (none) user.info rcS[42]: init frontpanel ...
Jan  1 00:00:00 (none) user.info rcS[42]: Loading cs_frontpanel.ko 
Jan 01 00:00:03 (none) user.info stb_update.sh[109]: Updating kernel on device mtd2 ...
Erasing 128 Kibyte @ 0 --  0 % complete Erasing 128 Kibyte @ 20000 --  3 % complete Erasing 128 Kibyte @ 40000 --  6 % complete Erasing 128 Kibyte @ 60000 --  9 % complete Erasing 128 Kibyte @ 80000 -- 12 % complete Erasing 128 Kibyte @ a0000 -- 15 % complete Erasing 128 Kibyte @ c0000 -- 18 % complete Erasing 128 Kibyte @ e0000 -- 21 % complete Erasing 128 Kibyte @ 100000 -- 25 % complete Erasing 128 Kibyte @ 120000 -- 28 % complete Erasing 128 Kibyte @ 140000 -- 31 % complete Erasing 128 Kibyte @ 160000 -- 34 % complete Erasing 128 Kibyte @ 180000 -- 37 % complete Erasing 128 Kibyte @ 1a0000 -- 40 % complete Erasing 128 Kibyte @ 1c0000 -- 43 % complete Erasing 128 Kibyte @ 1e0000 -- 46 % complete Erasing 128 Kibyte @ 200000 -- 50 % complete Erasing 128 Kibyte @ 220000 -- 53 % complete Erasing 128 Kibyte @ 240000 -- 56 % complete Erasing 128 Kibyte @ 260000 -- 59 % complete Erasing 128 Kibyte @ 280000 -- 62 % complete Erasing 128 Kibyte @ 2a0000 -- 65 % complete Erasing 128 Kibyte @ 2c0000 -- 68 % complete Erasing 128 Kibyte @ 2e0000 -- 71 % complete Erasing 128 Kibyte @ 300000 -- 75 % complete Erasing 128 Kibyte @ 320000 -- 78 % complete Erasing 128 Kibyte @ 340000 -- 81 % complete Erasing 128 Kibyte @ 360000 -- 84 % complete Erasing 128 Kibyte @ 380000 -- 87 % complete Erasing 128 Kibyte @ 3a0000 -- 90 % complete Erasing 128 Kibyte @ 3c0000 -- 93 % complete Erasing 128 Kibyte @ 3e0000 -- 96 % complete Erasing 128 Kibyte @ 3e0000 -- 100 % complete 
Jan 01 00:00:32 (none) user.info stb_update.sh[109]: Kernel update on device mtd2 successful.
rm: can't remove '/var/update/zImage': No space left on device
Jan 01 00:00:34 (none) user.info stb_update.sh[109]: Reboot ...
Restarting system.
[2h[61"p[m[44m[37m[1m[2J[1;1H[(B[)B[?3l[?9h╔══════════════════════════════════════════════════════════════════════════════╗
║ U-Boot 2009.03-svn1773 (Nov 02 2010 - 15:25:47)     Coolstream HDx           ║
╠══════════════════════════════════════════════════════════════════════════════╣
...

Das Skript kann den Kernel nicht aus dem Filesystem löschen, deshalb wird der Kernel wieder und wieder geflasht.

Ciao,
DdD.

edit: also das Image vom 4.7. geht auch noch, das vom 5.7. hat den Fehler!

Sieht aus, als wenn /var entweder gesprengt worden ist, nicht genug Platz hat oder gar r/o ist. Passen die Daten denn nicht in /tmp bei der Box? Normalerweise nutzt man ja für Updates auch /tmp und nicht /var.

Hi,

BPanther hat geschrieben: ↑Sa 29. Jul 2023, 13:17 Sieht aus, als wenn /var entweder gesprengt worden ist, nicht genug Platz hat oder gar r/o ist.

so sieht es wohl aus.

Da vanhofen gerade im wohlverdienten Urlaub ist, kann es ein wenig dauern, bis das gefixt ist.

Ciao,
DdD.

ich habe zwar keine cst box .. aber

rm: can't remove '/var/update/zImage': No space left on device

auf deutsch ..

rm: kann '/var/update/zimage nicht entfernen': kein platz auf dem gerät übrig

viele wege führen nach rom .. ich sehe es geht voran .. ungenannter

Hi,

stefanx hat geschrieben: ↑Sa 29. Jul 2023, 08:56 Verstehen kann ich das nicht wirklich, früher hat es ja auch funktioniert, und wenn man Platz braucht, dann sollte man den unnötigen Schrott weglassen und sich auf das wesentliche konzentrieren.
Mir kommt es so vor als wenn hier die alten CST-User gar nicht erwünscht wären.

nur um das mal ein wenig klarzustellen:
wenn die alten Nevis hier nicht mehr erwünscht wären, hätten wir die schon längst auf einen gewissen Stand eingefroren, was aber bedeuten würde, dass es zB :
a) keine neuen Images mehr für Nevis geben würde, oder aber

b) man ein seperates Repo für Nevis anlegt, was aber bedeutet, dass man jedwede Änderung an dem "normalen" Neutrino (für HD2 und Armboxen) extra rückportieren und dann auch testen müsste!
Das verdoppelt mal eben den Aufwand, dafür haben wir im Team, also insbesondere vanhofen (aka die "One-Man-Show"), nicht die Manpower.
Falls sich jemand mit entspr Kenntnissen darum kümmern möchte -> plz PM

.

c) Nichtsdestoweniger werden für die HD1 (und selbst für die HD2!) immer mehr Ausnahmen für neuere Softwareversionen nötig (zB das hier), damit die Images überhaupt noch laufen. Das liegt leider an den Closed-Source-Treibern der Hersteller oder uralten Kernelversionen, dammit.

Dazu kommt noch: hier im Team haben die meisten mind ne HD2 als normale "Produktivbox". Ich zB schaue täglich mit meiner Tank TV, die update ich zwar sporadisch, aber halt nicht täglich.
Meine Armboxen starte ich eher selten, halt wenn es was zu testen gibt. Auch wir gehen mit der Zeit.

Aber es gibt im Buildsystem für die Nevisboxen eine Prüfung, ob das Image noch "flashbar" ist.

Meine Vermutung zZt ist, dass die Prüfung da ein paar Bytes daneben liegt (man beweise mir das Gegenteil, lol). Seht euch die Commits im BS für den 4.7. an, und wer sich ein wenig damit auskennt, würde sich wundern, warum das auf einmal ein Problem darstellt.
Ich hab zB heute auch die beiden Images vom 4.7. und vom 5.7. mittels newtuxflashtools von den Dateigrössen verglichen, ich hab aber nicht wirklich was gefunden, was auffällig wäre. Ein paar KB hier oder dort, aber nix grosses.

Zusammengefasst: die Nevis sind nicht tot, aber es wird immer schwieriger, sie am Leben zu erhalten.

Und die Anzahl der User, die die noch nutzen und/oder sie regelmässig flashen, nimmt ab. Dass dieser Fehler erst heute nach ganzen drei Wochen aufgefallen ist, spricht doch echt Bände.
Dies ist kein Vorwurf, nur eine Feststellung.
Und das kein Log gepostet wurde, naja, also ihr seid doch echt User, die das können müssten. Aber ich hab eine meiner Nevis mal gerne wieder extra angeschlossen und geflasht. Der Kernel dürfte inzw so dermassen oft geflasht worden sein...

Bitte nicht falsch verstehen, ich hab nur mal Luft abgelassen.

Ciao,
DdD.

Es sind rund 350kb mehr was im Image nach dem 03.07.2023 ist, und der Grund dafür ist libjpeg-turbo 3.0.0, sieht man auch wenn man sich die verschiedenen xxx-cst-nevis-rootfs.tgz ansieht.

Don de Deckelwech hat geschrieben: ↑Sa 29. Jul 2023, 22:38Zusammengefasst: die Nevis sind nicht tot, aber es wird immer schwieriger, sie am Leben zu erhalten.

Und die Anzahl der User, die die noch nutzen und/oder sie regelmässig flashen, nimmt ab. Dass dieser Fehler erst heute nach ganzen drei Wochen aufgefallen ist, spricht doch echt Bände.
Dies ist kein Vorwurf, nur eine Feststellung.

Im Grunde ist es bei SH4 ähnlich die ich noch baue. Da liegt zwar der Source komplett vor und man könnte theoretisch vielleicht auch höhere Kernelversionen verwenden, nur da kommts auch auf die Größe an. Ja, es gibt Situationen wo das wichtig ist

, denn in eine UFS910 oder UFS922 muß Neutrino in 16 MB Flash passen.

Don de Deckelwech hat geschrieben: ↑Sa 29. Jul 2023, 22:38Und das kein Log gepostet wurde, naja, also ihr seid doch echt User, die das können müssten.

Das ist es auch etwas, was mich ärgert. Oft kommt nur "geht nicht" oder ähnliches. Ist es denn wirklich so schwer mal klare Aussagen zu machen, was genau nach was gemacht passiert oder nicht mehr, welche Anzeigen auf der Box kommen (wenn Display vorhanden) und ein anständiges Log mit dazu zu liefern?

Ich baue derzeit bei mir Images für 28 Boxen. Wird da wirklich erwartet, daß man die nach dem bauen auch alle testet? Die Zeit hat doch keiner - das sollte auch jedem klar sein. In der Regel teste ich 2-3 Boxen die hier dauerhaft in Betrieb sind. Und wenn doch mal was schief geht, dann braucht es eben ordentliche Fehlermeldungen. Hatte ich z.B. mal bei einer SH4 Box. Da hat der User darauf hingewiesen, daß die Box nicht startet und die Imagegröße nicht mehr zu passen scheint. Habe ich mir angeschaut und er hatte recht. Der Fehler konnte somit schnell behoben werden.

Hi,

BPanther hat geschrieben: ↑Sa 29. Jul 2023, 23:41 Ich baue derzeit bei mir Images für 28 Boxen.

und das bewundere ich echt an dir! Das kann man garnicht hoch genug einschätzen.

Ciao,
DdD.

Don de Deckelwech hat geschrieben: ↑Sa 29. Jul 2023, 23:49
BPanther hat geschrieben: ↑Sa 29. Jul 2023, 23:41Ich baue derzeit bei mir Images für 28 Boxen.
und das bewundere ich echt an dir! Das kann man garnicht hoch genug einschätzen.

Danke.

Wird hier via Scripte auf einem Laptop gemacht, bauen und dann hochladen. Da darf dann in den rund 7h 30m nichts schief gehen, sonst muß ich das nochmal machen - oder zumindest da weitermachen wo es schief lief.
NI baut glaube ich direkt auf dem Server - und da werden sicherlich auch Scripte dazu eingesetzt. Da spart man sich das extra hochladen.

Glaube OATV oder HDMU bauen sogar noch mehr als ich - und auch andere Boxen. Wer da solche Mengen baut, der kann auch nicht alles danach testen - schon weil man auch nicht unbedingt alle Boxen hat. Da sind nunmal die User selbst gefragt.

Don de Deckelwech hat geschrieben: ↑Sa 29. Jul 2023, 22:38
Und das kein Log gepostet wurde, naja, also ihr seid doch echt User, die das können müssten. Aber ich hab eine meiner Nevis mal gerne wieder extra angeschlossen und geflasht. Der Kernel dürfte inzw so dermassen oft geflasht worden sein...

Hätte ich gern gemacht aber mein Tablet mit dem ich das immer gemacht habe kackt mir ständig ab. Da scheint der Akku hinüber zu sein.
Um das am PC machen zu können müsste ich das Kabel wieder umlöten was ich derzeit aus gesundheitlichen Gründen nicht kann.

max_10 hat geschrieben: ↑Sa 29. Jul 2023, 23:36 Es sind rund 350kb mehr was im Image nach dem 03.07.2023 ist, und der Grund dafür ist libjpeg-turbo 3.0.0, sieht man auch wenn man sich die verschiedenen xxx-cst-nevis-rootfs.tgz ansieht.

Das ist mir jetzt auch aufgefallen die img Dateien sind 256kb größer.
Wenn man folgende Dateien/Plugins dort entfernt:
Neutrino Mediathek
terrestrial.xml
corona Plugin
zdfhbbtv plugin

Würde das Image schon wieder rein passen. Das zdfhbbtv Plugin läuft eh nicht auf den HD1 Boxen. und die terestrial.xml macht auf den Boxen nur wenig Sinn. (Da die keine Tuner dafür haben)

Hallo, dann ist es ja gut wenn man doch noch HD1 CST Boxen betreiben darf bzw. dafür wichtige Anpassungen bekommt.

Es ist eben die Herangehensweise offenbar längst überholt.
Ich wäre für das Einfrieren funktionierender Letztversionen und nur zwingende bzw. Änderungen zu machen.

Wie bereits von anderen Mitgliedern erwähnt, gibt es doch Einiges was in so einem HD1-Image fehl am Platz ist oder keiner mehr braucht.
Wer bitte schaut heute eine Mediathek an einer HD1, oder verwendet die als Mediaplayer?
Ich finde sämtliche Funktionen die ein Standard-TV seit Jahren ohnehin besser kann könnte man weglassen.

Ich und meine Freunde verwende diese Boxen als SAT-Receiver zum SAT-TV schauen.
Bei der Aufnahme Funktion ist die Möglichkeit über NFS einen Speicher zu teilen sehr gut und wird auch in der Praxis verwendet.
Wichtig das Serververbindungen weiter laufen und so gut bedienbar sind.

stefanx hat geschrieben: ↑So 30. Jul 2023, 09:29

Wie bereits von anderen Mitgliedern erwähnt, gibt es doch Einiges was in so einem HD1-Image fehl am Platz ist oder keiner mehr braucht.
Wer bitte schaut heute eine Mediathek an einer HD1, oder verwendet die als Mediaplayer?
Ich finde sämtliche Funktionen die ein Standard-TV seit Jahren ohnehin besser kann könnte man weglassen.

Leider ist dem eben nicht so. Mein Bruder sein TV hat nichtmal einen entsprechenden Tuner und einen Netzwerkanschluss schon garnicht.

Bei meinem TV wurden die Apps für die Mediatheken schon vor Jahren deaktiviert. Ich nutze die Mediathek (allerdings mit einer Axas) täglich. Ich musste mich auch von den VU+ Receivern verabschieden da die Mediathek dort zum Teil ziemliche Probleme macht. (aber auch andere Dinge wie TS).
Aber auf der Neo kann man die Mediathek nur noch mit ganz wenigen Beiträgen nutzen, von daher kann die dort auch entfernt werden.
Es gibt noch weitere Dateien die man nicht zwingend braucht. Dazu müsste das NI dann allerdings ein Downlodplugin zum Nachinstallieren standardmäßig haben. (Ich nutze da och immer das Plugin von Ezak
https://github.com/Ezak91/CST-Downloadcenter-Plugin.git

libturbojpeg anders bauen, spart schon einmal 456,8 KB durch Wegfall von libturbojpeg.so im Image.
bauen der Nevis mit alter libturbojpeg version und Änderung beim bauen spart da insgesamt auch 300kb, gegen vorher

Also genug Möglichkeiten damit wieder Platz im Image ist.

Hat das irgendwelche Nachteile?

Neutrino-Images

Kernel update Bootschleife nach Update

Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update

Re: Kernel update Bootschleife nach Update