0

I am trying to write an ansible playbook to check to see if a particular module is loaded for the current kernel running.

if I do an lsmod | grep my_module_$kernelVer

I would see something like

my_module_2_6_32_754_3_5_el6_x86_64

if I am on the 2.6.32-754.3.5.el6.x86_64 kernel

if I am still on that kernel and said module is

my_module_2_6_32_431_el6_x86_64

I need to rebuild the module for the current kernel that is on the server. I know how to do it in bash but I am not sure how to store a specific value with ansible and the register command and I am just learning ansible.

Thanks for any help provided.

4
  • So, your goal is to discover the version of the kernel, discover the version of the module you have inserted now, and then rebuild the module if they don't match?
    – erik258
    Commented Oct 8, 2019 at 3:30
  • yes that is correct, I only want the job to change something if that current module for that kernel isnt loaded.
    – flugo
    Commented Oct 8, 2019 at 12:18
  • what if an older module is loaded - you're going to unload it ?
    – erik258
    Commented Oct 8, 2019 at 18:29
  • yes, the code I have that rebuilds the module will unload it and rebuild the module for the current kernel since the older module causes the app to not connect back to the console correctly
    – flugo
    Commented Oct 8, 2019 at 20:26

1 Answer 1

0

if I do an lsmod | grep my_module_$kernelVer

Ok, that's the invocation of a shell module. It needs to be a shell because you're using |, and that's a shell construct.

I know how to do it in bash but I am not sure how to store a specific value with ansible and the register command and I am just learning ansible.

You can use the register to capture the results of the command and refer to it later. http://www.mydailytutorials.com/ansible-register-variables/ looks worth reading.

All that having been said, are you really sure you care so much about it matching? Okay, granted, the module not loading may be a big problem for you. But you're testing your kernel upgrades anyway, right? After all, the methodology you define here removes the loaded module to build a new one. I've loaded 3rd party modules in the past that don't even have a kernel version in the name, and frankly I prefer it. I'm not an expert on kernel modules, but keeping kernel versioning and module versions disassociated is worth considering.

3
  • ok I didnt know know I could register an explicit return value in register.
    – flugo
    Commented Oct 9, 2019 at 20:22
  • I guess maybe I really shouldnt care about it matching and just fix the overall issue of correcting the module being loaded for now. I already have the shell script written to fix long term since kernels can come out every month or so and need to patch to those new kernels potentially every month for 3500 servers. Guess this is case of me doing to much, just get the job done and move on.. Thanks for the information Daniel
    – flugo
    Commented Oct 9, 2019 at 20:29
  • I do recognize that just because the module is loaded doesn't mean it works. Similarly just because it's rebuilt against the current running kernel's sources doesn't mean it works. You are the expert in your module and know best whether it needs a rebuild. The best path forward would be to have a solid test for the new kernel including verification of your module before committing to it.
    – erik258
    Commented Oct 10, 2019 at 2:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .