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.
- A corrupt loop (encrypted agents).
- The ext2 filesystem bug is directly affecting bootability.
- The protected machine is corrupt.
- The live dataset is corrupt.
- More than one volume is flagged as a boot volume.
Follow the following troubleshooting steps appropriate for your agent:
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. Verify that only one volume is designated as the boot volume. You can check this in Windows under Disk Management (external link).
5. If all steps fail, contact Datto Technical Support.
Encryption loop corruption can cause SeaBIOS errors. Reboot the Datto appliance then queue a screenshot. If this does not resolve the issue, perform the troubleshooting steps for all agents if not already completed.
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/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 vmlinuz, initrd.img, config, 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.
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.