VNISH Ninja · Academia
El minero arrancó: qué verificar antes de declarar exitosa la instalación
Una interfaz accesible solo prueba que parte del sistema arrancó. Verifica build, inventario, refrigeración, pool y trabajo aceptado antes de declarar éxito.
Método de trabajo
- Compara build leído con el objetivo previsto.
- Compara hashboards y chips con el inventario anterior.
- Revisa refrigeración, temperaturas, PSU y electricidad para la variante exacta.
- Confirma pool, worker y accepted work; separa métricas locales y de pool.
Analicemos una situación
Situación de aprendizaje, no un resultado comunicado por un cliente.
Imagina un primer arranque hipotético que muestra el logotipo esperado y un panel legible. La siguiente acción útil es comparar con el registro previo al cambio, no declarar el éxito de inmediato. Confirma que la compilación indicada sea la prevista para este dispositivo. Compara las placas detectadas con el inventario anterior y después revisa las observaciones de refrigeración y los errores nuevos.
A continuación, identifica el worker previsto y comprueba si su registro en el pool muestra trabajo aceptado durante el periodo de observación elegido. Si falta una placa, aunque el hashrate total siga pareciendo considerable, esa ausencia continúa sin resolverse; el total no puede anularla. A la inversa, una discrepancia breve entre dos paneles no constituye un diagnóstico hasta que se comprendan sus fuentes y periodos. Registra cada observación con su marca de tiempo, diferenciando «no comprobado» de «comprobado y correcto».
La decisión final puede ser GO, HOLD o STOP según las condiciones acordadas previamente para el lugar de operación. Ningún número universal de minutos sustituye estas evidencias. Una primera pantalla que funciona es el punto de partida para comprobar el estado real, no una garantía de minería estable.
Límites y condiciones de parada
- Bucle de reinicio, placa ausente, temperatura sin control, rechazo repetido o build incorrecto requieren STOP.
- Una pantalla verde no es una prueba extremo a extremo.
- No existe una ventana universal de estabilización.
Artefacto reutilizable
| # | Campo | Comprobado | Evidencia / nota |
|---|---|---|---|
| 1 | build planificado / observado | □ | |
| 2 | placas / chips antes y después | □ | |
| 3 | refrigeración / temperatura / PSU | □ | |
| 4 | pool / worker / accepted work | □ | |
| 5 | estado de Dev Fee visible en el dashboard | □ | |
| 6 | método de medición de potencia en pared | □ | |
| 7 | errores / ventana / GO-HOLD-STOP | □ |
Copia esta estructura al registro del cambio; nunca incluyas contraseñas, claves ni accesos privados.
Términos de esta guía
- Lectura del estado real
- Observación del estado real del dispositivo comparado con el resultado previsto.
- Discrepancia de inventario
- Diferencia entre los componentes esperados del dispositivo y los observados.
- HOLD
- Decisión de no avanzar mientras sigan sin resolverse evidencias obligatorias o una cuestión operativa.
Comprueba lo que has entendido
Estas preguntas comprueban la comprensión. No autorizan una instalación ni certifican un resultado.
¿Un hashrate total alto puede anular la observación de que falta una placa?
Mostrar respuesta
No. La discrepancia de inventario sigue sin resolverse.
¿«No comprobado» significa «correcto»?
Mostrar respuesta
No. Estos estados deben mantenerse separados en el registro.
¿Un tiempo de espera fijo puede establecer la estabilidad de todos los dispositivos?
Mostrar respuesta
No. El periodo de observación y las condiciones de aceptación dependen de la prueba concreta y del lugar de operación.
Fuentes primarias
- BITMAIN - generic online-upgrade precautions (updated 2026-03-03) Revisado 2026-09-10
- BITMAIN - Antminer S21 air-cooled specification Revisado 2026-09-10
- Bitcoin Developer Guide - Mining Revisado 2026-09-10
- Stratum V2 - Mining Protocol Revisado 2026-09-10