Storm season is back, bringing with it the potential for significant weather events. If you have clients in areas prone to infrastructure disruption, visit the Disaster Recovery Resources guide for preparedness information. Datto recommends performing proactive disaster recovery testing to mitigate potential downtime. See our articles about the importance of disaster recovery testing and Preparing For A Cloud Virtualization Test: Policies, Procedures, And Partner Responsibilities to learn more. For live updates, follow @datto on Twitter.

Screenshot Verification: Troubleshooting SeaBIOS Screenshot Failures



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


  • An incorrect virtualization storage controller used for screenshot virtualization.
  • For an encrypted agent, a corrupt loop.
  • The ext2 filesystem bug directly affecting bootability.
  • The protected machine is corrupt.
  • The live dataset is corrupt.


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 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 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.

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