Screenshot Verification: Troubleshooting SeaBIOS Screenshot Failures

Follow

Issue

The screenshot verification process fails, displaying the message "SeaBIOS (version Ubuntu-1.8.2-1ubuntu1) / Machine UUID / Booting from Hard Disk . . ."

Cause

  • The incorrect storage controller has been selected for virtualization the agent during the verification process.
  • For an encrypted agent, the loop used in the verification process is corrupted.
  • A bug that directly affects agents that use the ext2 filesystem.
  • The agent and/or the live dataset is corrupt.

Resolution

Follow the following troubleshooting steps appropriate for your agent:

All Agents

1. Swap the Virtualization Storage Controller used to boot VM during the verification process. Queue a screenshot after modifying the controller.

2. Force a differential merge for the next backup attempt. Queue a screenshot for the the resulting snapshot.

3. The agent's boot volume may be corrupt. To assess this on the agent itself, run tools that check and resolve disk errors, such as chkdsk or fsck, depending on the agent's operating system. Flag the next backup to force a differential merge as described in step 2. If the resulting screenshot fails, you may need to delete the base image associated with the agent.

4. If all steps fail, contact Datto Technical Support.

Encrypted Agent

Encryption loop corruption can cause SeaBIOS errors. Reboot the Datto appliance whenever possible, then queue a screenshot. If this does not resolve the issue, preform the troubleshooting steps for all agents if not already performed.

Linux Agent

EXT2 Filesystem Kernel Bug

Verify the /boot partition is not excluded in the agent's Volume-Level Backup Control settings. If it is not excluded, and backups are completing successfully, mount a file restore and verify that the /boot partition is present. If it is missing, the production machine may be affected by a bug caused by pausing the filesystem on an unjournaled ext2 partition.

To resolve this issue, convert the /boot partition on the production machine to ext3 or ext4. Updating the agent's kernel to a version newer than 4.1 can also resolve the issue.

Verify Boot Partition Contents

On the agent, or its file restore, navigate to the the /boot partition, and check for the following:

  • Verify that there is information present for the current kernel in use. Look for a file similar in name to '/boot/initrd.img-<kernel version>-generic.'
  • Screenshots can fail if the Datto appliance cannot find the /boot/initrd.img-<kernel version>-generic file, which causes VM preparation to fail, and exit with the error state "Failed to locate initial ram disk (initrd)."
  • If /boot/initrd.img-<kernel version>-generic __ is missing, run the sudo update-initramfs -c -k command on the production system to regenerate the file.
  • Verify that the vmlinuzinitrd.imgconfig, and system.map files are present.
  • Verify that the grub directory is present, and that the contents of the grub.cfg file match the platform version that the agent is running on.

Figure 1: Example contents of a healthy /boot directory on a Linux machine

Corrupted Boot Partitions

If you have ruled out all of the above issues, and you have attempted to take a new base image without success, verify that the boot partition on the agent is in a healthy state. Run fsck scan on the volumes and partitions that /boot is on, and attempt another backup once the scan completes.


Was this article helpful?

0 out of 0 found this helpful

You must sign in before voting on this article.

Calling all Partners! We want to hear your feedback! Please participate in this quick survey and help us build a better, more-relevant Knowledge Base!

Want to talk about it? Head on over to our Community Forum!