Maybe. They are part of my command-line application. I can run it without tools too by building an application that loads at boot time from the USB disc and does the same actions without any user intervention. That's how we initiate new computers when installing our terminal software.kzinti wrote:Both inithd and mkpart are tools...rdos wrote: No, I don't. I boot with a USB floppy containing my OS and then on the command line I write "inithd /i / r 0", then I create a partition with mkpart, and copy the boot image to the root. That's pretty simple.
It does have to do with UEFI. My OS image is not a linked PE executable, and so cannot be directly loaded neither by 32-bit nor by 64-bit UEFI. Rather, the OS image is built with a tool (or application) from a configuration file that writes a binary that combines a set of device-driver files, settings, application executables, preloaded files and autorun commands. The load64.bin and load32.bin files are executables that can be loaded by UEFI and that sets up an environment so the OS image can be started.kzinti wrote: bootx64.efi is the bootloader... not sure why you need a second stage bootloader (load64.bin) but that's fine, it has nothing to do with UEFI.
Typically, I won't have this problem when I reformat the disc (like in the example), only when I try to update an existing Windoows installation for multiboot. It's often easier to add my OS to GRUB, provided you know where the GRUB config file is and can change it. GRUB booting also needs a second stage loader, much for the same reason as UEFI does.kzinti wrote: I don't know why you have this problem where you need to erase UEFI variables, I have never run into this or heard about it before now.
With MBR booting, there are ten or so sectors that have a similar function as the second stage loader. It will read the OS image to a fixed address and start it.
