Es probable que este funcione. Puedes iniciar esa imagen con, por ejemplo, docker start b5f2a8a39709.
(También podrías querer eliminar algunas de esas imágenes antiguas; ¡hay una gran cantidad de espacio en disco que se puede recuperar!)
2 Me gusta
Obteniendo: Respuesta de error del demonio: No existe tal contenedor: b5f2a8a39709
Gracias. Además, mis procedimientos de copia de seguridad copian TODOS los archivos del sistema. Es probable que haya imágenes más recientes allí si supiera dónde buscar y dónde copiarlas.
Mis disculpas por interrumpir la solución alternativa, pero vamos a migrar a otro servidor, lo cual fue un desafío en sí mismo porque era un servidor dedicado y acabamos de renovar el contrato por un año completo el pasado junio.
Quizás sería bueno que el equipo de Discourse emitiera una advertencia para las personas que lo ejecutan en servidores que ya no son compatibles. Descubrirlo de la manera en que lo hicimos es MUY desagradable. (tres usuarios con el mismo problema, estamos hablando de servidores, no se renuevan a la misma velocidad que las laptops).
1 me gusta
Quiero que quede claro que esto no fue un cambio intencional.
Tampoco tenemos acceso directo a hardware tan antiguo y necesitamos recurrir a la ayuda de la comunidad aquí para determinar qué es exactamente lo que está saliendo mal.
Una vez que sepamos con certeza que se trata de un problema de compilación con la gema en sí, podremos tomar medidas.
3 Me gusta
@here
Agregar una clave de nivel superior en el archivo app.yml con
base_image: discourse/base:2.0.20220621-0049-slim
Debería solucionar el problema, aunque ralentizará un poco las reconstrucciones.
3 Me gusta
Es justo, pero los proveedores de todo el mundo todavía ofrecen este tipo de servidores como servidores de baja entrada.
Para muchos proyectos pequeños de código abierto, estos servidores son ideales, en cuanto a precio, y a menudo no pueden permitirse un Intel Xeon o AMD Ryzen con 32 GB de RAM.
Entiendo perfectamente que no tengas el hardware para probar el software, pero por la comunicación en este hilo, lo establecimos nosotros y luego no hubo ninguna reacción.
Un simple “lo siento, vamos a investigar esto” sería suficiente en este caso, en lugar de dejarnos colgados.
1 me gusta
Probando ahora con este cambio.
La compilación parece fallar de la misma manera.
Esto fue con el cambio a containers/app.yml, agregando:
base_image: discourse/base:2.0.20220621-0049-slim
cerca de la parte superior.
1 me gusta
Eso significa que el problema no es que enviemos una versión precompilada de la gema, sino que la gema upstream no puede compilarse en esas CPU antiguas.
Hemos abierto el issue #789 contra la gema oj.
2 Me gusta
Entendido. Me gustaría restaurar una de mis imágenes recientes de Docker, a partir de mis copias de seguridad de rsync. ¿Hay algún procedimiento que pueda seguir para localizarlas y restaurar/iniciar una? ¡Gracias!
¿Has probado a ejecutar ./launcher start app?
1 me gusta
Si este no funciona, prueba el otro método que detallé para reconstruir desde el último commit que funcionó.
3 Me gusta
Sí. Eso pone en marcha el servidor web, pero en realidad no puedes acceder a ningún hilo, simplemente giran.
Esto no ayudará.
El problema es que la gema actualizada no comprueba si la instrucción es compatible con la CPU antes de usarla.
Ayudará a que la instancia de Discourse vuelva a estar en funcionamiento, ya que instala la versión anterior/funcional de la gema (demostrado por lo que hice para que la instancia de Bryan volviera a funcionar), pero sí, cualquier actualización adicional (a través de admin/upgrade) activará el mismo problema de nuevo.
1 me gusta
Aún no tengo suerte con una nueva compilación ni con la ejecución de la instancia anterior, así que como se acerca el fin de semana, puede que espere hasta la próxima semana con la esperanza de que la situación se pueda solucionar desde el lado de la gema…
¿Qué procedimiento fue este? Confieso que estoy un poco confundido ahora intentando seguir las diversas ideas en este hilo. ¡Gracias!
La segunda parte de esta publicación:
1 me gusta
Lo intentaré. Gracias.
Otra posible solución alternativa es añadir lo siguiente a app.yml
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
3 Me gusta
Asumo que las actualizaciones seguirían siendo inseguras después de esto, ¿correcto? Estoy haciendo la compilación en el commit anterior actualmente.