This has turned out to be a non-issue that only affected the system I was working on. I have logged into another ARM64 machine and ipmiutil works in-band as expected. Sorry for the false alarm. Thanks Andy and Hozefa for enabling this platform!
Thanks for the quick response as always Andy! C:\Windows\System32\drivers\IPMIDrv.sys does exist. It does load the ipmi driver according to driverquery: IPMIDRV IPMIDRV Kernel But it seems the part that is missing is the Microsoft_IPMI WMI classes. I am surprised these are platform specific. As a sanity check, when I try to instantiate this WMI class on server 2019 x86_64 it works: PS C:\Users\Administrator> $CimSession = New-CimSession PS C:\Users\Administrator> $ipmi = Get-CimInstance -Namespace...
ARM64 Windows Server 2019 does allow the program to run, but when I try to run commands against the local BMC, I am unable to get the driver to load. Any special workarounds needed for the KCS interface? Or, could this be some signing issue? Thanks! Here is the output from ipmiutil config -x: ipmiutil config ver 3.13 ipmi_open: driver type = ipmi_open_ia: error opening \.\Imb to imbdrv.sys ipmi_open_ms: cannot open microsoft_ipmi driver (ipmidrv.sys) ipmi_open rc = -16 type = Driver type , open rc...
Added support for hours in ClockTime class. Enabled all display calculations.
Added Linux build and readme.txt
Set title, added Windows 64-bit icons and build scripts
Removed some debugging statements to prepare for release
Added GPLv3 license
timecalc.py
Fixed button order, added comments, removed remaining debugging messages
Renamed readme.txt to build.txt. Added readme.txt
Added GUI, which handles all buttons and keys but provides no logic yet
Added negative number output, variations on operator concatenation
You are correct. There is no need for lanplus in WinPE. If I can make it all in one binary, or at least one package with a wrapper, it will make a more consistent experience with the existsing 2.98 version that works in both WinPE and FullOS. I understand it is not a big priority. Thanks!
OK thanks, this does help. I will do a dependecy walker on those DLLs to narrow this down. Or, as a last resort, I can make a wrapper that calls the lanplus version if a lanplus call is made.
Interesting findings. Prebuilt 3.0.6 does not work under WinPE 10. Applying the ipmiutil2-64.mak and ipmiutil2.mak files you provided had no impact alone, but combining those with your buildmin script works. I get the help output and can do an ipmiutil sel (for example) and it seems to work locally in WinPE10. Do you blame openssl for this? Any more steps you can suggest to help isolate the offender here? Thanks!
Prebuilt does not run in WinPE. I will experiment with the different suggestions on my home system tonight. Thanks for your help Andy!
I was able to workaround the 32/64 issue and was able to successfully build as I was referring to in ticket #28. This ticket is more related to not having any output or errors when trying to run the same resulting binary (that works on a full windows OS) on WinPE10 64-bit. I am not sure what additional debugging steps I can take in this environment, or if there are any flags I can set that might help. Thanks!
OK, the VS2017 puts its vavarsXX.bat files in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build. Seems like a challenging problem. My vote is that having separate buildwin32/buildwin64 is quite reasonable. This build env is at home, so let me know if you need any more data from my env or any more tests to run. Thanks!
ipmiutil 3.0.6 x64 WinPE run issue
ipmiutil 3.0.6 x64 build script issue
Sorry for the lack of update. The crash was not reproducible after a BMC update past...
ipmiutil 2.9.8 sel crashes after displaying 2 entries