03:01:44 <Smithx10> @sommerfeld  What did you need to do?  I tried earlier and got the "windows 11 not supported on this machine" 
16:54:49 <sommerfeld> 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.
16:58:55 <Smithx10> @sommerfeld  ahhh ok,  Maybe I have to do that for 2025 and 11 
17:00:25 <sommerfeld> andyf has a bhyve sync out for review that adds an emulated software TPM to bhyve.
17:01:28 <sommerfeld> 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.   
17:04:02 <Smithx10> I think it also might need minimum storage too * 
17:04:17 <sommerfeld> https://superuser.com/questions/1699669/windows-11-install-with-disable-tpm-and-secureboot-option-for-older-computer
17:04:45 <sommerfeld>     Boot that drive and once the Windows installer has started, press Shift+F10 to open a command prompt.
17:04:46 <sommerfeld>     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).
17:06:18 <Smithx10> Nice https://iamroot.it/2021/10/06/windows-11-autounattend-xml-bypasstpmcheck-bypasssecurebootcheck/
17:07:45 <sommerfeld> yeah, annoyingly the windows 11 installer doesn't tell you which requirement wasn't met!
17:08:43 <Smithx10> Ive been digging into panther logs etc lol 
17:19:47 <sommerfeld> 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.  
17:22:36 <Smithx10> Those bypass checks worked for 11 in my unatttend awesome.  I don't know if 2025 is the same issue or not*
19:49:48 <gitomat> [illumos-gate] 17224 clean up mac_ether_offload_info() returns -- Patrick Mooney <pmooney⊙pc>
20:38:17 <jbk> 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?
20:38:51 <jbk> e.g. stick the machine into 64-bit mode, flat addressing, and maybe provide basic services for disks, etc.
20:41:41 <tsoome> I can imagine how it could be created, but I haven't seen such implementation.
20:42:22 <richlowe> I would imagine edk will do that
20:42:33 <richlowe> it's also something u-boot will arrange for on ARM systems
20:42:39 <richlowe> (via edk2)
20:42:41 <tsoome> yep, exactly. 
20:44:06 <richlowe> I was interested to see apparently AMD have ditched VGA (I guess?) in their graphics stuff
20:44:08 <tsoome> and it would not really want to dance in between long mode and 16-bit real mode to use BIOS functions, I would imagine;) 
20:44:22 <richlowe> or at least they "require" EFI now, and bios won't work
20:44:28 <richlowe> I'm guessing the reason, I suppose
20:45:00 <tsoome> yes, it is told times ago that one should not expect to have VGA
20:45:14 <tsoome> VGA BIOS, that is.
20:45:22 <richlowe> oh yes, but people listening and acting on it is kinda rare in the x86 world
20:46:01 <richlowe> I still don't know whether to have hopes for the effort(s?) to nudge x86 toward just booting in long mode
20:51:59 <sommerfeld> Intel dropped its x86S initiative: https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end
20:53:30 <tsoome> yep.
20:54:48 <tsoome> we too do the real mode switch dance from 64-bit kernel (in case of BIOS boot ofc).
20:58:34 <Smithx10> 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?
21:00:47 <sommerfeld> 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
21:01:50 <sommerfeld> 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.
21:02:41 <Smithx10> ahh, that is something to explore 
21:02:46 <Smithx10> https://github.com/TritonDataCenter/packer-plugin-bhyve/blob/main/builder/bhyve/driver.go#L96
21:08:41 <sommerfeld> tsoome: one annoying bit I recall was that you had to repeat the mode switch dance on every new core/thread!
21:08:59 <tsoome> ouch
21:09:18 <sommerfeld> (probably still do)
21:09:39 <tsoome> yea, bios bootloader is lucky to run single threaded;)
21:11:15 <sommerfeld> (see real_mode_start_cpu, usr/src/uts/i86pc/ml/mpcore.S )
21:16:04 <richlowe> anything that says "real mode platter" near it, is scary
21:16:44 <richlowe> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/os/mp_pc.c#L33 acts like it's about to explain it when you grep, and then doesn't.
21:33:35 <sommerfeld> 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.
21:59:24 <jbk> richlowe: i thought with UEFI it's already in 64-bit mode.. it's just the older stuff still using BIOS
22:00:08 <jbk> (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)
22:00:13 <jbk> but that assumes UEFI
22:02:19 <tsoome> well, its basically an alternate binary as long as we need to keep bios support. 
22:35:35 <Smithx10> sommerfeld:  thanks for that tip,  I think it will help with the packer-bhyve-plugin