Cómo descubrir la salida de menu de GRUB2

Acabo de actualizar una máquina remota que ejecuta Ubuntu Server 12.04. Solo tengo acceso a través de SSH y ahora está pidiendo un reinicio. Supongo que se instaló un kernel nuevo. Necesito hacer que arranque en un núcleo muy específico, de lo contrario, simplemente se bloqueará. ¿Hay alguna manera de verificar (desde la command-line, ya que me estoy conectando a través de SSH) qué GRUB2 va a hacer en el próximo reinicio?

Necesito principalmente asegurarme de que:

  1. La máquina se iniciará en el núcleo derecho (que ahora puede haberse movido al submenu " Previous Linux Versions ")
  2. El menu de GRUB2 va a "obedecer" mi request de time de espera (en algunas ocasiones encontré máquinas que simplemente se atascarían con el menu de arranque GRUB2, a pesar de tener un parámetro GRUB_TIMEOUT especificado en /etc/default/grub )

Entonces, ¿hay alguna manera de "simular" o diagnosticar lo que GRUB2 va a hacer en el próximo reinicio? Una forma de comprobar cosas como " Va a arrancar kernel yaddayaddayadda y tiene un time de espera activado de yadda segundos "

Sé que es una posibilidad remota, pero tal vez hay algo así como una herramienta de diagnóstico (que tendrá que ser la command-line … Ni siquiera tengo X-Windows en la computadora a la que me estoy conectando)

¡Gracias de antemano!

    La única forma de SIMULAR realmente que sé es pasar el disco a una máquina virtual.

    Hago esto mucho con mi memory USB GRUB2, que tiene kernels para mi escritorio y netbook más una docena de Linux Live CDs así como inputs de arranque memtest, DOS, Windows, …

    Cuando cambio algo en la configuration allí (como agregar otro Live CD ISO), puedo probar si arranca iniciando el dispositivo USB en una session KVM.

    Desafortunadamente, esta solución será mortal para usted, si el sistema realmente arranca y luego escribe en el disco. Los filesystems van al ka-boom porque todavía están en uso por el host, y luego los invitados comienzan a repararlos y usarlos también …

    Entonces, para usar esto de manera segura, debe asegurarse de que su VM lo use en modo de solo lectura. La opción más segura para lograr eso es a través de un dispositivo de bucle de solo lectura.

      # losetup --read-only --find --show / dev / sda
     / dev / loop42
     # synchronization
     # qemu-kvm -disk file = / dev / loop42, readonly 

    Como GRUB no necesita hacer ninguna escritura, debería poder ver exactamente lo que sucederá. Sin embargo, asegúrese de que su disco esté sincronizado ya que una modificación de file reciente en / boot aún puede residir solo en la memory y no en el disco. Si puedes desmontar / arrancar esa sería la mejor opción.

    Para su problema de línea de command, tenga en count que puede hacer X sobre SSH (aunque es terriblemente lento). KVM también ofrece VNC, console serie y otras funciones remotas.

    Si no puede ejecutar una VM en el server (por ejemplo, si es un VServer), puede usar el Dispositivo de bloque de networking (NBD) en modo de solo lectura o incluso en modo de escritura por escritura para ejecutar la máquina virtual del server. sobre la networking. El server ni siquiera necesita compatibilidad con NBD para eso, solo necesita ejecutar el daemon del server. Sin embargo, el cliente debería soportar NBD en kernel.

    Por supuesto, todo el concierto de simulación es exagerado si, en cambio, solo pudieras leer y comprender el file grub.cfg. Desafortunadamente, los que se generan automáticamente son muy largos y no se pueden leer con un estilo innecesario.