[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