Problem:
We are using more and more hardware that require to patch Debian kernel with non-free firmwares[1]
With Foreman 1.7.5 we were able to identify quickly the kernels that required this patch as they were human distinguable. But now with version 1.22 they are named by their URL source hash[2], it is a bit harder to distinguish the kernels.
I don’t say manual patching is the best way, but it was quick and simple.
Now I have two questions:
- is there any setting to revert back the kernel and initrd name old style ?
- is there a way to automatically patch kernels with foreman ? (it may be a template, but there are so many, I don’t see quite well which one I could tweak).
Thank you for your support
Matthieu
[1] https://wiki.debian.org/DebianInstaller/NetbootFirmware
[2] https://github.com/theforeman/foreman/pull/5244
Let’s start with manual patching: although the name still conains a hash in it, but it is still human readable. We start the file name with medium name as it is defined in Foreman. So basically the name is <medium_name>-<some_hash>. Even more so, the hash is constant length (10 chars). This is the actual code that is responsible for giving the filename.
As a workaround, we can change the Preseed default PXELinux template to work with custom file for supplying the ramdisk file: if you are using a single ramdisk - it’s very easy. All is needed is to change initrd=<%= @initrd %> in the template to point to your custom file instead. In case you are using multiple OS’es, it becomes a bit more complicated, but still doable with the help of parameters. Basically we will need to define a parameter, and set its value for each OS instance to the corresponding patched file. Then we can edit the same Preseed default PXELinux template, but instead of hard coding the filename, we will take its value from the parameter:
initrd=<%= host_param('patched_ramdisk_param') %>
About making the patch process itself automatic in Foreman - it’s doable, bu will require a plugin. If you are into it, we can talk about it a bit more. Ping me here or on IRC/Matrix if you want to go that way.
Hope it helps
Hi Shimon_Shtein,
As time goes, foreman is adding each minor version kernel/initrd into boot/ folder, bringing us with around 60 files from the same medium (since version 6.0 to 9.5, and we have some amd64/x86_64 duplicates).
If we imagine the format <medium_name>-<hash>, it still makes a lot even if the medium name is mentioned. That’s why I find it harder to handle, because we have to build a server to generate its PXE boot file and find which kernel filename it is related to. 
However we will think about a better way to handle our kernels, maybe with templating and a unique recent kernel patched.
A plugin for patching on the fly after media downloading would be great, unfortunately I’m mostly in ops side and my development skills are quite limited. I’ll keep my eyes towards plugins, in case anyone scratchs deeper toward this solution.
Thank you for your answer anyway
As a side note, you can purge the folder, if all the files there are managed by Foreman. The recent ones will be redownloaded each time you put a host in build mode. At least it will make the amount of files a bit more manageable.
What about the suggestion to use custom variable and custom storage for patched files?
Indeed I will have to purge it anyway because foreman doesn’t use them anymore and is downloading/renaming components with hash notation.
However, I have disabled the setting Ignore facts for operating system under Provisionning so foreman stops to download kernels each time puppet reports a new minor version. It should limits the number of kernels.
About the template solution or manually patching kernels in boot, I haven’t discussed with my team yet but I tend for the first solution as it could simplify the resolution.
With the idea to clean up foreman about kernel versions, can I bulk-change the operating system for multiple VMs ? So they use the same kernel in case of rebuilding ?
