How to figure out GRUB2's menu output

Question

I have just updated a remote machine which is running Ubuntu Server 12.04. I have only access through SSH and now it's asking for a reboot. I'm guessing a new kernel was installed. I need to make it boot in a very specific kernel, otherwise it will just hang. Is there any way to check (from the command line, since I am connecting through SSH) what GRUB2 is going to do on the next reboot?

I mainly need to make sure that:

1. The machine is going to boot on the right kernel (Which now may have been moved into the "Previous Linux Versions" submenu)
2. The GRUB2 menu is going to "obey" my timeout request (in some occasions I found machines that would just get stuck with the GRUB2 boot menu, despite of having a GRUB_TIMEOUT parameter specified in /etc/default/grub)

So is there any way to "simulate" or diagnose what GRUB2 is going to do on the next reboot? Some way to check things like "It is going to boot kernel yaddayaddayadda and it has a timeout activated of yadda seconds"

I know it's a long shot, but maybe there is something like a diagnose tool (which is going to have to be command line... I don't even have X-Windows on the computer I'm connecting to)

Thank you in advance!

Answer 1

The only way to really SIMULATE that I know of is to pass the disk to a VM.

I do this a lot with my GRUB2 USB stick, which has kernels for my desktop and netbook plus a dozen Linux Live CDs as well as boot entries memtest, DOS, Windows, ...

When I change something in the configuration there (like adding another Live CD ISO), I can test whether it boots by starting the USB stick in a KVM session.

Unfortunately this solution will be deadly to you, if the system actually boots and then writes to the disk! Filesystems go ka-boom since they're still in use by the host, and then the guests starts repairing and using them too...

So to use this safely, you'd have to make sure your VM uses it in read-only mode. The safest option to achieve that is through a read-only loop device.

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

Since GRUB itself does not need to make any writes, you should be able to see exactly what will be happening. Make sure your disk is synced to though as a recent file modification on /boot may still reside in memory only and not on disk. If you can umount /boot that'd be the best option.

For your command line problem, note you can do X over SSH (even though it's awful slow). KVM also offers VNC, serial console and other remote-features.

If you are not able to run a VM on the server (for example, if it is a VServer), you could use Network Block Device (NBD) in read-only or even in copy-on-write mode to run the server VM over the network. The server does not even need to support NBD for that, it just needs to run the server daemon. The client would have to support NBD in kernel though.

Of course the whole simulation gig is overkill if instead you could just read and understand the grub.cfg file. Unfortunately the automatically generated ones go great lengths to make it unreadable with unnecessary styling.