Is it good to make a separate partition for /boot?

Question

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?

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

score 54 · Accepted Answer · edited Apr 12 '22 at 07:24

54

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.

edited Apr 12 '22 at 07:24

Manuel Jordan

1,728
2
16
40

answered Aug 12 '10 at 00:59

Avery Payne

996
8
8

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 http://fedoraproject.org/wiki/Common_F13_bugs#Preupgrade_doesn.27t_work_with_default-sized_.2Fboot_partition) – Cristian Ciupitu Aug 29 '10 at 01: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 02 '10 at 20:51
36

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 03 '10 at 12:33
@xenoterracide, when you find out, let me know...I too have noticed this "bigger is better" trend with /boot partitioning. Does the Tux graphic really need 100Mbyte of storage? :) – Avery Payne Sep 03 '10 at 22:17
RE @Mr. Shiny ++ I always use ext2 that way if i screw up any part of my grub.conf or whatever I can use any cdrom going back 10 years to fix it. – xenoterracide Sep 04 '10 at 00:25
2

@Avery Payne, @xenoterracide: my current /boot under ubuntu 10.10 is 463MB. This is an old install that's been upgraded since kernel 2.6.22. I guess Ubuntu's package management doesn't delete old kernels for some reason. This was an ubuntustudio install at one point, so for a lot of the kernels I have both -generic and -rt versions. Also, there is a backup of each of the ~8MB initrd files. Obviously this problem is easily resolved for someone who knows what's going on. Maybe they don't delete old kernels unless /boot is full? – intuited Jan 20 '11 at 01:04
26

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 04 '11 at 08: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
If you update your kernel with yum, the installonlyn plugin (enabled by default) will clear out old kernels for you automatically. – Michael Hampton May 04 '13 at 20:54
"the" was "þe", never "ye", but most of us don't have the letter thorn (þ) on our keyboards any more. – Walf Oct 06 '23 at 04:56

score 43 · Answer 2 · edited Aug 27 '19 at 16:49

43

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

edited Aug 27 '19 at 16:49

Jeff Schaller

67,283
35
116
255

answered Aug 11 '10 at 10:11

dsp

919

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 01:07

score 19 · Answer 3 · edited May 04 '13 at 20:21

19

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.

edited May 04 '13 at 20:21

Anthon

79,293

answered Aug 12 '10 at 10:01

wzzrd

3,720

4

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 01:15
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 07:17
1

Your root filesystem is more likely to get full if your disk is fragmented into partitions and less is available to the root partition – nafg Jul 16 '17 at 23:49
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 00:08
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
@Faheem M.: So.... are you saying it doesn't work for you, or mainly that I must be remembering the timeframe badly? A very quick google turned up this entry posted on November 20th, 2006 so I'm going to bet I was right with my timeframe. – sehe Mar 23 '11 at 00:33
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

tsvallender · Answer 4 · 2010-08-12T09:12:43.617

13

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.

edited Aug 12 '10 at 09:12

answered Aug 11 '10 at 12:56

tsvallender

607

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 03 '10 at 12:34

score 7 · Answer 5 · answered Aug 12 '10 at 00:37

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.

score 6 · Answer 6 · answered Aug 11 '10 at 09: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!

score 1 · Answer 7 · answered Apr 10 '13 at 15:50

1

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)

answered Apr 10 '13 at 15:50

Alecz

141

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

score 1 · Answer 8 · answered Mar 22 '11 at 06:07

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

score 1 · Answer 9 · answered Mar 22 '11 at 08:44

1

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

answered Mar 22 '11 at 08:44

sakisk

2,873

2

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 01 '13 at 08:47
Are you implying that it was it 5 seconds slower in your experience? – ignis Jun 01 '13 at 09:16
1

No. AFAIR the last time I did that I was using ext2. – sakisk Jun 01 '13 at 16:33

score 0 · Answer 10 · edited Dec 29 '12 at 01:00

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.

score 0 · Answer 11 · answered Apr 26 '21 at 23:24

If you boot with EFI, then /boot/efi is another mount of the separate EFI system partition, so you already have a partly separate boot partition, that is the EFI partition.

That is only partly, because /boot also contains GRUB, kernels etc.

So the question becomes: why does all these don't go into the EFI partition?

Is it good to make a separate partition for /boot?

11 Answers11

Linked