I've seen some people make a separate partition for /boot. What is the benefit of doing this? What problems might I encounter in the future by doing this?

Also, except for /home and /boot, which partitions can be separated? Is it recommended?

  • 1
    My Ubuntu 8.04 came from Dell with a /boot partition. It wasn't my choice. When I installed 10.04 fresh, it didn't try to create one. – David Thornley Aug 11 '10 at 12:28
  • When I tried to install Arch Linux for the first time, this was highly recommended, and it even failed to install the first time I didn't do this. Never had problemes in other distros, though. – horsedrowner Aug 11 '10 at 12:55
  • See also a question on separate partitions generally and questions specific to /tmp and /var – sondra.kinsey Apr 10 '19 at 21:10

10 Answers 10


This is a holdover from "ye olde tymes" when machines had trouble addressing large hard drives. The idea behind the /boot partition was to make the partition always accessible to any machine that the drive was plugged into. If the machine could get to the start of the drive (lower cylinder numbers) then it could bootstrap the system; from there the linux kernel would be able to bypass the BIOS boot restriction and work around the problem. As modern machines have lifted that restriction, there is no longer a fixed need for /boot to be separate, unless you require additional processing of the other partitions, such as encryption or file systems that are not natively recognized by the bootloader.

Technically, you can get away with a single partition and be just fine, provided that you are not using really really old hardware (pre-1998 or so).

If you do decide to use a separate partition, just be sure to give it adequate room, say 200mb of space. That will be more than enough for several kernel upgrades (which consume several megs each time). If /boot starts to fill up, remove older kernels that you don't use and adjust your bootloader to recognize this fact.

| improve this answer | |
  • 3
    Regarding the size, "for Fedora 13 the default /boot partition size was increased to 500 MiB to avoid these problems in the future". (from fedoraproject.org/wiki/…) – Cristian Ciupitu Aug 29 '10 at 1:28
  • 4
    500M ? wtf are they storing in there? I have never needed even 100M I'm using 13M on /boot right now. – xenoterracide Sep 2 '10 at 20:51
  • 29
    There are still lots of modern reasons for having a /boot partition, and they all boil down to "The boot loader can't read the root filesystem". The historic use-case is, as you said, drives too large, but the modern cases are encryption, new filesystems (such as ext4), LVM, or any esoteric setup that is simply not supported by GRUB. – Mr. Shiny and New 安宇 Sep 3 '10 at 12:33
  • 23
    Did anyone mention that in dual-boot situations, if Linux system is installed after Windows, GRUB provides boot lines for side-by-side systems. If /boot were not on the separate partition, a deletion of the Linux partition would have made the machine unbootable. If /boot were on the separate partition, deletion of the Linux installation (say, root partition) won't have harmed ability to boot the side-system. – mbaitoff Jul 4 '11 at 8:24
  • 5
    I have had my 100MB /boot partition overfill with outdated kernels. This is very messy when that happens. – Malfist Jul 11 '11 at 14:44

One reason for having a /boot partition is that it allows for things like encrypted /, where the kernel and initrd are loaded from an unencrypted partition and then used to mount the encrypted root partition containing the operating system. It shouldn't matter for general usage however.

Adding a comment from Riccardo Murri:

There are also historical reasons for having a separate /boot: in older times, the BIOS could only access part of a large disk, so all files needed by the OS bootloader had to be kept in the BIOS-accessible zone. Hence a separate /boot partition. This does no longer apply, though

| improve this answer | |
  • 1
    well... iirc the bootloader can only access primary partitions still... so it can be useful if you've quite a few extended partitions. – xenoterracide Aug 12 '10 at 1:07

The main reason for the major enterprisey distro's like Red Hat and I think Suse to use a separate /boot is that they use LVM by default and Grub cannot be used to boot from LVM. It is that simple.

So if you want to use LVM, and that is a boon, you use a separate /boot. Personally, I think it is good practice to use both LVM and separate partitions for a host of things, like /var, /boot, /home and /tmp and even /usr on servers, for example in order to protect your root filesystem or data partitions from getting full.

| improve this answer | |
  • 3
    Another good reason was that GRUB didn't support ext4, only ext3, so if you wanted to use ext4 for / you had to have a separate /boot partition. – Cristian Ciupitu Aug 29 '10 at 1:15
  • 1
    Several people have implied that GRUB would not be able to boot from LVM. GRUB2 is booting happily from LVM2 without any problem on my home PC for about 1.5 years now. Sweetest thing since sliced bread. Oh, and that is supported by default by the ubiquity (alternative) installer. Try it – sehe Mar 22 '11 at 0:08
  • 1
    As for /tmp/, you can mount memory with tmpfs there nowadays. It might be faster, and also healthier for your harddrives. In any case, /tmp/ is not supposed to survive reboots. – imz -- Ivan Zakharyaschev Mar 22 '11 at 7:17
  • 2
    Grub legacy does not, and Grub 2 did not work if /boot was mounted on a LVM logical colume. Support was added fairly recently. It should not be difficult to dig up the particular reference. Ditto for software RAID, support for that has also been added recently to Grub 2. – Faheem Mitha Mar 22 '11 at 17:27
  • 1
    I asked on #grub when LVM support was added to Grub 2, and Colin Watson replied "October 2006", and added "(that isn't to say that it would have worked for everyone at that point; for example, GRUB only learned how to skip LVM snapshots in July 2010)". I guess that my perception was influenced by trying to get a Grub2 + LVM setup working in Jan 2011, and Grub2 was broken for me. I finally settled on 1.99~20110112-1 (Debian) as the first version that worked for me. As Colin commented, "something not working doesn't mean that there's no code to support it". – Faheem Mitha Mar 23 '11 at 15:55

