You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
There are several kernel 'variants', e.g. kernel, kernel-hci, kernel-mos, etc. All of these have colliding namespaces, meaning they all have the exact same kernel version and install all their files to the exact same location/filename.
Generally this isn't good, as each variant should differentiate itself with a different version, for example the base variant could use kernel version 5.15.137.1-1.cm2 while the mos variant could use kernel version 5.15.137.1-1.mos.cm2.
Additionally, in order to enforce a higher 'preference' for the custom variants they could have a much higher base release, e.g. if the base kernel is 5.15.137.1-1.cm2 then all the variants could use version 5.15.137.1-1000.$VARIANT.cm2 (e.g. 5.15.137.1-1000.mos.cm2). When using grub2-mkconfig, this would enforce the 'default' kernel was always a custom variant, in case both the base and a custom kernel are installed (e.g. if both kernel and kernel-mos are installed, then grub2-mkconfig would always choose kernel-mos as the default kernel since its version will always be higher than the base kernel version).
Also, using the exact same kernel version for all variants dramatically increases the difficulty in debugging since there's no way to tell what variant any given vmlinuz or kernel module comes from, other than looking at the system's installed rpms (which is not always available, e.g. with a kdump file the kernel version is provided but not the list of installed rpms).
Currently, it's impossible to install any 2 kernel packages with the same version, e.g. the package kernel-5.15.137.1-1.cm2 and kernel-hci-5.15.137.1-1.cm2 cannot both be installed on a system, because all their files collide.
To Reproduce
Steps to reproduce the behavior:
root@test [ ~ ]# tdnf install kernel-5.15.137.1-1.cm2
Loaded plugin: tdnfrepogpgcheck
Package kernel-5.15.137.1-1.cm2 is already installed.
Nothing to do.
root@test [ ~ ]# tdnf install kernel-hci-5.15.137.1-1.cm2
Loaded plugin: tdnfrepogpgcheck
Downgrading:
kernel-hci x86_64 5.15.137.1-1.cm2 mariner-official-base 41.16M 34.87M
Total installed size: 41.16M
Total download size: 34.87M
Is this ok [y/N]: y
kernel-hci 36558994 100%
Testing transaction
Found 1047 problems
file /boot/.vmlinuz-5.15.137.1-1.cm2.hmac from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /boot/System.map-5.15.137.1-1.cm2 from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /boot/config-5.15.137.1-1.cm2 from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /boot/linux-5.15.137.1-1.cm2.cfg from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /boot/vmlinuz-5.15.137.1-1.cm2 from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/.vmlinuz.hmac from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/arch/x86/crypto/crc32c-intel.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/arch/x86/kernel/msr.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/arch/x86/kvm/kvm-amd.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/arch/x86/kvm/kvm-intel.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/arch/x86/kvm/kvm.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
file /lib/modules/5.15.137.1-1.cm2/kernel/block/bfq.ko.xz from install of kernel-hci-5.15.137.1-1.cm2.x86_64 conflicts with file from package kernel-5.15.137.1-1.cm2.x86_64
...
Expected behavior
A clear and concise description of what you expected to happen.
Properly fixing this would be to fully separate each kernel variant's namespaces by using unique kernel versions for each variant.
Without that fix, at minimum all the kernel variants need to have Conflicts: with each other.
The text was updated successfully, but these errors were encountered:
I think this came out of creating kernels intended for very specific image configurations; it was never expected that kernel-hci and kernel would be installed on the same system.
Going forward, now that we support grub2-mkconfig, I agree we should look into separating the namespaces so that multiple configurations can be set up on the same system.
Describe the bug
There are several kernel 'variants', e.g.
kernel
,kernel-hci
,kernel-mos
, etc. All of these have colliding namespaces, meaning they all have the exact same kernel version and install all their files to the exact same location/filename.Generally this isn't good, as each variant should differentiate itself with a different version, for example the base variant could use kernel version
5.15.137.1-1.cm2
while the mos variant could use kernel version5.15.137.1-1.mos.cm2
.Additionally, in order to enforce a higher 'preference' for the custom variants they could have a much higher base release, e.g. if the base kernel is
5.15.137.1-1.cm2
then all the variants could use version5.15.137.1-1000.$VARIANT.cm2
(e.g.5.15.137.1-1000.mos.cm2
). When using grub2-mkconfig, this would enforce the 'default' kernel was always a custom variant, in case both the base and a custom kernel are installed (e.g. if both kernel and kernel-mos are installed, then grub2-mkconfig would always choose kernel-mos as the default kernel since its version will always be higher than the base kernel version).Also, using the exact same kernel version for all variants dramatically increases the difficulty in debugging since there's no way to tell what variant any given vmlinuz or kernel module comes from, other than looking at the system's installed rpms (which is not always available, e.g. with a kdump file the kernel version is provided but not the list of installed rpms).
Currently, it's impossible to install any 2 kernel packages with the same version, e.g. the package
kernel-5.15.137.1-1.cm2
andkernel-hci-5.15.137.1-1.cm2
cannot both be installed on a system, because all their files collide.To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Properly fixing this would be to fully separate each kernel variant's namespaces by using unique kernel versions for each variant.
Without that fix, at minimum all the kernel variants need to have Conflicts: with each other.
The text was updated successfully, but these errors were encountered: