[gpfsug-discuss] GPFS systemd and gpfs.gplbin

Jonathan Buzzard jonathan.buzzard at strath.ac.uk
Thu Jun 10 19:08:47 BST 2021


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



More information about the gpfsug-discuss mailing list