Divided between ease-of-use, security and other technicalities, installing operating systems on unsupported devices or for environments that the operating system was not designed to run on has become progressively difficult. The transition from MBR to GPT partition types alone has set a whole new range of problems, in particular where users do not wish to upgrade their hardware or are lagging behind the development curve with unsupported or partially supported hardware. Additionally, the secure boot, U/EFI, TPM and other security requirements have made it progressively difficult to install operating systems on unsupported hardware.

It seems ever more apparent that software and hardware producers have formed deliberate or undeliberate trusts to ensure that computers are delivered as a black-box where software and hardware are so tightly coupled that upgrading involves the purchase of both. Historically, this has been observed more in the mobile device domain where devices have become expendable or consumable goods, followed closely by companies such as Apple that have quickly adopted the planned obsolescence at both the hardware and software level and yet with even Microsoft following the same pattern where security has been leveraged to also include some form of inescapable DRM.

This page summarizes some of the strategies involved in installing operating systems on unsupported hardware.

The following section summarizes the tools used most of the time for installing Windows in unsupported environments.

The main goal of these tools is to have access to:

• a partitioning tool that can run in RAM,
• a tool that can generate USB installation media given different partition layout and boot technologies

• Rufus,
• Parted Magic although gparted should get the job done whilst being freely accessible,
• virtualization software such as VMWare
• multi-boot tools such as:
  • veency
  • easy2boot

are always good to have around even though the tools are sometimes messy and have varied support for Apple machines.

There are many tools out there that achieve more or less the same effect and some do that in various ways that do not help much.

A counter-recommendation is, for example, "Balena Etcher" (as opposed to "Rufus") that rose as a hype mainly due to its ease-of-use and flashy interface but unfortunately does not allow precise specifications to be made on the type of USB installation medium to generate. In fact, "Balena Etcher" will happily take an ISO file and dumbly bitwise-copy the ISO file onto an USB stick with several warnings ala disk-dump "dd" on Linux - which, will fail anti-climatically upon boot.

Similarly, whilst the disk dumper tool "dd" on Linux is a great tool for performing bitwise-copies, copying ISO or image files onto USB installation drives will also lead to various degrees of failure. The main reason is that a tool such as "Rufus" goes the extra mile to repartition and adjust the USB drive such that it can be recognized when booted.

"veency" and "easy2boot" are currently racing each other to be supported on Apple machines such that both tools will have varying degrees of success when booting off the generated USB stick. Unfortunately, it is still the case that there is no universal multi-OS / multiboot tool available that will span the three main operating systems: Windows / Linux / MacOS (OSX).

"VirtualBox" has strange support for using a physical drive as the hard-drive that does not seem to work in most cases while "KVM" / "qemu" are more oriented towards unattended or automated virtualization - even so, "VMWare" itself has quite some requirements regarding CPU features such that different versions must be tried in case virtualization is not fully supported for the machine that "VMWare" runs on.

• good Internet connection and stable LAN,
• CD-ROM drive,
• plenty of USB drives ()

The following section summarizes the various strategies used to install Windows.

The straight-install method is the base case and involves installing the operating system as it was delivered by the vendor.

Go figure that installing using a CD-ROM drive is still the best option to install any operating system beyond the floppy-disk era. CD-ROM drives are notoriously inexpensive and even modern operating systems vastly support installing from CD-ROM much better than from USB drives.

On older machines that do not support EFI boot (this includes Apple machines ), the straight install method involves creating a bootable USB drive using a tool such as rufus with the MBR partition scheme selected which also implies a BIOS (non-EFI) boot.

The machine is then booted off the USB stick and, with some luck, operating systems such as Windows will recognize the hard-drive and then install.

On newer machines that support EFI booting, rufus can be symmetrically used to generate an USB install but with the GPT and U/EFI options set.

A rather extreme way of installing an operating system is to first create a virtual machine using software such as VMWare and then install the operating system to an USB drive. Unfortunately, this requires some good virtualization software that is able to use a physical drive, and especially an USB drive, as a hard-drive for the virtual machine.