One final reason, less important than those given, is it can allow the PC to remain bootable if part of the disk is corrupted. The more partitions you have, the easier it will be to simply not mount the partition with the fault.

This can be useful sometimes, but usually there's a better way anyway.

EDIT: Another point: assuming Linux, using LVM can be a good way to avoid any potential problems, it makes it easy to resize "partitions" and add new space seemlessly.

| improve this answer | |
  • 2
    Wouldn't it require that at least part of the / partition be uncorrupted? Sure, the kernel image is on /boot, but the drivers are in /lib and the init or sh is in /bin. – Mr. Shiny and New 安宇 Sep 3 '10 at 12:34

I think this is more of a personal preference than anything else. Might even be a best-practice. My personal view of /boot is rather read-only based. Once in a while you need to write in there to upgrade your kernel or maybe add another OS in the grubloader. Besides that it's just needed to ... well, boot. So having it in a separate filesystem might help putting it on read-only (might even be some security aspect to it as well).

Should it be a separate filesystem? I guess not.. But is it a bad idea? No, not at all!

| improve this answer | |

In answer to the 'what problems might it cause' part of the question: as with any partitioning there is always a risk that you will come to need more space than you initially allocated. While this is unlikely in the case of /boot, there was recently an issue with pre-upgrade in Fedora caused by small /boot sizes.

| improve this answer | |

Regarding the second part of the question, it may be useful to place in separate partitions anything that is independent of the current distribution. By also leaving extra space available on the drive, this allows, if necessary in the future, to either install a different distribution, or perform a reinstall of the current one, sharing access to anything that you'd want to see on both.

Obviuos candidates for separate partitions are then /usr/local and /home, as well as /root. I personally find it more efficient to create custom partitions, mount them in an arbitrary mountpoint, like /part/data, and then proceed with symlinks, as in:

sudo ln -sf /part/data/joe /home/joe
sudo ln -sf /part/data/root /root
sudo ln -sf /part/data/usr-local /usr/local
| improve this answer | |

Another reason that I think is not mentioned is that you can use the filesystem type and the configurations that you prefer for /boot which are certainly not the same as the ones when it is used as part of /. Features like journaling, checksums, etc. are not useful for /boot and you can make booting faster by deactivating them or using a simpler filesystem (like ext2).

| improve this answer | |
  • 1
    It's hard for me to believe that journaling and checksumming make boot noticeably slower. Do you have hard numbers? – ignis May 30 '13 at 21:46
  • Sorry, no numbers available, you can experiment if you like. For some people even if it's +5 seconds slower it is noticeable. – sakisk Jun 1 '13 at 8:47
  • Are you implying that it was it 5 seconds slower in your experience? – ignis Jun 1 '13 at 9:16
  • 1
    No. AFAIR the last time I did that I was using ext2. – sakisk Jun 1 '13 at 16:33

I found it slighly more difficult to boot from the grub prompt when using a separate /boot partition.

It seemed that the kernel was on /boot, but the initramfs was on / (separate partition).

So it was not clear which partition to use in the grub menu.

With all the potential advantages of a separate /boot partition, there is also a risk of having to troubleshoot more than usually in case something bad happens (i.e. run grub-install without running update-grub afterwards :S)

| improve this answer | |
  • Fedora uses /boot, in part by history as grub doesn't (didn't?) understand all possible filesystems. And my vmlinuz and initrd are both in /boot, installed from the vanilla kernel from git... – vonbrand Apr 10 '13 at 16:08

Let me write here just my few of my experiences:

Well in my case, I have RAID 1 (1GB only for /boot ) and RAID 5 for rest of disk space.

I use grub 2 from debian squeeze and it is fine. Grub 2 doesn't have this limitation anymore like grub 1 did.

Nowadays it doesn't matter. This was needed when you had grub version 1, which did not know, how to boot from RAID5, but it knew how to boot from raid 1. And that's the reason why.

In my case I use it just for case, I could need it, if something bad happen. Because not everytime you have new LIVE debian or ubuntu in your pocket.

Also if something bad happen, I make backup of /boot. Once it saved my install already.

I use Linux SW RAID 1 with 3 HDDs and RAID 5 with same HDDs. First 1 GB I use for RAID 1.

But if you use LILO or GRUB version 1.98 -> 2, you don't need to have separed /boot partition.

| 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.