@sommerfeld What did you need to do? I tried earlier and got the "windows 11 not supported on this machine"

Smithx10: a bunch of things. First is to make sure you give the VM multiple threads and enough memory. The second one involved hitting a function key while the installer was running to pop up a windows shell, running regedit and adding a few registry keys to tell it to bypass the TPM check.

@sommerfeld ahhh ok, Maybe I have to do that for 2025 and 11

andyf has a bhyve sync out for review that adds an emulated software TPM to bhyve.

I ended up installing windows 10, then running the program that tells me *why* my machine can't run windows 11 to figure out the "need > 1 cpu" thing.

I think it also might need minimum storage too *

Boot that drive and once the Windows installer has started, press Shift+F10 to open a command prompt.

Type regedit and create the relevant bypass registry keys (Navigate to HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig\ and create new DWORD32 registry keys BypassTPMCheck and BypassSecureBootCheck, setting their value to 1).

Nice iamroot.it/2021/10/06/windows-11-au…ypasstpmcheck-bypasssecurebootcheck

yeah, annoyingly the windows 11 installer doesn't tell you which requirement wasn't met!

Ive been digging into panther logs etc lol

I went down this path because a nonprofit my wife volunteers at has a membership database which is based on microsoft access -- and it needs some work.

Those bypass checks worked for 11 in my unatttend awesome. I don't know if 2025 is the same issue or not*

[illumos-gate] 17224 clean up mac_ether_offload_info() returns -- Patrick Mooney <pmooney⊙pc>

somewhat off topic, but thought someone might know -- is there any sort of project that'd provide a UEFI-like experience for legacy bios systems?

e.g. stick the machine into 64-bit mode, flat addressing, and maybe provide basic services for disks, etc.

I can imagine how it could be created, but I haven't seen such implementation.

I would imagine edk will do that

it's also something u-boot will arrange for on ARM systems

(via edk2)

yep, exactly.

I was interested to see apparently AMD have ditched VGA (I guess?) in their graphics stuff

and it would not really want to dance in between long mode and 16-bit real mode to use BIOS functions, I would imagine;)

or at least they "require" EFI now, and bios won't work

I'm guessing the reason, I suppose

yes, it is told times ago that one should not expect to have VGA

VGA BIOS, that is.

oh yes, but people listening and acting on it is kinda rare in the x86 world

I still don't know whether to have hopes for the effort(s?) to nudge x86 toward just booting in long mode

Intel dropped its x86S initiative: tomshardware.com/pc-components/cpus…x86-instruction-set-comes-to-an-end

yep.

we too do the real mode switch dance from 64-bit kernel (in case of BIOS boot ofc).

While doing these image builds in parallel, I noticed that bhyve can exit and the VNC server may take few seconds to come up. Is this the intended behavior?

Smithx10: what I noticed is that each "reboot" (and there are a bunch of them during a Windows install) causes the VNC connection to drop

Didn't notice much in the way of a delay coming up but I had the bhyve fbuf "wait" option enabled (so it paused until a VNC client connected) and I wasn't necessarily quick in manually reconnecting.

ahh, that is something to explore

tsoome: one annoying bit I recall was that you had to repeat the mode switch dance on every new core/thread!

ouch

(probably still do)

yea, bios bootloader is lucky to run single threaded;)

(see real_mode_start_cpu, usr/src/uts/i86pc/ml/mpcore.S )

anything that says "real mode platter" near it, is scary

github.com/illumos/illumos-gate/blo…er/usr/src/uts/i86pc/os/mp_pc.c#L33 acts like it's about to explain it when you grep, and then doesn't.

starts in 16-bit real mode, then have to crawl upwards layer by layer until you get to 64-bit protected mode. "ontogeny recapitulates phylogeny" for systems software.

richlowe: i thought with UEFI it's already in 64-bit mode.. it's just the older stuff still using BIOS

(it would be really nice in several ways if we could be started w/ UEFI boot services still running, and then terminate them ourselves a bit later in the boot)

but that assumes UEFI

well, its basically an alternate binary as long as we need to keep bios support.

sommerfeld: thanks for that tip, I think it will help with the packer-bhyve-plugin