Description of problem:
Currently the 92-tuned.install kernel-install plugin provided by the tuned package modifies all BLS snippets that match the KERNEL_INSTALL_MACHINE_ID passed to the script.

This makes sense for the system managed entries but it conflicts with entries that are managed by the boom boot manager: boom will propagate these options if they are present when the entry is set up, but the files should not be modified outside boom's control since this will cause the boom boot identifier to change.

Boom boot entries include the boot_id in the file name pattern:

%{machine_id}-%{boot_id}-%{version}.conf

Compared to the system managed entries which use:

%{machine_id}-%{version}.conf

Modify 92-tuned.install to skip this change for files that match the boom naming convention.

Rather than rely on the presence of '-' (which may appear in some kernel builds, especially custom or debug kernels), use a regular expression to match the 7-character or greater SHA1 hash that appears in boom BLS snippet file names and the remaining structure of the file name.

A paired change is made to the tuned.spec %postun script to apply the same scope to the logic that reverts these changes on removal.

This gives the correct behaviour for me of continuing to add the $tuned_... references to the system managed entries where needed, but without causing unexpected changes to the boom boot entries. The spec file also correctly reverts the change for the same set of entries when %postun is executed.

Version-Release number of selected component (if applicable):
tuned-2.14.0-3.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1. Install the boom package and create a boom boot entry:

# dnf -y install boom-boot
# boom create --title "Tuned Test" --rootlv rhel/root
Created entry with boot_id 389b8de:
  title Tuned Test
  machine-id b49e623f993c4fd7b200c5e350f9cacc
  version 4.18.0-167.el8.x86_64
  linux /vmlinuz-4.18.0-167.el8.x86_64
  initrd /initramfs-4.18.0-167.el8.x86_64.img
  options root=/dev/rhel/root ro rd.lvm.lv=rhel/root rhgb quiet
  grub_users $grub_users
  grub_arg --unrestricted
  grub_class kernel

Note the boot_id (389b8de in this example).

2. Install the tuned package if not already present.
3. Update the kernel package (runs tuned kernel-install plugin)

Actual results:

Running "boom list" shows that the boot_id has changed unexpectedly:
# boom list -o+title
BootID  Version                     Name                     RootDevice            Title                                                             
e664a93 4.18.0-167.el8.x86_64       Red Hat Enterprise Linux /dev/rhel/root        Tuned Test
^^^^^^^                                                        
286b701 4.18.0-147.8.1.el8_1.x86_64 Red Hat Enterprise Linux /dev/mapper/rhel-root Red Hat Enterprise Linux (4.18.0-147.8.1.el8_1.x86_64) 8.1 (Ootpa)


And the boot_id fragment of the entry file name no longer matches the content:

# boom list -obootid,entryfile
BootID  EntryFile                                                          
e664a93 b49e623f993c4fd7b200c5e350f9cacc-389b8de-4.18.0-167.el8.x86_64.conf
^^^^^^^                                  ^^^^^^^
286b701 b49e623f993c4fd7b200c5e350f9cacc-4.18.0-147.8.1.el8_1.x86_64.conf

Inspecting the file content shows that tuned parameters have been added:

# cat /boot/loader/entries/b49e623f993c4fd7b200c5e350f9cacc-389b8de-4.18.0-167.el8.x86_64.conf 
#OsIdentifier: 4abe4f7fd38fc7506cbe2f42b1b85d54af3b29b1
title Tuned Test
machine-id b49e623f993c4fd7b200c5e350f9cacc
version 4.18.0-167.el8.x86_64
linux /vmlinuz-4.18.0-167.el8.x86_64
initrd /initramfs-4.18.0-167.el8.x86_64.img $tuned_initrd
                                            ^^^^^^^^^^^^^
options root=/dev/rhel/root ro rd.lvm.lv=rhel/root rhgb quiet $tuned_params
                                                              ^^^^^^^^^^^^^
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel


Expected results:
Boom managed boot entries are not modified when carrying out a kernel update with the tuned package installed.


Additional info:
Boom is typically used to manage boot entries that correspond to a snapshot of system state and these should not be modified after creation.

A pull request addressing this problem has been submitted and accepted by the upstream tuned project (#307).