reset: enhancement: add -l<num> option for reset/powerup to a specific internal logical instance
reset: target behavior differs depending on the ordering of command-line options
reset: enhancement: add -l<num> option for reset/powerup to a specific internal logical instance
reset: target behavior differs depending on the ordering of command-line options
reset: interpret -e as a modifier, not a target
Thank you for the detailed information, and for the patch. I see why this change is needed.
This was discovered in 3.0.8 but affects all of the active branches.
reset: interpret -e as a modifier, not a target
ipmiutil alarm/health not working on Windows
From Nov 21, 2024 email thread: I really don't have any good answers to resolve this. A few things that you could do: - use version 3.1.8 if that suits you best for this case - investigate the firmware side to see why it appears to return extra bytes for the HMAC - use the new version with -Y Also note that there have been several openssl DLL version upgrades, so the latest (ipmiutil-3.2.1) should have all the current fixes.
failed to build 3.1.9 for macos sequoia
A CVE has been detected even with the latest version of the tool regarding the used OpenSSL stuff (ssleay32.dll). The numbers are CVE-2024-5535 CVE-2016-2177 CVE-2016-2108 CVE-2016-2068 CVE-2022-1292 Any possibility to get this fixed / updated? [https://attachment.freshdesk.com/inline/attachment?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTQxNTgyMDU5NDYsImRvbWFpbiI6InNlcnZlcmV5ZS5mcmVzaGRlc2suY29tIiwiYWNjb3VudF9pZCI6MzcxODk0fQ.N7IPSBwgG9XLI16FuxKOqvCc1pPgZjot5iQMeOYK8D8] Mit freundlichen...
Hm, libipmiutil.so.1 is still not linked against -lcrypto for me when building 3.2.1 release with gcc 14.2.1 on linux/x86_64: x86_64-alt-linux-gcc -g -O2 -o ipmi_sample_evt ipmi_sample_evt.o isensor2.o ievents2.o libipmiutil.a ../lib/libipmi_lanplus.a -lcrypto if [ "xyes" = "xyes" ]; then \ ar x ../lib/libipmi_lanplus.a ; \ x86_64-alt-linux-gcc -shared -Wl,-soname,libipmiutil.so.1 -o libipmiutil.so.1 ipmicmd.o mem_if.o ipmidir.o imbapi.o ipmimv.o ipmild.o ipmibmc.o ipmilipmi.o subs.o md5.o md2.o...
I have included this in iipmiutil-3.2.1, just released. This works for me, but let me know to confirm that you don't have any issues with it.
avoid tampering with TMPDIR
Now included in ipmiutil-3.2.1
libipmiutil underlinked against libcrypto
OK, I have updated the ipmiutil-3.2.1.tar.gz to include -lcrypto in the library build.
ACK; there's #11 though, sorry to come back with that!
libipmiutil underlinked against libcrypto
avoid tampering with TMPDIR
I have applied an update that should resolve this in ipmiutil-3.2.1 (does not set TMPDIR), but would like you to confirm it before pushing this out. Here is the updated tarball - https://ipmiutil.sourceforge.net/FILES/ipmiutil-3.2.1.tar.gz
I've just checked 3.2.0 build without this kludge and it's still failing the same way: lcc: error: cannot open file '/tmp/iu/ipmiutil-3.1.9/lcc_xkFr8c.s' (No such file or directory) Indeed: $ zcat ipmiutil-3.2.0.tar.gz| grep -c TMPDIR 81 Please consider the workaround (sans the typo): s/TMPDIR/TEMPDIR/g; thank you!
avoid tampering with TMPDIR
Sorry for the delay in responding. I remember doing an update for this ticket, and I believe that the change was included in 3.1.7 and beyond, but it isn't enumerated in the Changelog.
This was included in the ipmiutil-3.2.0 changes released 12/05/2024, and also in github.
Yes, I'll do that shortly. Sorry that I missed including that previously.
Hi, Can the patch on the mailing list (https://sourceforge.net/p/ipmiutil/mailman/ipmiutil-developers/?viewmonth=202106) be applied in the next release? Thanks, Richard.
Thanks Andy, I have shipped the patch via https://github.com/Homebrew/homebrew-core/pull/191136, this issue can be closed.
failed to build 3.1.9 for macos sequoia
Attached is the updated oem_dell.c Yes, there was an updated library file added in 3.1.9
any thoughts?
Another thing, I also saw some checksum change with the ipmiutil-3.1.9.tar.gz - sha256 "c0dacc4ad506538f59ed45373b775748deddddc36e6d3c303f5069a59cacab08" + sha256 "5ae99bdd1296a8e25cea839784ec39ebca57b0e3701b2d440b8e02e22dc4bc95" was there some aritfact re-uploading for 3.1.9 release? Thanks!
Thanks for the patch, it actually should be typedef struct { int val; char *str; } vFlashstr; rather than typedef struct { int value; char *string; } vFlashstr; Other than that, it works well for me, thanks! gonna ship with https://github.com/Homebrew/homebrew-core/pull/191136
failed to build 3.1.9 for macos sequoia
It looks like this particuar compiler does not handle these 'const struct vFlashstr' declarations properly. It must need the struct defined explicitly. There are several other oem*.c files affected if so. const struct vFlashstr vFlash_completion_code_vals[] = {... }; I have attached an updated ocm_dell.c which should work better. Please try with that and let me know if it gets past ocm_dell.c now.
failed to build 3.1.9 for macos sequoia
getevt exits with return code ( rv = -3)
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
ipmiutil alarm/health not working on Windows
I appreciate your time and your response.
Let's review the questions you posed: 1) Is there a method to test ipmiutil without a physical IPMI server? A: The purpose of ipmiutil is to support physical IPMI servers, but it may work with the simulators for functions that do not require two-byte sensors (outside the IPMI standard). 2) What is the 'driverless' option in ipmiutil? Normally, when configuring IPMI on a server, it is run locally, and a driver is required for the OS to talk to the IPMI firmware. Key drivers: openipmi (Linux), imb...
Let's review the questions you posed: 1) Is there a method to test ipmiutil without a physical IPMI server? A: The purpose of ipmiutil is to support physical IPMI servers, but it may work with the simulators for functions that do not require two-byte sensors (outside the IPMI standard). 2) What is the 'driverless' option in ipmiutil? Normally, when configuring IPMI on a server, it is run locally, and a driver is required for the OS to talk to the IPMI firmware. Key drivers: openipmi (Linux), imb...
May I kindly request an explanation on this, please?
I am attempting to test ipmiutil using the ipmi_if.txt file and have encountered the following result: # cat ipmi_if.txt # IPMI Device Information device /tmp/.ipmi_dummy # # ipmiutil sel -v -f ipmi_if.txt ipmiutil sel version 3.19 RecId Date/Time_______ SEV Src_ Evt_Type___ Sens# Evt_detail - Trig [Evt_data] 2cde Type0f INF 69 e2 62 de 62 0a 00 00 00 00 01 78 3a ipmiutil sel, completed successfully # I'm interested in understanding the meaning of the output, specifically the line 2cde Type0f INF...
What is the 'driverless' option in ipmiutil? Could you explain it to me?
There are some ipmiutil commands that do not require sensor ids which should work with the simulators (like health, reset, wdt), but if the command to the simulator requires two bytes for sensors, it currently won't work with ipmiutil. It would be a large effort to add support for two-byte sensor ids throughout the code. The purpose of IPMI is to manage physical servers with IPMI firmware.
May I kindly request an update on this, please?
Thank you for your response. Is there a method to test ipmiutil without a physical IPMI server?
I'm not familiar with IPMISIM, but I know that Corey Minyard wrote ipmi_sim, and he has been a key developer in IPMI for a long time. I don't know much about the IPMI simulators, except that some of them have gone beyond the IPMI spec (expanded the number of sensors beyond one byte). I deal mostly with IPMI firmware.
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
FYI, you can see the actual version of ipmiutil.exe each time you run it (3.1.9 will show as 3.19).
Apparently with the 3.1.9 MSI, I must have not updated that instance of the version number from 3.1.8 to 3.1.9. Sorry for the confusion.
I noticed after running the 3.1.9 .MSI installer on windows, under add/remove programs (appwiz.cpl), it shows 3.1.8 is "installed". Not sure if this is a type-o or 3.1.8 was accidentally packaged as 3.1.9?
It could be an issue with specifying the field, or a restriction built into the firmware. If you could send the ifru debug output for this command adding -x, we should be able to find the cause. Andy On Sat, May 20, 2023 at 1:34 AM u-sanada bengal00@users.sourceforge.net wrote: I would like to change the serial number of the Fujitsu PRIMERGY RX2530M1, but it is not possible. ifru -s <serial number=""> command is input, but writing ends with an error. This Server synchronizes information between the...
I would like to change the serial number of the Fujitsu PRIMERGY RX2530M1, but it is not possible. ifru -s <serial number=""> command is input, but writing ends with an error. This Server synchronizes information between the motherboard and the front panel, which we call the chassis, and I think this has something to do with it. If there is a way to use ipmiutil or ifru or another way to write serial numbers to chassis and motherboard respectively It would be helpful if you could tell me. Thank ...
Is it helpful for "InstantEvents" so i can manage the staff and other crew members.
That is not a topic that is related to this software. Ipmiutil is an opensource software project to enable managing physical servers that support IPMI firmware.
Is it helpful for Instant Events so i can manage the staff and other crew members.
ipmiutil_wdt.service did not start
A fix for this is included in ipmiutil-3.1.9 (renaming $prog to $progn) at https://ipmiutil.sf.net
SMBIOS entry point
A fix for this is now published in ipmiutil-3.1.9 at http://ipmiutil.sf.net In order for it to be handled in Linux, Windows, BSD, etc., I used the literal 0x6d5a7000 instead of getting it from systab.
Issues with windows msi installer
The fix for this is now published in ipmiutil-3.1.9 at http://ipmiutil.sf.net
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
The fix for this is now published in the ipmiutil-3.1.9 release at http://ipmiutil.sf.net.
Hi Andy, Sorry for the delayed response. When i compile and load this on my device, I am getting some issues regarding shared libraries, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues regarding shared libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine.
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
OK. I have been preparing a new ipmiutil-3.1.9 release, and I have added this change to ireset.c in it. Can you try it and verify that it resolves this problem? https://ipmiutil.sourceforge.net/FILES/ipmiutil-3.1.9.tar.gz I provided the source tarball, since I don't know which OS flavor you are running.
Yes, it works without that check.
Good question. Originally the Romley systems had different soft shutdown support. The Intel Romley servers were from around 2010 IIRC, so it is possible Intel has reused the Romley ID for a different model, but they've never done that before. In any case, we need to remove the is_romley check in ireset.c based on your experience. If you do that on your system, it works, right?
Hi Andy, How significant is is_romley() check in ireset.c? I see that problem can be resolved by removing this check.
Changing from ipmi_cmd to ipmi_cmd_mc is what allows this to run either normally or via IPMB. For the command that repeats, It is a Chassis Control soft-shutdown command. ipmidir Cmd=02 NetFn=00 Lun=00 Sa=20 Data(1): 05 Send Netfn=00 Cmd=02, raw: 00 20 00 02 05 ipmidir Resp(1,2): status=0 cc=cf, Data(0): 28.3 Chassis Control Command (0x02) 0h = power down 1h = power up 2h = power cycle 3h = hard reset 4h = pulse Diagnostic interrupt 5h = soft-shutdown of OS via ACPI The fact that this returns completion...
Hi Andy, After the upgrade , we moved from drivermode to driverless mode. so it was expected that open ipmi driver not being there. I tried to fallback to driver mode by creating /dev/ipmi0 . but i got the same output even after doing so. The issue seems to have originated from platform type. As platform was not platIntel, it missed to set watchdog and moved to chassis_ctl command and the corresponding output is seen in 3.1.5 log. Is there any reason you could think of, why the particular command...
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
It looks like there is a different in the driver type (openipmi vs. direct): In the 2.79 debug it opens the MV openipmi driver ok: ~~~ipmi_open: driver type = unknown ipmi_open_mv: cannot open /dev/ipmi/0 ipmi_open_mv: succesfully opened /dev/ipmi0, fd=4 ipmi_open rc = 0 type = open Driver type open, open rc = 0 But in the 3.15 debug, it fails to open MV openipmi and falls back to directio. ipmi_open: driver type = ipmi_open_mv: cannot open /dev/ipmi/0 ipmi_open_mv: cannot open /dev/ipmi0 ipmi_open_mv:...
and this change (((bpower >= 5) && (platform == platIntel)) is restricting watchdog to run as part of ipmi_reset()
From deeper inspection, the following function is_romley(vendid,prodid) is returning true, and giving the same hardware a different platform for the same hardware in 3.1.5
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
ipmi_cmd (GET_SEL_ENTRY) returns response with incorrect id.
Sorry for the delay. I just realized that I didn't respond to your latest ipmiutil_evt.log. It includes records from 0122 through 03f5 but doesn't show the 0dff records or beyond (before the SEL was cleared). It looks like we don't have enough evidence to find out what went wrong in this instance. My best guess is that one of the earlier records had a malformed event that caused it to point to 2200.
Sorry for the delay. I just realized that I didn't respond to your latest ipmiutil_evt.log. It includes records from 0122 through 03f5 but doesn't show the 0dff records or beyond (before the SEL was cleared). It looks like we don't have enough evidence to find out what went wrong in this instance.
Noted, with thanks!
getevt exits with return code ( rv = -3)
Apparently this was attributed to the MS IPMI driver issues, and was resolved with the Intel driver.
ipmiutil sensor not working for Huawei or DELL hardware (driver)
ipmiutil sensor not working for Huawei or DELL hardware (driver)