I dual boot Windows 7 with Linux Mint. However, Windows 7's partition layout takes up all the primary partitions, leaving me with the option of one more primary partition or many more logical partitions. So, I went with logical. However, I am just reading that /boot should be mounted on a separate primary partition, but I mount the whole root directory on a logical partition. My Linux Mint operates seemingly fine, but might this be problematic?
Linux – Does /boot need to be mounted on a separate primary partition
bootlinuxpartition
Related Solutions
Here is the problem in your understanding:
My understanding is that the bootloader GRUB2, is mounted to /boot.
GRUB is not "mounted" on boot. GRUB is installed to /boot
, and is loaded from code in the Master Boot Record.
Here is a simplified overview of the modern boot process, assuming a GNU/Linux distribution with an MBR/BIOS (not GPT/UEFI):
- The BIOS loads.
- The BIOS loads the small piece of code that is in the Master Boot Record.
- GRUB does not fit in 440 bytes, the size of the Master Boot Record. Therefore, the code that is loaded actually just parses the partition table, finds the
/boot
partition (which I believe is determined when you install GRUB to the Master Boot Record), and parses the filesystem information. It then loads Stage 2 GRUB. (This is where the simplification comes in.) - Stage 2 GRUB loads everything it needs, including the GRUB configuration, then presents a menu (or not, depending on user configuration).
- A boot sequence is chosen. This could be by a timeout, by the user selecting a menu entry, or by booting a command list.
- The boot sequence starts executing. This can do a number of things - for example, loading a kernel, chainloading to another bootloader - but let's assume that the boot sequence is standard GNU/Linux.
- GRUB loads the Linux kernel.
- GRUB loads the initial ramdisk.
- The initial ramdisk mounts
/
under/new_root
(possibly cryptographically unlocking it), starts udev, starts resume-from-swap, etc. - The initial ramdisk uses the
pivot_root
utility to set/new_root
as the real/
. init
starts. Partitions get mounted, daemons get started, and the system boots.
Notice how the kernel is only loaded at step 7. Because of this, there is no concept of mounting until step 7. This is why /boot
has to be mounted again in step 9, even though GRUB has already used it.
It may also be of use to look at the GRUB 2 section of the Wikipedia page on GRUB.
The partitions are spaced well enough, and you could transform the primary partitition sda4
into a logical one sda10
, if you first resize the extended partition sda3
.
See below for a modified table that you could use with sfdisk /dev/sda < new_partition
, and for a diff showing the modifications made. After this, you should have a free slot for another primary partition (a new sda4
).
However I strongly advice you to first try it on a dummy file that you could create with
$ dd if=/dev/null of=/tmp/dummy bs=1 seek=1000G
$ sfdisk /tmp/dummy < new_partition
Then, as root:
# kpartx -a /tmp/dummy
The last step will let the kernel attach a loop device (/dev/loop0
if it isn't already in use) to /tmp/dummy
and scan all the partitions that you have created on it. Then you could check with partitioning tools like fdisk
or gparted
if they're able to parse the partitioning of /dev/loop0
fine. Only after all that proceed with the
# sfdisk /dev/sda < new_partition
followed by a reboot.
You should also change any references to sda4
to sda10
(and (hd0,msdos4)
to (hd0,msdos10)
) in /etc/fstab
and /etc/grub.d/*
(the latter followed by an update-grub
).
By all means, do not accuse me of anything if you're hosing your system ;-)
It may be better to wait for another answer, there are probably automated tools that could convert your partition table to GPT or such things, or more friendly partitioning programs that let you do it in a guided way.
new_partition:
/dev/sda1 : start= 2048, size= 1124352, type=7, bootable
/dev/sda2 : start= 1126400, size= 408475648, type=7
/dev/sda3 : start= 409602048, size= 1040963584, type=f
/dev/sda5 : start= 409602056, size= 409599984, type=7
/dev/sda6 : start= 819204096, size= 78123008, type=83
/dev/sda7 : start= 897329152, size= 9762816, type=82
/dev/sda8 : start= 907094016, size= 195309568, type=83
/dev/sda9 : start= 1102403592, size= 307199984, type=7
/dev/sda10 : start= 1409605632, size= 40960000, type=83
diff:
@@ -1,9 +1,9 @@
/dev/sda1 : start= 2048, size= 1124352, type=7, bootable
/dev/sda2 : start= 1126400, size= 408475648, type=7
-/dev/sda3 : start= 409602048, size= 1000001528, type=f
-/dev/sda4 : start= 1409605632, size= 40960000, type=83
+/dev/sda3 : start= 409602048, size= 1040963584, type=f
/dev/sda5 : start= 409602056, size= 409599984, type=7
/dev/sda6 : start= 819204096, size= 78123008, type=83
/dev/sda7 : start= 897329152, size= 9762816, type=82
/dev/sda8 : start= 907094016, size= 195309568, type=83
/dev/sda9 : start= 1102403592, size= 307199984, type=7
+/dev/sda10 : start= 1409605632, size= 40960000, type=83
Best Answer
Linux doesn't care where
/boot
is. In fact, Linux itself doesn't access/boot
at all except when updating its contents. Only the bootloader accesses/boot
.In most setups, it is unnecessary to put
/boot
on a separate partition. There are downsides to separating out/boot
: it's more complicated, it uses up an entry in the partition table, it could run out of spaceā¦ The only reason to split out/boot
is if it's necessary to make the system bootable.With older PCs, it used to be often necessary to have a small
/boot
partition at the beginning of the disk. This was due to BIOS limitations. The BIOS is the system software that's in the computer's flash memory and that loads the operating system from the hard disk. Older BIOS generations tended to be incapable of reading from the whole disk. The last few BIOS generations before UEFI, and UEFI, have no such limitations, so these days you can mostly forget about those, but you'll still find tutorials that date back from the limited BIOS era (as well as people who were educated to make a separate/boot
partition for that reason and aren't aware that it isn't relevant anymore).Another reason to have a separate
/boot
partition is if your root partition uses some mechanism that your bootloader doesn't support. For the most part, like BIOS limitations, this is an obsolete concern: Grub (the standard PC bootloader) supports most of the filesystems and partition types that Linux supports.On UEFI systems, it's possible to put the kernel image on the EFI partition. Then you have a separate boot partition, but it isn't a Linux-specific boot partition, it's a system-wide boot partition.
The main reason to have a separate
/boot
partition these days is if you encrypt the system partition. The code that knows how to perform the decryption is in the kernel (or in the initrd/initramfs), so the kernel (and initrd/initramfs) needs to be in unencrypted storage. Even if the bootloader supported the encryption mechanism, you'd need to enter the password twice, once for the bootloader and one for Linux itself (or else there would have to be a mechanism to communicate that password, which would be pretty hard to do without exposing the password more widely than it should).Note that this answer applies to PC computers. Other types of computers boot in a different way and may or may not need the kernel to be in a special place.