INTERNAL & PARTNERS
Hello Al,
Thank you for taking care. We are not. Next year we migrate from CentOS7 to
something like Rocky and it would be nice to have it fixed but we can live with
the workaround I think.
Wouldn’t it be possible to use something unique like the serial number of the
server? This should be available via the FRU info´s.
Have a nice WE
Michael
-----Ursprüngliche Nachricht-----
Von: Al Chu11 <chu11@llnl.gov>
Gesendet: Freitag, 12. Mai 2023 15:18
An: FRANK Michael <michael.frank@forvia.com>; 'freeipmi-users@gnu.org'
<freeipmi-users@gnu.org>
Betreff: Re: AW: AW: AW: [Freeipmi-users] SDR cache not updated
- External - This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi Michael,
I guess best option for us is to delete all cache files by a cron job once a
day. Do you see any issue with that?
I think that's a workable solution.
Looking at the info below, this is quite unfortunate. Despite moving to
another vendor's motherboard, both elected to not initialize any of the
timestamps. That's why FreeIPMI assumed nothing had changed.
I think one additional test I could add is if the number of records has
changed, but that's tricky because some vendors don't store the correct number
of records in the SDR info. Although I could perhaps just check the number of
records that SDR info returns only.
Lemme think about doing that.
Al
On 5/12/23 00:03, FRANK Michael wrote:
INTERNAL & PARTNERS
Hello Al,
I guess best option for us is to delete all cache files by a cron job once a
day. Do you see any issue with that?
Here are the SDR info:
X3650 M5:
SDR version : 1.5
SDR record count : 327
Free space remaining : 19333 bytes
Most recent addition timestamp : Post-Init 0 s
Most recent erase timestamp : Post-Init 0 s
Get SDR Repository Allocation Information Command : supported
Reserve SDR Repository Command : supported
Partial Add SDR Command : supported
Delete SDR Command : supported
Modal/non-modal SDR Repository Update operation : non-Modal supported
SDR could not be written due to lack of space : No
Number of possible allocation units : 2044
Allocation unit size : 16 bytes
Number of free allocation units : 1208
Largest free block : 1208 allocation units
Maximum record size : 4 allocation units
SR650:
SDR version : 1.5
SDR record count : 291
Free space remaining : 48755 bytes
Most recent addition timestamp : Post-Init 0 s
Most recent erase timestamp : Post-Init 0 s
Get SDR Repository Allocation Information Command : supported
Reserve SDR Repository Command : supported
Partial Add SDR Command : supported
Delete SDR Command : supported
Modal/non-modal SDR Repository Update operation : non-Modal supported
SDR could not be written due to lack of space : No
Number of possible allocation units : 3836
Allocation unit size : 16 bytes
Number of free allocation units : 3047
Largest free block : 3047 allocation units
Maximum record size : 4 allocation units
Thanks
Michael
-----Ursprüngliche Nachricht-----
Von: Al Chu11 <chu11@llnl.gov>
Gesendet: Montag, 8. Mai 2023 16:25
An: FRANK Michael <michael.frank@forvia.com>; 'freeipmi-users@gnu.org'
<freeipmi-users@gnu.org>
Betreff: Re: AW: AW: [Freeipmi-users] SDR cache not updated
- External - This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi Michael,
The cache files aren't too interesting, what would be more interesting is the
SDR info for each of the motherboards, which you can get via `ipmi-sensors -i`.
Al
On 5/8/23 00:45, FRANK Michael wrote:
INTERNAL & PARTNERS
Hello Al,
Sorry for the delay.
We swapped from a Lenovo x3650 M5 to a Lenovo SR650. So, same Vendor but
different model.
I can share the old and new cache files if it helps
Regards
Michael
-----Ursprüngliche Nachricht-----
Von: Al Chu11 <chu11@llnl.gov>
Gesendet: Dienstag, 25. April 2023 17:42
An: FRANK Michael <michael.frank@forvia.com>; 'freeipmi-users@gnu.org'
<freeipmi-users@gnu.org>
Betreff: Re: AW: [Freeipmi-users] SDR cache not updated
- External - This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi Michael,
Was the hardware that you swapped in a different vendor or similar hardware
from before? I'm assuming you mean the former.
I suppose similar to my previous answer, if the timestamps/version numbers of
the new hardware happen to not indicate that the sdr firmware is newer,
--sdr-cache-recreate decided that the firmware was not new
enough and didn't recreate it. This might just be bad luck at the
version number and timestamps from the new hardware happen to be <= to the
former hardware's timestamps and version number.
I suppose some extra checks could be done, perhaps to see if the number of
records is different or manufacturer is different. That's something we could
add.
IMO, what might be a good option is to run --flush-cache once in awhile,
perhaps once a day or once a week to ensure that you get a fresh copy of the
cache regularly, especially when hardware is changed.
Al
On 4/25/23 08:08, FRANK Michael wrote:
INTERNAL & PARTNERS
Hello Al,
Thank you so much for all your work and support you spend on freeipmi.
We are using freeipmi 1.5.7 on Centos7 and having an ongoing issue that cache
is not updated.
Recently we changed the Hardware of a server and reused the IP address.
Even that we use ipmi-sensors with the option --sdr-cache-recreate the cache
file is not updated and we received wrong data for this hardware.
The cache file was very old:
-rw-r--r-- 1 GLD GLD 8035 Jun 19 2020
sdr-cache-usgldmon0242.10.131.132.20
Finally option --flush-cache fixed and new cache was built (guess
deleting the cache file is doing the same job)
Is this a know issue in freeipmi 1.5.7 which is maybe fixed in a later version?
If yes please share the version with me.
Best regards
Michael
-----Ursprüngliche Nachricht-----
Von: Al Chu <chu11@llnl.gov>
Gesendet: Montag, 19. Juli 2021 19:11
An: FRANK Michael <michael.frank@faurecia.com>;
'freeipmi-users@gnu.org' <freeipmi-users@gnu.org>
Betreff: Re: [Freeipmi-users] SDR cache not updated
Hi Michael,
So a subtlety of --sdr-cache-recreate is that it will only update your SDR
cache if its out of date. My suspicion, is that your hardware SDR / firmware
was updated, but the vendor did not update the SDR timestamps, thus FreeIPMI
did not believe the SDR was out of date.
(You can see these timestamps via ipmi-sensors -i).
Unfortunately the solution is to simply flush the sdr cache
(--flush-
cache) and force its recreation. The interval you want to do this is sort of
up to you.
Perhaps you could script to check if the firmware version has changed and only
force the --flush-cache when necessary? You can see this via bmc-info, but
this of course assumes the vendor bothered to update the firmware revision
number.
Al
On Mon, 2021-07-19 at 16:23 +0000, FRANK Michael wrote:
Hello,
we use ipmi-sensors with the option --sdr-cache-recreate In a
script which is scheduled every minute for monitoring purpose.
On one of our sites we had a lot of false positive events on two
servers ( see attached logs).
Finally, I found out that the SDR cache file was already 3 years old.
After flushing the cache all sensors went back to normal. The only
thing was that 11 sensors left had been discovered.
My question is now how this option --sdr-cache-recreate is working
and what can I do to let ipmi-sensors automatically refresh the
cache file in case something changes on the remote end.
I am worried about what happen if new FRUs are added. If the cache
file is not updated with new sensors, we miss the monitoring of
newly added things,
Any help is much appreciated
Michael FRANK
Supervisor Global Monitoring Architecture Faurecia Clean Mobility T
+49 821 4103 420 ● M +49 171 9967 206 michael.frank@faurecia.com
Faurecia Emissions Control Technologies, Germany GmbH -
Biberbachstraße 9 – 86154 Augsburg – Germany
Sitz der Gesellschaft: Augsburg - Registergericht Augsburg HR B
20757
Geschäftsführer: Yves Andres, Silke Krome, Soeren Peters
Vorsitzender des Aufsichtsrats: Mathias Miedreich
This electronic transmission (and any attachments thereto) is
intended solely for the use of the addressee(s). It may contain
confidential or legally privileged information. If you are not the
intended recipient of this message, you must delete it immediately and notify
the sender.
Any unauthorized use or disclosure of this message is strictly
prohibited. Faurecia does not guarantee the integrity of this
transmission and shall therefore never be liable if the message is
altered or falsified nor for any virus, interception or damage to
your system.
WARNING: This email violated LLNL's email security policy and has
been modified. If you would like a list of blocked file types or
for more information please see:
Blocked Email Extensions
An attachment free_ipmi.tgz was removed from this document as it
constituted a security hazard. If you require this document, please
contact the sender and arrange an alternate means of receiving it.
_______________________________________________
Freeipmi-users mailing list
Freeipmi-users@gnu.org
https://urldefense.us/v
3/__https://urldefense.us/v3/__https://lists.gnu.org/mailman/listin
f
o
/freeipmi-users__;!!G2kpM7uM__;!!G2kpM7uM-TzIFchu!wz1d6KpWKo4Q6NW5v
f
1
IIP5DC_8l2o_pdQpAmM9yFodOJrSmBMpMRy-9Z0HrhBkh5O0E57iQLNV2ndGmoC0k8v
U
U
$
-TzIFchu!il28AShgA_3e9-3O1mjJ4yThSSwsvyMoJVEk2MSSwbbIScwcrBqEUkGgpK
0
H
S
XOh$
5acXjzUk
--
Albert Chu
Livermore Computing
Lawrence Livermore National Laboratory
5acXjzUk
--
Albert Chu
Livermore Computing
Lawrence Livermore National Laboratory
5acXjzUk
--
Albert Chu
Livermore Computing
Lawrence Livermore National Laboratory
5acXjzUk