I learned that Kernel live on root,

I check the root directory

[root@iz2ze9wve43n2nyuvmsfx5z /]# ls boot
config-3.10.0-693.2.2.el7.x86_64                         initramfs-3.10.0-693.el7.x86_64.img       System.map-3.10.0-693.el7.x86_64
config-3.10.0-693.el7.x86_64                             initramfs-3.10.0-693.el7.x86_64kdump.img  System.map-3.10.0-862.3.2.el7.x86_64
config-3.10.0-862.3.2.el7.x86_64                         initramfs-3.10.0-862.3.2.el7.x86_64.img   vmlinuz-0-rescue-f0f31005fb5a436d88e3c6cbf54e25aa
efi                                                      initrd-plymouth.img                       vmlinuz-3.10.0-693.2.2.el7.x86_64
grub                                                     symvers-3.10.0-693.2.2.el7.x86_64.gz      vmlinuz-3.10.0-693.el7.x86_64
grub2                                                    symvers-3.10.0-693.el7.x86_64.gz          vmlinuz-3.10.0-862.3.2.el7.x86_64
initramfs-0-rescue-f0f31005fb5a436d88e3c6cbf54e25aa.img  symvers-3.10.0-862.3.2.el7.x86_64.gz
initramfs-3.10.0-693.2.2.el7.x86_64.img                  System.map-3.10.0-693.2.2.el7.x86_64


[root@iz2ze9wve43n2nyuvmsfx5z /]# ls -al | grep -i kernel
[root@iz2ze9wve43n2nyuvmsfx5z /]# 

Which one is the Kernel?

  • vmlinuz-xxx. See your grub.cfg, you'll know. – 炸鱼薯条德里克 Jan 2 '19 at 5:23
  • vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克 – user10726006 Jan 2 '19 at 5:30

vmunix was/is the traditional name of the kernel file in several Unix operating systems.

In Linux, this was changed to vmlinux and then to vmlinuz when kernel file compression was added.

Classically, the kernel file might have lived in the root directory, and on some Linux distributions you might still see a symbolic link at /vmlinuz and /vmlinuz.old pointing to the current and previous kernel version, respectively. But modern bootloaders can easily handle more than two kernel versions, and the convention has evolved to use /boot/vmlinuz-<kernel version number>.

When the disk sizes increased and Logical Block Addressing became the norm on IDE disks (between 1994 and 2003), the BIOSes of pre-1994 systems did not always support LBA and so might be able to access only the first 528 MB or so, until a LBA-aware operating system started running. As a result, it was important to be able to place the files required for the earliest phases of boot-up to a separate small partition that could be guaranteed to be at the very beginning of the disk. In Linux, that resulted in the /boot filesystem convention.

In a nutshell, you'll have the option of creating /boot as a separate filesystem that will only contain the kernel and initrd/initramfs files of the current and any previous fallback kernel versions, and any files the bootloader itself might need (most commonly the /boot/grub directory).

Although all modern systems understand LBA as a matter of course, the /boot filesystem convention lives on, as it can also be used to allow the system to boot even if the root filesystem takes a form that is completely unrecognizable to the system firmware, for example:

  • an encrypted root filesystem,
  • a root filesystem on Linux LVM (easily expandable beyond the limits of any single disk if required, even on-line),
  • a root filesystem on a software RAID0 or RAID5 set (not necessarily great ideas for root filesystem unless you have special requirements)
  • or a root filesystem on a multi-volume ZFS or BtrFS set.

Some system firmwares do include a built-in check that a recognizable, bootable partition exists before attempting to boot from a HDD, even though the actual bootloader might be capable of booting from non-traditional disk layouts.

| improve this answer | |
  • I believe some bootloader can read these storage types and load kernel/initrd from them, in those cases, separate /boot is not needed. – 炸鱼薯条德里克 Jan 2 '19 at 6:30
  • 1
    Yes, some (fairly new) versions can. But the capability to use a /boot filesystem is still there, to allow for e.g. using a hypothetical future (Z+1)fs as a root filesystem even before bootloader support for it is implemented. And when not needed, /boot can become just a regular directory on the root filesystem. Basically, there is no reason to clutter up / with the kernel files on modern systems. – telcoM Jan 2 '19 at 6:40
  • I personnally suggest putting all files on / as a single filesystem, and another seprate filesystem for bootloader, since on modern systems kernel files are managed by package manager, if your root filesystem is broken, the kernel left on another filesystem becomes useless. Also, to make kernel package management work, kernels files on another filesystem needs extra mount. – 炸鱼薯条德里克 Jan 2 '19 at 6:47
  • 1
    If your root filesystem is only slightly broken, the fsck tool included in the initramfs might be able to fix it. If you also include in your initramfs the minimum tools to restore a backup, you can potentially recover from pretty severe root filesystem problems. Kernel package management only requires that the kernel files are in a standard location (i.e. /boot); it does not care whether it's just a directory or a separate mounted filesystem. /etc/fstab will automate the mounting of as many filesystems as you want. But yes, using just a single root filesystem is valid on many cases. – telcoM Jan 2 '19 at 7:08

On CentOS 7, the kernel is located under the /boot directory by default. This location will be specified in the configuration file of the bootloader, GRUB2. The location of the GRUB2 configuration file is /etc/grub2.cfg. This is a symlink to the actual configuration file, whose location varies depending upon firmware used (BIOS/UEFI).

Inside the GRUB2 configuration file, you'll find a 'menuentry' stanza for each kernel your system is configured to boot. Inside each stanza, look for a root variable. An example from my system is the following:

set root='hd0,msdos1'

The above variable specifies the first partition on the first MBR-partitioned disk. On my system, this corresponds to /dev/sda1, which is the mounted as /boot partition.

Continuing inside the same menuentry stanza, you should see a line starting with 'linux16' or 'linuxefi'. Immediately following this keyword is the path to the kernel (relative to the root directory specified earlier). For example:

linux16 /vmlinuz-3.10.0-693.el7.x86_64 ...

On your system, this will be one of the 'vmlinuz-*' files you have seen from the output of ls /boot. These are the kernels currently installed on your system.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.