0

Background

One of my duties requires having a variety of computers with a series of preconfigured software suites available for use on fairly short notice. These computers have dissimilar hardware, and there is no automatic updates of any sort (let alone a centralized system.) To solve both the issue of deploying these suites and updating them, I've been attempting to use Acronis True Image. Following various instructions in a Windows 10 VM hosted on macOS via VirtualBox, I:

  1. Used Acronis Snap Deploy 5 to create an Acronis Bootable Media .iso.
  2. Booted from that image.
  3. Created a master image offline.
  4. On a new VM, booted from the Bootable Media and successfully deployed the master image.

Issue

While the .iso works fine for booting a VM:

enter image description here

Trying to burn the .iso using unetbootin just causes it to silently struggle, Rufus says the image is unsupported, and Etcher yields an error saying there's no file system:

enter image description here

Which is confirmed by mounting the image in macOS and Windows:

enter image description here enter image description here

However, there is definitely some real data in the image:

enter image description here

Question

How is it possible that an .iso boots perfectly fine with VirtualBox, but has no apparent file system and fails to be imaged to any sort of USB drive? How can I create a bootable version this image for use with a "real" computer?

JMY1000
  • 527

1 Answers1

0

Try to write the image without using conversion tools (such as unetbootin). You can use plain dd, or direct imaging tools like Win32DiskImager. In macOS, this post suggests:

  1. diskutil list to find the "/dev/diskX" device;
  2. diskutil unmountDisk /dev/diskX;
  3. dd if=/path/to/iso of=/dev/rdiskX bs=1M (comments suggest "rdisk" for performance)
  4. diskutil eject /dev/diskX.

ISO images are CD images (the name comes from "ISO 9660"), and they're structured differently from "regular" disks. Most importantly, the boot information is placed in a different location – CDs use an "El Torito" boot record at sector 17; BIOS-compatible disks use a MBR at sector 0; UEFI-compatible disks use a GPT at sector 1 and a whole separate partition to contain the bootloader.

So in order to boot a CD image from USB, there are two options:

  • Programs such as Rufus and Unetbootin don't simply "burn" the image; they convert a pure CD image to a USB one.

    They try to recognize the image's contents, extract them to the USB drive, and create a whole new bootloader that – hopefully – will be compatible with the original one.

    This requires the conversion program to actually understand how the CD image works. (For example, if the CD used isolinux, the converter needs to install syslinux to the USB stick.)

  • Programs such as isohybrid prepare the image itself such that it simultaneously contains CD (ISO 9660), BIOS (MBR), and UEFI boot code, so that it can be written to any kind of disk without further conversion.

    The result is an image whose contents depend on the way you look at it. When written to a CD, the OS will find a regular ISO 9660 filesystem. When the exact same data is written to a USB disk, the OS will find a large "empty" partition and a very small "EFI boot" partition. Example. Example.

Both methods are complex, but the worst case is trying to combine the two. As an example, Unetbootin used to be a good CD→USB conversion tool in the past, but now that Linux distributions are often shipped in already USB-compatible hybrid ISO images, Unetbootin tends to misunderstand their contents and actually output an image that no longer boots.

Finally, disks do not need to have visible files in order to be bootable. There's a bare minimum needed to make the disc or disk boot, but beyond that, everything is controlled by the disc/k's own bootloader itself. So it doesn't matter that you see a completely empty disc; the bootloader might just be looking for its own data elsewhere.

In your case, it seems very likely that the image is already in some sort of hybrid format; it has just enough of an ISO 9660 filesystem to let firmware find the bootloader, but the remainder of the OS is hidden somewhere else.

You can try to determine whether it's actually compatible with BIOS MBR boot format using:

head -c 512 file.iso | hexdump -Cv

If the very last line (000001f0) ends with 55 aa, that means a BIOS MBR partition table is present.

grawity
  • 501,077