[gpfsug-discuss] kernel updates and GPFS modules: manual, DKMS, cron, other?

Marcy.D.Cortes at wellsfargo.com Marcy.D.Cortes at wellsfargo.com
Fri Mar 3 21:10:02 GMT 2023

We build the rpm and it gets installed if needed in a systemd script that puts it on and then restarts GPFS.  Apps are dependent on a health check startup script. To use that auto build you have to have a compiler installed and we avoid that on production servers

From: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org<mailto:gpfsug-discuss-bounces at gpfsug.org>> on behalf of: David Magda <dmagda+gpfs at ee.torontomu.ca<mailto:dmagda+gpfs at ee.torontomu.ca>>
Date: Friday, Mar 03, 2023 at 2:32 PM
To: gpfsug-discuss at gpfsug.org <gpfsug-discuss at gpfsug.org<mailto:gpfsug-discuss at gpfsug.org>>
Subject: [gpfsug-discuss] kernel updates and GPFS modules: manual, DKMS, cron, other?


I am a new user of GPFS (Spectrum Scale) and would like to know if there is a ‘best practice’ on handling kernel updates on HPC clients. We are running Ubuntu 18.04 and 20.04 clients with 5.1.x, talking to RHEL storage servers, and would like to know how to handle re-compiling the client-side kernel modules.

There is of course the “mmbuildgpl” utility:


but how do folks invoke it? Manually, via cron at night on or reboot, via some kind of apt (dpkg-trigger(1)) / RPM hook?

We have the “unattended-upgrades” package enabled, which only installs security-tagged updates by default, but sometimes this does include kernel updates, which may become active on the next reboot:


So is there a best practice? Has someone invented this wheel that I could leverage, or will I have to invent it myself?

Thanks for any info.

David Magda
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20230303/3963b05a/attachment-0002.htm>

More information about the gpfsug-discuss mailing list