Installing CentOS7 Boot Loader Into The /boot Partition

Home » CentOS » Installing CentOS7 Boot Loader Into The /boot Partition
CentOS 13 Comments

I did not see any way, during the CentOS7 install, to install the CentOS7 boot loader into the /boot partition rather than to the MBR of a drive. How does one do this in the installation of CentOS7 ?

13 thoughts on - Installing CentOS7 Boot Loader Into The /boot Partition

  • See:
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-disk-partitioning-setup-x86.html and the section about selecting which disk on which to install the bootloader. Specifically, there’s a ‘button’ (looks more like a link in the screenshot) called “Full disk summary and bootloader” on the
    “Installation Destination”**screen, at the bottom. I haven’t tried this yet (but I will soon), but it would seem that by telling it the device on which /boot resides the bootloader will be installed there.

  • The documentation implies that when you tell it what device the bootloader resides on that it will install the bootloader in the MBR of that device. Otherwise how would it know where on that device to install the bootloader ?

    It does say that you may choose not to install a bootloader then another application must boot the system. I use such another application (
    Terabyte’s BIBM ) so I will try that hoping that booting the code at the beginning of the /boot partition will indeed boot CentOS7.

    All other Linux distros I have allow you to choose a /boot partition in which I can install that distro’s boot loader. Then I can direct my own boot loader to boot into that /boot partition for a particular distro after which the distro’s boot menu takes over.

  • Not choosing a bootloader did not work. Without the ability to tell the CedntOS7 installation to install its bootloader in my /boot partition, I
    cannot use CentOS7. For me the CentOS7 developers have really messed up.

  • File a bug with Red Hat’s bugzilla; CentOS just rebuilds that source, and bugs like this must be fixed upstream.

    There is other discussion around the web on this issue for GRUB2 (which is where the issue lies). The core is that GRUB2 is quite a bit larger than GRUB 1, and thus it may or may not be safe to install to a partition. However, you can force it; one such post about doing this is at:
    https://ask.fedoraproject.org/en/question/10666/install-grub2-to-a-partition/

    I’m going to be doing this myself at some point in the near future; I’ll try to remember to fully document what I need to do to make it work.

  • I thought I saw a section in the Release Notes that said Anaconda will no longer install the boot loader in a partition, as the loader has grown big enough that it runs the risk of overwriting other info in the partition. But I could be wrong…

  • The grub2 boot loader is installed in a /boot partition in my Fedora 20
    installation and works properly. But I do create 1 GB boot partitions and maybe most people do not use as much space for their boot partition as I do.

    How hard would it really be for grub2 to check to make sure it has enough space to install itself into a /boot partition ? I am a programmer myself and although I do not know the code/design for the grub2-install command I am sure such a check for /boot partition size cannot be that hard to do.

    I finally saw some posts about how to install grub2 for CentOS7 into a
    /boot partition manually and I will do that. But the Anaconda installer should never have created this headache to begin with no matter what they say. All other Linux distros I have used, such as Suse, Mint, Ubuntu, Mageia etc., give the ability of installing the bootloader into a /boot partition even when defaulting to grub2. There is no excuse for this Anaconda nonsense from Fedora other than programmer egotism.

  • I do not blame CentOS. I think it was some Fedora programmers who perpetrated this nonsense, but maybe it was Red Hat.

    I am a programmer myself. Gee it must be really hard to determine whether enough space exists in a partition to install the GRUB2
    bootloader .

    Yes I now realize what I can do. Thanks !

  • Fedora is not CentOS; upstream’s take would likely be, ‘while it may be good enough for Fedora, this is an Enterprise Linux, not Fedora, and thus we’re not going to support anything this sketchy.’ There are numerous posts on the Ubuntu forums about it; it’s not isolated to CentOS.

    It does do this, and there is an alternate, but not recommended, option
    (which is what the –force does). The actual error from grub-setup:
    grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea. grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE
    and its use is discouraged.

    Anaconda didn’t create the headache; the developers of GRUB2 did by not properly supporting installation to a partition without saying that it is a BAD idea.

    It’s a GRUB2 problem, not an anaconda one, and GRUB2 is a GNU project, not a Fedora one.

    If I were in release engineering for upstream, I wouldn’t allow anaconda to do something that the GRUB2 authors say is a BAD idea; there will be at least one person who will lose data or have an unbootable system by using the feature (the GNU GRUB programmers put the warning message in;
    talk to them about why they did that and what the GNU GRUB2 project plans to do about properly supporting installation in an enterprise-worthy fashion to a partition and not to the MBR).

    And I want to be able to do the bootloader install to a partition myself, but I do understand why it would be supported for the non-Enterprise Fedora but not for the Enterprise version.

  • the stage 1 and 1.5 bootloader aren’t in the file system, they are stored on the reserved first few sectors. its possible core.img in grub2 is too large to store in the partition boot record space, I dunno how big that is.

  • Programming is about calculations as well as logic. It cannot be impossible to calculate how big core.img is, how much space is in the partition in which grub2 is installed and either tell the end-user it can or cannot be done. Things like “it’s bad to install grub2 into a partition” mean nothing in the computer programming world. The first rule of programming: the bit is on or it is off.

  • What the error message is saying is that ‘we know the bootloader is too big to fit in the partition’s boot sector, so we hide it with blocklists, but they’re unreliable (filesystem utilities could potentially overwrite them), and so that makes it a bad idea.’ The
    –force parameter is the user telling grub-setup ‘I know you know it’s too big and will use blocklists and they’re unreliable but I don’t care:
    use them anyway!’ The bootloader has a significant amount of code that is not inside the filesystem and either must ‘hide’ in the partition’s boot sector or be hidden by ‘lying’ about the sectors that the bootloader is using (the blocklist method).

    The programmers at the GNU GRUB project have determined that it is not reliably supportable to put GRUB2 on a partition, rather than putting it in the MBR (a whole different ball of wax is EFI boot support…..).
    Correcting this is something that the GRUB project people will have to properly fix (and it’s probably not easy to do, or they would have already done it). The Fedora project supports it, at least as far as Fedora *supports* anything (that is, if it breaks, you keep the pieces)
    whereas an Enterprise distribution with paying customers can’t reasonably do that, since if it breaks they have to support fixing it.
    That’s what the service contract buys, after all.

    The CentOS project rebuilds that Enterprise linux distribution verbatim, as so won’t support it either, until the upstream supports it.

    But if you want to do it manually, you can. And I will be trying this, but on a bit of an oddball system, not your run-of-the-mill BIOS-boot-to-MBR systems.

  • I can only say that I have always used a dedicated /boot partition for a Linux distro, I have never had a Linux distro have access to a /boot partition in a different Linux distro, and the only thing I have ever manually done with a /boot partition is back it up somewhere offline. What problems this straighforward use of the /boot partition, and installing the bootloader on it, can entail in this sort of scenario, which must be pretty common, I cannot guess. I do understand that CentOS7, as an Enterprise Linux distro, may want to limit an installation of grub2 from being installed on a separate /boot partition but at the same time the assumption being made is that CentOS7 should now controlling bootup of a computer. I think thsi needs to be documented.

    I did manage to install grub2 in my CentOS7 /boot partition, and everything seems to be alright. The only negative effect is that CentOS7
    changed my BIOS time incorrectly. But that has been fixed.