Fail to find the Kernel in root directory












0














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


and



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


Which one is the Kernel?










share|improve this question






















  • vmlinuz-xxx. See your grub.cfg, you'll know.
    – 炸鱼薯条德里克
    1 hour ago










  • vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
    – user10726006
    1 hour ago
















0














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


and



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


Which one is the Kernel?










share|improve this question






















  • vmlinuz-xxx. See your grub.cfg, you'll know.
    – 炸鱼薯条德里克
    1 hour ago










  • vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
    – user10726006
    1 hour ago














0












0








0







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


and



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


Which one is the Kernel?










share|improve this question













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


and



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


Which one is the Kernel?







centos






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 1 hour ago









user10726006

234




234












  • vmlinuz-xxx. See your grub.cfg, you'll know.
    – 炸鱼薯条德里克
    1 hour ago










  • vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
    – user10726006
    1 hour ago


















  • vmlinuz-xxx. See your grub.cfg, you'll know.
    – 炸鱼薯条德里克
    1 hour ago










  • vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
    – user10726006
    1 hour ago
















vmlinuz-xxx. See your grub.cfg, you'll know.
– 炸鱼薯条德里克
1 hour ago




vmlinuz-xxx. See your grub.cfg, you'll know.
– 炸鱼薯条德里克
1 hour ago












vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
– user10726006
1 hour ago




vmlinuz-3.10.0-693.2.2.el7.x86_64 is the kernel? @炸鱼薯条德里克
– user10726006
1 hour ago










2 Answers
2






active

oldest

votes


















2














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.






share|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.
    – 炸鱼薯条德里克
    40 mins ago










  • 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
    30 mins ago










  • 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.
    – 炸鱼薯条德里克
    23 mins ago












  • 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
    2 mins ago



















0














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.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491966%2ffail-to-find-the-kernel-in-root-directory%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    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.






    share|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.
      – 炸鱼薯条德里克
      40 mins ago










    • 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
      30 mins ago










    • 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.
      – 炸鱼薯条德里克
      23 mins ago












    • 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
      2 mins ago
















    2














    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.






    share|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.
      – 炸鱼薯条德里克
      40 mins ago










    • 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
      30 mins ago










    • 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.
      – 炸鱼薯条德里克
      23 mins ago












    • 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
      2 mins ago














    2












    2








    2






    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 48 mins ago









    telcoM

    15.8k12143




    15.8k12143












    • I believe some bootloader can read these storage types and load kernel/initrd from them, in those cases, separate /boot is not needed.
      – 炸鱼薯条德里克
      40 mins ago










    • 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
      30 mins ago










    • 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.
      – 炸鱼薯条德里克
      23 mins ago












    • 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
      2 mins ago


















    • I believe some bootloader can read these storage types and load kernel/initrd from them, in those cases, separate /boot is not needed.
      – 炸鱼薯条德里克
      40 mins ago










    • 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
      30 mins ago










    • 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.
      – 炸鱼薯条德里克
      23 mins ago












    • 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
      2 mins ago
















    I believe some bootloader can read these storage types and load kernel/initrd from them, in those cases, separate /boot is not needed.
    – 炸鱼薯条德里克
    40 mins ago




    I believe some bootloader can read these storage types and load kernel/initrd from them, in those cases, separate /boot is not needed.
    – 炸鱼薯条德里克
    40 mins ago












    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
    30 mins ago




    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
    30 mins ago












    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.
    – 炸鱼薯条德里克
    23 mins ago






    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.
    – 炸鱼薯条德里克
    23 mins ago














    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
    2 mins ago




    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
    2 mins ago













    0














    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.






    share|improve this answer


























      0














      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.






      share|improve this answer
























        0












        0








        0






        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 48 mins ago









        Haxiel

        1,199310




        1,199310






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491966%2ffail-to-find-the-kernel-in-root-directory%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Quarter-circle Tiles

            build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

            Mont Emei