Technical troubleshooting guide for Hovixa VPS boot failures. Learn to use the SolusVM 2 VNC console to diagnose kernel panics, GRUB errors, and filesystem corruption.

Troubleshooting Kernel Panics and Boot Failures Using the VNC Console

A Kernel Panic or boot failure is one of the few scenarios where a VPS becomes completely unreachable via SSH. Because the Operating System fails to initialize the network stack, you must use the HTML5 VNC Console in SolusVM 2 (vm.hovixa.com) to view the "serial output" of the boot sequence. This allows you to see exactly where the initialization process hangs and take corrective action.

1. Identifying the Boot Stage Failure

To diagnose the issue, you must observe the boot sequence in real-time. Open your VNC console and trigger a Reboot from the SolusVM panel. Watch for the following failure points:

• GRUB Error: If the screen says grub> or error: no such partition, the bootloader cannot find its configuration file or the kernel image.
• Kernel Panic: Usually indicated by a screen full of technical text ending in - end Kernel panic - not syncing. This often happens after an interrupted kernel update or a missing driver.
• Initramfs/Dracut Prompt: If the boot hangs at a (initramfs) prompt, the system was able to load the kernel but cannot mount the root (/) filesystem.

2. Common Fix: Booting an Older Kernel

Most kernel panics occur immediately after a yum update or apt upgrade. If a new kernel is incompatible with your current configuration, you can temporarily revert to a stable version:

1. Reboot the VM while watching the VNC console.
2. When the GRUB menu appears, use the arrow keys to stop the timer.
3. Select Advanced options for... and choose the previous kernel version (the one below the top entry).
4. If the system boots successfully, uninstall the broken kernel or update your GRUB configuration to make the older kernel the default.

3. Repairing Filesystem Corruption

If the VNC console shows fsck died with exit status 4 or drops you into an emergency shell because the disk is read-only, you must perform a manual filesystem check.

Execution Steps:

# Identify the root partition (usually /dev/vda1)
blkid

# Run a non-interactive repair (the disk must NOT be mounted)
fsck -y /dev/vda1
    

After completion, type reboot to attempt a normal start.

4. Troubleshooting Diagnostic Table

5. Technical Implementation Details

• Serial Console Log: If the VNC screen is blank during a panic, your kernel may not be configured to output to the VGA console. You may need to add console=ttyS0 console=tty0 to your GRUB boot parameters.
• CPU Features: Some kernel panics (like Invalid opcode) occur if the OS requires a CPU flag that isn't passed through. Hovixa uses a "Host" CPU passthrough model to prevent this, but older ISO installs may require manual configuration.
• Persistence: Changes made in the GRUB editor (pressing e) are volatile. To make them permanent, you must edit /etc/default/grub once you have regained access to the OS and run update-grub.

Sysadmin Advice: If you cannot resolve the panic within 15 minutes, do not waste more time. Use **Rescue Mode** to exfiltrate your data and perform a clean **OS Reinstall**. It is often more efficient than debugging a corrupted kernel initramfs.