8 thoughts on - What Happened If Install A El7 Package On A El6 System

• Many CentOS-7 packages will not install because they will need dependencies that the EL-6 does not have. The kernel is different because it is mostly self-contained and meant to be parallel installed. In most cases, it should result in an unbootable system because the boot is going to be dracut+systemd bits and the EL-6 has none of that.

• At Tue, 7 May 2019 05:50:35 -0400 CentOS mailing list wrote:

  And I wonder if the EL7 kernel will even show up as an available kernel. EL7
  uses Grub 2 and EL6 uses Grub [1]. *Different* config files. Because (unlike Lilo), grub is not updated in the MBR each time its config is updated (eg installing a new kernel), it is very likely the EL7 kernel rpm install might not touch /boot/grub/grub.conf, since it is expecting to update
  /boot/grub/grub.cfg instead.

  I know that when I installed Ubuntu 18.04 as a *second* OS, that even though the /boot file system is shared between CentOS 6 and Ubuntu 18.04 the Ubuntu
  18.04 installer did not touch /boot/grub/grub.conf and installed
  /boot/grub/grub.cfg along side (I manually reinstalled grub 1 and manually hacked /boot/grub/grub.conf to put the Ubuntu 18.04 boot option in).

• +1

  One needs to rebuild (recompile) everything that was not built on
  “mismatched” version of the system. And this will constitute correct
  “installation using old UNIX way”. Otherwise you quite likely will have problems (even if they are hidden, i.e. if it appears to you that “all works”). One of examples would be using some library that is of different version than your extra software was compiled against. The library might be found, and successfully loaded at an execution time, but it may have different subroutine entry names or some missing which may be discovered only under some circumstances. At a compilation time the headers will be what provides necessary information… Anyway, understanding this will tell you apart as a sysadmin from “non-sysadmin”
  person ;-)

  Valeri

• Valeri Galtsev wrote:
  Yup, Valeri’s absolutely correct. I *have* rebuilt drivers (Rocket Raid, for example, doesn’t appear to maintain drivers for cards over about 4 yr old). The biggest problem in mismatches is that someone’s changed a variable name, for whatever reason, and you get “unknown variable”.

  mark

• I found kernel is mismatch accidentally when I using “uname -r” to

  I would say it depends on the dependencies. If its just some userspace tooling then it will probably work ok. Its just x86_64 binaries after all. When you start getting into drivers and system level libraries then your probably gonna have a bad time but even then, the kernel doesn’t change that much. Most of the new kernel stuff is for obscure virtualisation /
  containerisation techniques.

  Of course daemons will be a difficult area as the SystemD stuff might not there but it seems that there is still a lot of packages that ship with init.d scripts.

  I generally found el6 packages to be generally compatable with el7 and vice versa but there is no guarantee that the next update wont horribly break your system. In fact, it probably will :)

  Security was often a second concern to ‘ this system will horribly break if we update it so lets just turn off the internet!’

• Reproduce steps:

  1. Prepare a CentOS 6.3 system on a VM (make sure grubby-7.0.15-3.el6.x86_64 has been installed)
  2. Download kernel-3.10.0-327.el7.x86_64.rpm from http://vault.CentOS.org/
  3.
  3.1 Create a symlink with “ln -s /sbin/new-kernel-pkg /usr/sbin/new-kernel-pkg”
  3.2 Install kernel-3.10.0-327.el7.x86_64.rpm with “rpm -i –force –nodeps”
  4. Reboot

  Then we’ll see the system boot and running as normal. And /etc/grub.conf updated automatically.

• Correct, and different versions of dependencies, and files go in different locations, etc.

  Correct.

  Older versions of dracut will run on newer kernels just fine. When you install the kernel on CentOS 6 it will run the CentOS 6 version of dracut at the time of the install and create a CentOS 6 compatible initramfs image.

  Systemd is user-space and does not include components in the kernel (as far as I’m aware). Even if it does, the kernel is still backwards-compatible and would boot just fine to upstart (which is the init system in CentOS 6), it simply would not use those modules and features that are used for systemd.

  CentOS 7 does have grub legacy (1) as an option and does work fine with grub legacy. I have set up CentOS 7 systems that use grub legacy in the past. It stands to reason that a kernel that installs and configures just fine in grub legacy on CentOS 7 will do the same in grub on CentOS 6.

  This is not the case with CentOS. You can run dual-boot CentOS 6 and 7
  on the same grub legacy boot loader and CentOS 7 will boot up and run just fine.

  While I cannot make any guarantees that a CentOS 7 kernel will not cause issues running in CentOS 6, and indeed I would not support a system that used such, the Linux kernel, being self-contained and largely backwards-compatible should in theory, at least, not have issues running a CentOS 7 kernel on CentOS 6, and indeed there are newer kernels that are specifically built for CentOS 6 (elrepo kernel-ml) that run just fine as well.

  The main thing that might stand in your way would be any changes to the rpm file format (which does happen from time to time) that prevent an rpm built for CentOS 7 from being recognized and installible by rpm or yum in older versions of CentOS 6. I am aware of such changes from older versions of CentOS but none between CentOS 6 and 7.

  So in summary, it would probably work just fine, but I wouldn’t do it, recommend it or support it.

  Peter

• The >> are from me.

  I wasn’t sure if this would work, but since the person has a working system and you have explained why.. I learned something new. Thank you.