macOS Creating bootable ISO for VMware

[Nermal]

This is an extremely niche question so I fully appreciate that I may not get an answer here... I'm just too lazy to sign up to a more appropriate forum if I don't have to

In an effort to learn a bit more about how modern computers work, I've had a bit of a play around and have created a "Hello World OS" that, so far, does nothing but say "hello world" and then loop infinitely. With the docs over at https://wiki.osdev.org/UEFI#Creating_disk_images I've used hdiutil to produce a .cdr image containing my bootx64.efi file:

hdiutil create -fs fat32 -ov -size 48m -volname NEWOS -format UDTO -srcfolder diskImage uefi.cdr

The resulting image works in QEMU, but that's a bit too fiddly for my taste so I'm trying to use it in VMware. However, I'm getting stuck. When I start up the VM, I get the following:

Attempting to start up from:
-> EFI VMware Virtual IDE Hard Drive (IDE 0:0)... No Media.
-> EFI VMware Virtual IDE CDROM Drive (IDE 1:0)... No Media.
-> EFI Network...

I'm not sure why it's reporting no media in the CD drive, because the image is definitely mounted. If I boot into the EFI Shell and run "map" then it only shows blk0 and blk1; fs0 isn't mapped.

There's presumably something wrong with the image; it seems that QEMU can tolerate it but VMware doesn't like it. I can double-click it in Finder and it mounts successfully and I can see the directory structure and bootx64.efi file. It's probably something subtle.

If I mount a different ISO file (such as a Linux distribution) then fs0 shows up inside the EFI Shell, so I'm pretty sure that the issue is with the image creation process itself.

So my question is "does anyone know how to make an image that VMware is happy with?"

 

[casperes1996]

I wrote an operating system for my bachelor project at uni. OSDev is such a good website with so much helpful info. Though I made my OS with the old Legacy BIOS based boot up with an MBR partition and wrote a bootloader in the MBR partition that loaded in the rest. Not with EFI.

What is the structure of the srcfolder diskImage? Does it have the /efi/boot folder structure?

 

[Nermal]

Sorted. I had the wrong end of the stick entirely. Despite the command on OSDev creating a file with a .cdr extension, it seems that it's actually a hard disk image rather than a CD. I just had to present it to the VM as a hard disk instead of a CD, and now it works correctly.

In case you're wondering, "qemu-img convert uefi.cdr -O vmdk uefi.vmdk" will convert the .cdr image to the .vmdk format used by VMware.

What is the structure of the srcfolder diskImage? Does it have the /efi/boot folder structure?

Yep. I'm trying to do things the modern way

 

[casperes1996]

Yep. I'm trying to do things the modern way

It’s on my todo list to try and modernize my OS too. It’s already 64-bit and the boot loader can probably be removed entirely or at least reduced a lot with UEFI. But first I would also need to explore why it breaks in modern versions of GCC so the todo list is long haha. Also want to convert it to arm at some point.

 

[Nermal]

I haven't given up on this yet... although the OS doesn't do much yet either

I uncovered an interesting bug though! I gave it a go on real hardware, and it promptly crashed as soon as I moved the mouse. Interestingly it works if I plug in the mouse after booting, but crashes if it's there during boot! Meanwhile it's fine under VMware. A bit of a mystery, but I suppose that's part of the "fun".

I'm going to have to try it on another machine and see what happens, but in the meantime I'm still using VMware as the primary development environment (I've scripted it to update the disk image on build, which is certainly a lot quicker/easier than writing the image to a physical disk!).

 

[casperes1996]

I haven't given up on this yet... although the OS doesn't do much yet either

I uncovered an interesting bug though! I gave it a go on real hardware, and it promptly crashed as soon as I moved the mouse. Interestingly it works if I plug in the mouse after booting, but crashes if it's there during boot! Meanwhile it's fine under VMware. A bit of a mystery, but I suppose that's part of the "fun".

I'm going to have to try it on another machine and see what happens, but in the meantime I'm still using VMware as the primary development environment (I've scripted it to update the disk image on build, which is certainly a lot quicker/easier than writing the image to a physical disk!).

This could have to do with interrupts. The working scenario is a bit odd but it is possible there's an IDT that works for some interrupts and not others and it jumps to invalid instructions. Or maybe you need to disable interrupts early in your boot process because it isn't entirely off at boot and an interrupt fires before you configure an IDT.

For the scripting aspects; That's exactly why I like using qemu. It's very easy to script with and extremely configurable. And if I want to test how my code behaves under different CPU feature sets it's very easy to configure that too.

I've started making a Rust OS myself for fun, dubbing it ROSE. Rust Operating System Environment
I'm also seeing issues with my stuff though, where it doesn't work if I run it with HVF acceleration (Apple's Hypervisor Framework for full hardware acceleration). But it seems like it halts/triple-faults before it even gets to my code. I tried putting

infLoop:
jump infLoop

at the top of my assembly entry point and it still boot-loops; Need to try it with KVM at some point. Aside from that it's fun to tell qemu to use different CPU types and watch the CPU model/vendor strings in CPUID change

I also found it easier to set up a build environment using Docker for cross compilation than setting up a local cross-compiling environment.

How far in are you at this point?
What method do you use to write your text out? Are you still in the UEFI BootServices and use its ConsoleWrite? Or are you interfacing with video out directly?
I'm personally using VGA Text Mode, which in fairness is not entirely supported by UEFI based systems but most of the ones out there still do support it through a BIOS compatibility interrupt mode switch. But the plan is to switch to a proper video mode later in the boot process anyway

 

[Nermal]

We're definitely attacking this from different angles



The mouse pointer moves, the window can be moved and resized, and it handles redraw (i.e. doesn't leave a trail of mouse pointers everywhere). Obviously no ConsoleWrite here!

Next on the agenda is either some window furniture or the ability to have more than one on the screen at a time. And every time I see "1024" or "768" in my code I keep thinking "I have got to stop hard-coding that"!

I've scripted it to update the disk image on build, which is certainly a lot quicker/easier than writing the image to a physical disk!

I've subsequently realised that I was wasting time by doing that. Sure, I had to write the image the first time to get the on-disk structure correct, but once that's done it's just a matter of replacing bootx64.efi with a new one.

 

[casperes1996]

The mouse pointer moves, the window can be moved and resized, and it handles redraw (i.e. doesn't leave a trail of mouse pointers everywhere). Obviously no ConsoleWrite here!

Next on the agenda is either some window furniture or the ability to have more than one on the screen at a time. And every time I see "1024" or "768" in my code I keep thinking "I have got to stop hard-coding that"!

Ah cool. I didn't expect proper graphical support set up
I assume you're getting a GOP frame buffer and writing pixel data into it, probably with double-buffering?

But yea different approaches. I'll tackle graphics last

I've subsequently realised that I was wasting time by doing that. Sure, I had to write the image the first time to get the on-disk structure correct, but once that's done it's just a matter of replacing bootx64.efi with a new one.

This is where I think QEMU is actually really awesome. You don't need to create an ISO or disk image or virtual disk or anything like that - you can point qemu at a folder or even a .efi file directly and have it automatically deal with the rest. Though EFI in QEMU is a tad more annoying since you need to get the Tianocore image separately. There's also a nice Rust crate called uefi-run that can quickly run an EFI program through QEMU if you have a Tianocore in the working directory with just "uefi-run <path_to_.efi_program>" - It also has really good debugging utilities like dumping the CPU's registers to a file if a triple fault occurs and such. I've not tried this sort of thing with VMWare though so its workflow may also work very well

 

[Nermal]

I assume you're getting a GOP frame buffer and writing pixel data into it, probably with double-buffering?

Bingo, although without the double buffering at this stage (might need to sort that out at some point though).

This is where I think QEMU is actually really awesome. You don't need to create an ISO or disk image or virtual disk or anything like that - you can point qemu at a folder or even a .efi file directly and have it automatically deal with the rest.

If I had to do all of it every time then that'd be one thing, but when I've scripted a build that automatically updates the VMware image, there isn't really anything to worry about any more.