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 <ch...@llnl.gov> Gesendet: Freitag, 12. Mai 2023 15:18 An: FRANK Michael <michael.fr...@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 <ch...@llnl.gov> > Gesendet: Montag, 8. Mai 2023 16:25 > An: FRANK Michael <michael.fr...@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 <ch...@llnl.gov> >> Gesendet: Dienstag, 25. April 2023 17:42 >> An: FRANK Michael <michael.fr...@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 <ch...@llnl.gov> >>> Gesendet: Montag, 19. Juli 2021 19:11 >>> An: FRANK Michael <michael.fr...@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.fr...@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 _______________________________________________ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
