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
  • 439
  • 2
  • 7
  • 1
    Note that bootable CDs (e.g. isohybrid) can be rather complex and have several kinds of boot records, multiple partition tables, and even overlapping filesystems. ([For example](https://mjg59.dreamwidth.org/11285.html). [Also](https://mjg59.dreamwidth.org/4957.html).) In other words, just because it looks empty in the file manager, doesn't mean it's empty. – u1686_grawity Nov 29 '17 at 08:41
  • @grawity Thanks for the additional info. Based on the fact that there's basically three different functionalities for the image, it seems logical that something along those lines is going on. That does beg the question how I can actually create bootable media using the image though. – JMY1000 Nov 29 '17 at 08:48
  • Have you tried writing the image to USB _directly_, without any conversion tools? (For example, `dd` or Win32DiskImager. Not unetbootin.) – u1686_grawity Nov 29 '17 at 08:53
  • @grawity I haven't: would [this](https://askubuntu.com/questions/372607/how-to-create-a-bootable-ubuntu-usb-flash-drive-from-terminal) be the right place to look? I have zero experience with `dd`. `sudo dd if=inputfile.img of=/dev/disk> bs=4m && sync` seems to be what they recommend. – JMY1000 Nov 29 '17 at 08:58
  • That should work, if you're _very_ careful with the `of=` parameter (don't accidentally nuke your real HDD!). I think macOS may have an option in Disk Utility to do the same. – u1686_grawity Nov 29 '17 at 09:08

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.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Neither `dd` nor Win32DiskImager worked; the hexdump also did not yield the expected results (everything in that range is 00s.) However, running a full hexdump showed confirmed there clearly was nonzero data. The first of this data though isn't showing up until 0x00008000, but has the text "CD001 ACRONIS_MEDIA". There's also text at 0x00008800 that reads "CD001 EL TORITO SPECIFICATION", before really jumping into data around 0x00013800. – JMY1000 Nov 29 '17 at 09:44
  • I see, so it's bootable as a CD (there's an El Torito sector), but _not_ as a regular disk (the MBR sector is empty), so you _will_ need some sort of conversion tool. For BIOS, the Rufus developer [says it's going to be very difficult](https://github.com/pbatard/rufus/wiki/FAQ#List_of_images_Rufus_isnt_compatible_with). You demonstrated earlier that the CD boots up in UEFI mode, so in theory it'd be easy to extract _that_ to USB, assuming your real firmware is UEFI-compatible – but I don't really have any instructions for that. See if Rufus can do it for UEFI. – u1686_grawity Nov 29 '17 at 11:53
  • Rufus refuses to open the image with the error "This image is either non-bootable, or it uses a boot or compression method that is not supported by Rufus..." Opening the ISO with 7-Zip shows one folder called [BOOT] with two files: https://i.stack.imgur.com/BDhb5.png – JMY1000 Nov 29 '17 at 18:38
  • Also is it true that the [MBR is not necessary for bootable CD/DVDs?](https://superuser.com/questions/1063220/windows-10-iso-on-usb-refuses-to-boot) – JMY1000 Nov 30 '17 at 02:55
  • VM seems to boot fine off the .iso even with EFI disabled as well. Also trying a variety of different configurations for creating the ISO in True Image did not create a MBR partition. – JMY1000 Nov 30 '17 at 04:34