On 10/06/2021 15:00, Ryan Novosielski wrote:>
The problem with not version locking the kernel, however, is that you really need to know that the kernel you are going to is going to support the GPFS version that you are going to be running. Typically that only becomes a problem when you cross a minor release boundary on RHEL-derivatives, but I think not always. But I suppose you can just try this on something first just to make sure, or handle it at the repository level, or something else.
Well *everything* comes from a local repo mirror for all the GPFS nodes so I can control what goes in and when. I use a VM for building the gpfs.gplbin in advance and then test it on a single node before the main roll out.
I would note that I read the actual release notes and then make a judgment on whether the kernel update actually makes it to my local mirror. It could be a just a bug fix, or the security issue might for example be in a driver which is not relevant to the platform I am managing. WiFi and Bluetooth drivers are examples from the past.
The issue I found is you do a "yum update" and new kernel gets pulled in, and/or a new GPFS version. However the matching gpfs.gplbin is now missing and I wanted an automated process of insuring the right version of gpfs.gplbin is installed for whatever kernel happens to be running. Noting that this could also be at install time, which partly why I went with the gpfs.helper RPM.
JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
