El servidor Nexenta/OpenSolaris se reinicia sin cesar después de actualizar NCP 2.0rc2 a NCP 3.0a4

El servidor Nexenta/OpenSolaris se reinicia sin cesar después de actualizar NCP 2.0rc2 a NCP 3.0a4

Tengo una máquina NexentaCore Platform 2.0rc2 (OpenSolaris b104) en funcionamiento, que estoy intentando actualizar usando apt-clone upgrade--- NCP 3.0a4 (OpenSolaris b124).

El proceso de actualización parece completarse exitosamente, sin embargo, la máquina se reinicia inmediatamente después de que selecciono el nuevo punto de control en el menú de GRUB.

Cuando inicio el nuevo punto de control con "-v", veo los siguientes mensajes justo antes de que la pantalla se apague para reiniciar:

 WARNING: failed to resolve 'scsa,probe' driver alias, defaulting to 'nulldriver'
 WARNING: failed to resolve 'scsa,nodev' driver alias, defaulting to 'nulldriver'

No estoy seguro si esto está relacionado.

¿Alguna sugerencia sobre cómo puedo solucionar este problema?

Respuesta1

Es posible que desee agregar la opción -k a la entrada del menú de grub para que el sistema operativo vuelva a mdb en caso de pánico. Algo como:

.../unix -k -B $ZFS-BOOTFS,console=text -m verbose

Respuesta2

Tengo el mismo problema. Una captura de pantalla muestra además:

ADVERTENCIA: no se pudo resolver el alias del controlador 'scsa,probe', por defecto es 'nulldriver' ADVERTENCIA: no se pudo resolver el alias del controlador 'scsa,nodev', por defecto es 'nulldriver'

/kernel/fs/amd64/zfs: símbolo no definido 'lbolt' /kernel/fs/amd64/zfs: símbolo no definido 'lbolt64' ADVERTENCIA: mod_load: no se puede cargar el módulo 'zfs'

pánico[cpu0]/thread=ffffffffffbc2e7a0: No se puede iniciar el módulo zfs

He investigado un poco y descubrí que /kernel/misc/amd64/scsi y /kernel/misc/scsi actualizados difieren del original, al menos en que tienen 'scsa,probe' y 'scsa,nodev'. cuerdas en ellos. Aunque no estoy seguro de dónde vienen esas cuerdas. Copiar esos archivos de un bien conocido simplemente generó un montón de errores nuevos.

Respuesta3

Si están ejecutando procesadores AMD, entonces puede ser una situación en la que el nuevo kernel (como lo ha identificado Paul Archer) se esté volviendo muy exigente con las líneas AMD más antiguas. Me encontré con esto en el que los AMD más antiguos provocarían desde reinicios aleatorios hasta arranques fallidos o fallidos.

información relacionada