Dieser wird wahrscheinlich funktionieren. Sie können dieses Image z. B. mit docker start b5f2a8a39709 starten.
(Sie möchten vielleicht auch einige dieser älteren Images bereinigen – es gibt potenziell eine große Menge an Speicherplatz, die wiederhergestellt werden kann!)
Fehlerantwort vom Daemon erhalten: Kein solcher Container: b5f2a8a39709
Danke. Außerdem kopieren meine Backup-Verfahren ALLE Dateien vom System. Es gibt wahrscheinlich aktuellere Images dort, wenn ich wüsste, wo ich suchen und wohin ich sie kopieren soll.
Ich entschuldige mich für die Unterbrechung des Workarounds, aber wir werden auf einen anderen Server migrieren, was eine eigene Herausforderung darstellte, da es sich um einen dedizierten Server handelte und wir den Vertrag erst im letzten Juni für ein ganzes Jahr erneuert haben.
Vielleicht wäre es schön, wenn das Discourse-Team eine Warnung für Leute herausgibt, die es auf nicht mehr unterstützten Servern betreiben. Es auf die Art und Weise herauszufinden, wie wir es getan haben, ist SEHR unangenehm. (Drei Benutzer mit demselben Problem, wir sprechen über Server, diese werden nicht so schnell erneuert wie Laptops.)
Ich möchte klarstellen, dass dies keine absichtliche Änderung war.
Wir haben auch keinen direkten Zugriff auf so alte Hardware und sind auf die Hilfe der Community angewiesen, um herauszufinden, was genau schiefgeht.
Sobald wir sicher wissen, dass es sich um ein Kompilierungsproblem mit dem Gem selbst handelt, können wir Maßnahmen ergreifen.
@here
Das Hinzufügen eines Top-Level-Schlüssels in der Datei app.yml mit
base_image: discourse/base:2.0.20220621-0049-slim
sollte das Problem umgehen, wird aber die Neuerstellung ein wenig verlangsamen.
Das ist fair, aber solche Server werden immer noch von Anbietern auf der ganzen Welt als Low-Entry-Server angeboten.
Für viele kleinere Open-Source-Projekte sind solche Server ideal, preislich gesehen, und oft können sie sich keinen Intel Xeon oder AMD Ryzen mit 32 GB RAM leisten.
Ich verstehe vollkommen, dass Sie nicht die Hardware zum Testen der Software haben, aber aus der Kommunikation in diesem Thread wurde dies von uns festgestellt und dann gab es überhaupt keine Reaktion mehr.
Ein einfaches „Tut mir leid, wir werden uns das ansehen“ wäre in diesem Fall ausreichend gewesen, stattdessen lassen Sie uns im Ungewissen.
Teste jetzt mit dieser Änderung.
Der Build scheint auf die gleiche Weise fehzuschlagen.
Dies geschah mit der Änderung an containers/app.yml, wobei hinzugefügt wurde:
base_image: discourse/base:2.0.20220621-0049-slim
nahe dem Anfang.
Das bedeutet, dass das Problem nicht darin besteht, dass wir eine vorkompilierte Version des Gems ausliefern, sondern dass das Upstream-Gem auf diesen alten CPUs nicht kompiliert werden kann.
Wir haben issue #789 gegen das oj-Gem eröffnet.
Verstanden. Ich möchte eines meiner kürzlichen Docker-Images wiederherstellen – aus meinen rsync-Backups. Gibt es eine Prozedur, auf die Sie mich verweisen können, um diese zu finden und eines wiederherzustellen/zu starten? Danke!
Haben Sie versucht, ./launcher start app auszuführen?
Wenn dieser nicht funktioniert, versuchen Sie die andere Methode, die ich für den Wiederaufbau vom letzten funktionierenden Commit beschrieben habe.
Ja. Das bringt den Webserver zum Laufen, aber man kann nicht auf Threads zugreifen, sie drehen sich nur.
Das wird nicht helfen.
Das Problem ist, dass das aktualisierte Gem nicht prüft, ob die Anweisung von der CPU unterstützt wird, bevor es sie verwendet.
Es wird helfen, die Discourse-Instanz wieder zum Laufen zu bringen, da die vorherige/funktionierende Gem-Version installiert wird (wie ich Bryans Instanz wieder zum Laufen gebracht habe), aber ja – jedes weitere Update (über admin/upgrade) wird das gleiche Problem erneut auslösen.
Ich habe noch keinen Erfolg mit einem neuen Build oder dem Laufenlassen der vorherigen Instanz, daher werde ich dies angesichts des bevorstehenden Wochenendes vielleicht bis nächste Woche aufschieben, in der Hoffnung, dass die Situation von der Gem-Seite aus behoben werden kann …
Welches Verfahren war das? Ich bin zugegebenermaßen jetzt etwas verwirrt, als ich versuche, die verschiedenen Ideen in diesem Thread zu verfolgen. Danke!
Der zweite Teil dieses Beitrags:
Ich werde das versuchen. Danke.
Eine weitere mögliche Problemumgehung ist das Hinzufügen des Folgenden zu app.yml
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
Ich gehe davon aus, dass Updates danach immer noch unsicher wären, richtig? Ich erstelle gerade den Build auf dem älteren Commit.