The screenshot verification process fails, displaying the message, "SeaBIOS (version Ubuntu-1.8.2-1ubuntu1) / Machine UUID / Booting from Hard Disk . . ."
- Screenshot virtualization is using an incorrect virtualization storage controller.
- A corrupt loop (encrypted agents) is causing screenshots to fail.
- The ext2 filesystem bug is directly affecting bootability.
- The protected machine is corrupt.
- The live dataset is corrupt.
- You have flagged more than one volume as a boot volume.
Follow the following troubleshooting steps appropriate for your agent:
1. Verify that you only have one volume designated as the boot volume. You can check the boot volume in Windows under Disk Management (external link). To check the boot flags on Linux systems, see the Linux Agent section below.
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 corruption on the agent, 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. If the resulting screenshot fails, you may need to delete the base image associated with the agent.
4. If all the above 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.
Multiple boot flags
To ensure you have boot flags on only one volume, check the Flags column in the output of this command:
You can also check the flags using GParted or KDE Partition Manager if you have a graphical environment installed. Ensure that there is only one protected volume with boot in the list of flags.
EXT2 filesystem kernel bug
Verify you have not excluded the /boot partition in the agent's Volume-Level Backup Control settings. If you have not excluded the partition, and backups are completing successfully, mount a file restore and verify that the /boot partition is present. If the /boot partition is missing, the production machine may be affected by a bug caused by pausing the filesystem on an unjournaled ext2 partition (external link).
To resolve this issue, convert the /boot partition on the production machine to ext3 or ext4 (external link). 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:
1. 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)."
2. If /boot/initrd.img-<kernel version>-generic __ is missing, run the following command to regenerate the file:
sudo update-initramfs -c -k.
3. Verify that the vmlinuz, initrd.img, config, and system.map files are present.
4. Verify that the grub directory is present and that the contents of the grub.cfg file match the platform version on which the agent is running.
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 protected machine 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.
If the above steps fail to resolve the issue, contact Datto Technical Support.