** Description changed: + [ Impact ] + + * An explanation of the effects of the bug on users and justification + for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. + + [ Test Plan ] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package + fixes the problem. + + * if other testing is appropriate to perform before landing this + update, this should also be described here. + + [ Where problems could occur ] + + * Think about what the upload changes in the software. Imagine the + change is wrong or breaks something else: how would this show up? + + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the event + of a regression. + + * This must never be "None" or "Low", or entirely an argument as to why + your upload is low risk. + + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. + + [ Other Info ] + + * Anything else you think is useful to include + + * Make sure to explain any deviation from the norm, to save the SRU + reviewer from having to infer your reasoning, possibly incorrectly. + This should also help reduce review iterations, particularly when the + reason for the deviation is not obvious. + + * Anticipate questions from users, SRU, +1 maintenance, security teams + and the Technical Board and address these questions in advance + + + [ Original Description ] + Hello, when running impitool sel get <event id>, the timestamp information is showing twice the date, but not the hour fr3d@safact:~/gbtipmitool/run$ ipmitool -I lanplus -U admin -P <password> -H 10.197.177.97 sel get 0x28a SEL Record ID : 028a - Record Type : 02 - Timestamp : 04/16/2025 04/16/2025 - Generator ID : 0020 - EvM Revision : 04 - Sensor Type : Unknown - Sensor Number : 00 - Event Type : Sensor-specific Discrete - Event Direction : Assertion Event - Event Data : 030000 - Description : - + Record Type : 02 + Timestamp : 04/16/2025 04/16/2025 + Generator ID : 0020 + EvM Revision : 04 + Sensor Type : Unknown + Sensor Number : 00 + Event Type : Sensor-specific Discrete + Event Direction : Assertion Event + Event Data : 030000 + Description : Using ipmi-sel / free-ipmi, the hour is reported in the nice way fr3d@safact:~/gbtipmitool/run$ ipmi-sel -h 10.197.177.97 -u admin -p <password> --display=650 ID | Date | Time | Name | Type | Event 650 | Apr-16-2025 | 23:58:03 | Sensor #0 | OEM Reserved | Event Offset = 03h (note: this is the same event 0x28a = 650) - Still using free-ipmi, in debug mode we can see the 32b timetsamp: 10.197.177.97: [ 19h] = checksum2[ 8b] 10.197.177.97: ===================================================== 10.197.177.97: SEL Event Record 10.197.177.97: ===================================================== 10.197.177.97: [ 28Ah] = record_id[16b] 10.197.177.97: [ 2h] = record_type[ 8b] 10.197.177.97: [ 6800440Bh] = timestamp[32b] 10.197.177.97: [ 0h] = generator_id.id_type[ 1b] 10.197.177.97: [ 10h] = generator_id.id[ 7b] 10.197.177.97: [ 0h] = ipmb_device_lun[ 2b] 10.197.177.97: [ 0h] = reserved[ 2b] 10.197.177.97: [ 0h] = channel_number[ 4b] 10.197.177.97: [ 4h] = event_message_format_version[ 8b] 10.197.177.97: [ C3h] = sensor_type[ 8b] 10.197.177.97: [ 0h] = sensor_number[ 8b] 10.197.177.97: [ 6Fh] = event_type_code[ 7b] 10.197.177.97: [ 0h] = event_dir[ 1b] 10.197.177.97: [ 3h] = offset_from_event_reading_type_code[ 4b] 10.197.177.97: [ 0h] = event_data3_flag[ 2b] 10.197.177.97: [ 0h] = event_data2_flag[ 2b] 10.197.177.97: [ 0h] = event_data2[ 8b] 10.197.177.97: [ 0h] = event_data3[ 8b] 10.197.177.97: ===================================================== 10.197.177.97: IPMI 1.5 Reserve SEL Request 10.197.177.97: ===================================================== 10.197.177.97: RMCP Header: - - Then, using ipmitool with -vvv flag, we can see the righttime stamp has been reported by the BMC Looking up SEL entry 0x28a >> Sending IPMI command payload >> netfn : 0x0a >> command : 0x43 >> data : 0x00 0x00 0x8a 0x02 0x00 0xff BUILDING A v2 COMMAND Local RqAddr 0x20 transit 0:0 target 0x20:0 bridgePossible 1 >> Initialization vector (16 bytes) - 9a 01 24 2a 62 43 84 3b ae 2d 64 04 34 71 32 74 + 9a 01 24 2a 62 43 84 3b ae 2d 64 04 34 71 32 74 authcode input (48 bytes) - 06 c0 80 0e 5e 9d 0c 00 00 00 20 00 9a 01 24 2a - 62 43 84 3b ae 2d 64 04 34 71 32 74 5c ee 34 ac - 0e f8 83 ca 27 56 99 07 72 21 83 f1 ff ff 02 07 + 06 c0 80 0e 5e 9d 0c 00 00 00 20 00 9a 01 24 2a + 62 43 84 3b ae 2d 64 04 34 71 32 74 5c ee 34 ac + 0e f8 83 ca 27 56 99 07 72 21 83 f1 ff ff 02 07 authcode output (16 bytes) - 2a b7 99 68 b5 d5 e4 31 c0 3b a0 87 a1 10 48 b4 + 2a b7 99 68 b5 d5 e4 31 c0 3b a0 87 a1 10 48 b4 << IPMI Response Session Header << Authtype : RMCP+ << Payload type : IPMI (0) << Session ID : 0xa0a2a3a4 << Sequence : 0x00000006 << IPMI Msg/Payload Length : 48 << IPMI Response Message Header << Rq Addr : 81 << NetFn : 0b << Rq LUN : 0 << Rs Addr : 20 << Rq Seq : 0a << Rs Lun : 0 << Command : 43 << Compl Code : 0x00 SEL Entry: 8a02020b440068200004c3006f030000 => in the SEL Entry, the timestamp is "0b440068" (=> 0x6800440b as it is a 32b integer) - So the issue is not related to IPMI data (both free-ipmi and ipmitool got the right timestamp) but it seems to be a display issue in ipmitool - Note: in an old stackoverflow thread, we can see ipmitool output with Hour in the event timestamp https://stackoverflow.com/questions/9265148/ipmitool-sel-command-on-per610-does-not-provide-detailed-information machine:/ # ipmitool sel get 0x2c SEL Record ID : 002c - Record Type : 02 - Timestamp : 02/13/2012 17:49:21 - Generator ID : 0021 - EvM Revision : 04 - Sensor Type : Voltage - Sensor Number : 60 - Event Type : Threshold - Event Direction : Assertion Event - Event Data : 02ffff - Description : Lower Critical going low - + Record Type : 02 + Timestamp : 02/13/2012 17:49:21 + Generator ID : 0021 + EvM Revision : 04 + Sensor Type : Voltage + Sensor Number : 60 + Event Type : Threshold + Event Direction : Assertion Event + Event Data : 02ffff + Description : Lower Critical going low Thanks -- Fred ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: ipmitool 1.8.19-7ubuntu0.24.04.1 ProcVersionSignature: Ubuntu 6.8.0-57.59-generic 6.8.12 Uname: Linux 6.8.0-57-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Thu Apr 17 09:36:35 2025 InstallationDate: Installed on 2022-04-26 (1087 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) ProcEnviron: - LANG=en_US.UTF-8 - PATH=(custom, no user) - SHELL=/bin/bash - TERM=xterm - XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + PATH=(custom, no user) + SHELL=/bin/bash + TERM=xterm + XDG_RUNTIME_DIR=<set> SourcePackage: ipmitool UpgradeStatus: Upgraded to noble on 2024-10-23 (176 days ago)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2107550 Title: ipmitool sel get is not showing hour in the timestamp details To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/2107550/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
