** 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. + ipmitool is incorrectly parsing the timestamp of event fields, showing + two dates instead of a date and a time. It's important to get the + correct timestamp of events, and the current situation limits this + information to purely a day, instead of a proper timestamp. + [ 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. + The test plan involves getting an event and checking if the timestamp + contains a date and a time, instead of just a date shown twice. There + are several ways to do this, but they all need a working BMC listening + to IPMI commands. + + For the test plan, we will deploy 24.04 on a bare metal machine which + has a BMC that ipmitool can query via localhost, without credentials. + And then for the testing, use a LXD container for each ubuntu release + under test, and run ipmitool inside that LXC. + + Here are the steps. + + # Deploy ubuntu 24.04 on a bare metal machine with a working BMC + + # setup LXD + sudo lxd init --auto + + # For each ubuntu release under test, run the following commands. Here + we will show it for noble, but iterate using oracular and plucky: + + lxc launch ubuntu-daily:$release $release-test + + # this will passthrough the IPMI device from the host to the container + lxc config set device add $release-test ipmi unix-char path=/dev/ipmi0 + + # enter the container to run the ipmitool command that will show the bug + lxc exec $release-test -- bash -c "apt update; apt install ipmitool -y" + lxc exec $release-test -- ipmitool sel get 1 + + # With the bug, the output of the ipmitool command above will show a + timestamp like: + + Timestamp : 02/25/12 02/25/12 + + # With the fix, that timestamp will include a time: + + Timestamp : 02/25/12 00:41:13 UTC + [ 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. + * 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 - + * 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 : 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 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 authcode output (16 bytes) 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 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> 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