Once the install is completed, the USB drive is removed and then plugged into the physical machine along with a live partitioning tool such as Parted Magic or gparted. The user will then boot the partitioning tool and transfer the entire partition from the USB where the operating system was installed to the physical hard-drive. Once the operating system is transferred to the physical hard-drive, the physical machine is rebooted and then some method must be devised in order to re-install the boot manager.

Typically, when the hard-drive changes machine or the operating system on the hard-drive is moved to a different hard-drive, operating systems and boot managers that track physical hardware will need to be adjusted.

On Windows, assuming a BIOS boot and an MBR partition layout, the machine can be rebooted using an untouched Windows install drive, the repair option selected and then a command prompt can be opened in order to execute the following command:

bcdboot E:\Windows /s C: /f BIOS

where:

• E: represents the partition where the operating system has been transferred from the USB stick used for the virtualization install,
• C: represents the system drive,
• BIOS refers to the BIOS boot method

Hopefully, this will re-create the \boot directory and allow the operating system to boot upon restarting the machine.

The computer must be booted from an untouched Windows install USB drive, the repair option selected and a command prompt launched. Windows typically creates multiple partitions during a standard Windows install, one of which being responsible for holding the boot record and in order to determine which partition to use, diskpart, the disk partitioning tool for Windows can be used.

Issue inside the command prompt:

diskpart

that should load the diskpart partitioning tool interactively.

Commands such as list disk, list partition and list volume can be used to determine which one is the EFI partition. Typically, the EFI partition is placed by the Windows install as the first partition on the drive. Next, the EFI partition is assigned a volume such that it can be accessed from the command prompt in order to rebuild the boot record.

First, the correct volume is selected:

select volume 0

and a letter assigned:

assign letter=Z

where:

• Z will be the volume that can be used to access the EFI partition.

After exiting diskpart with the quit (or exit command), the EFI partition is accessed:

cd Z:\EFI\Microsoft\Boot

The command:

bootrec /FixBoot

can then be executed in order to generate the boot record.

Finally, to rebuild the BCD store, issue the command:

bcdboot E:\Windows /l en-us /s C: All

where:

• E: is the drive that contains the Windows operating system transferred from the USB disk after installing Windows under virtualization.

In some cases, the command might fail, such that the existing BCD' file will have to be removed before running the aforementioned command:

ren BCD BCD.old

The machine can now be restarted and hopefully Windows should boot normally.

On Linux, the procedure involves installing or updating grub, depending on how grub has been installed - more or less the same procedure applies to LILO.

First, the machine is booted using a live-Linux partition (Parted Magic or gParted should do great) and the physical hard-drive partition is mounted:

mkdir -p /mnt/rescue
mount /dev/sda1 /mnt/rescue

Next, the user will bind-mount the dependent virtual filesystems that will be used by the boot manager to determine the partition layout:

mount -o bind /dev /mnt/rescue/dev
mount -o bind /sys /mnt/rescue/sys
mount -o bind /proc /mnt/rescue/proc

Then, the user will pivot into the /mnt/rescue directory as a root-jail:

chroot /mnt/rescue

Finally, the corresponding boot-manager command will be ran in order to re-install the boot manager. For instance, assuming that grub has been already installed inside the virtual machine:

update-grub

The effect should be that grub will detect the partition layout, the installed operating systems and generate the corresponding boot menu for the physical drive. The machine can then just be rebooted and the live-Linux drive disconnected.

A scalable install strategy is to use PXE / iPXE along with ISO files and other bootstrap methods. This method involves booting from the network card, at which point the machine issues a DHCP request and downloads a payload thereby staging into an environment from which various other payloads can be downloaded and booted (for instance, raw ISO files).

PXE servers are typically capable of booting ISO files however some care should be taken that the ISO file is appropriately large because the ISO file will have to be downloaded to the client machine over the network and then booted.

Network install via PXE for Windows as well as Apple network boot has been covered thoroughly by Wizardry and Steamworks such that the same techniques will not be reiterated except for mentioning that PXE is still an available strategy that might work for strange environments.