01-21-2020, 03:57 AM
Learning about Partitions and How to Create Them for Fedora
<div><p>Operating system distributions try to craft a one size fits all partition layout for their file systems. Distributions cannot know the details about how your hardware is configured or how you use your system though. Do you have more than one storage drive? If so, you might be able to get a performance benefit by putting the write-heavy partitions (<em>var</em> and <em>swap</em> for example) on a separate drive from the others that tend to be more read-intensive since most drives cannot read and write at the same time. Or maybe you are running a database and have a small solid-state drive that would improve the database’s performance if its files are stored on the SSD.</p>
<p> <span id="more-30051"></span> </p>
<p>The following sections attempt to describe in brief some of the historical reasons for separating some parts of the file system out into separate partitions so that you can make a more informed decision when you install your Linux operating system.</p>
<p>If you know more (or contradictory) historical details about the partitioning decisions that shaped the Linux operating systems used today, contribute what you know below in the comments section!</p>
<h2>Common partitions and why or why not to create them</h2>
<h3>The boot partition</h3>
<p>One of the reasons for putting the <em><strong>/</strong>boot</em> directory on a separate partition was to ensure that the boot loader and kernel were located within <a rel="noreferrer noopener" aria-label="the first 1024 cylinders of the disk (opens in a new tab)" href="https://en.wikipedia.org/wiki/Cylinder_1024" target="_blank">the first 1024 cylinders of the disk</a>. Most modern computers do not have the 1024 cylinder restriction. So for most people, this concern is no longer relevant. However, modern UEFI-based computers have <a rel="noreferrer noopener" aria-label="a different restriction (opens in a new tab)" href="https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#EFI_system_partition" target="_blank">a different restriction</a> that makes it necessary to have a separate partition for the boot loader. UEFI-based computers require that the boot loader (<a rel="noreferrer noopener" aria-label="which can be the Linux kernel directly (opens in a new tab)" href="https://www.kernel.org/doc/Documentation/efi-stub.txt" target="_blank">which can be the Linux kernel directly</a>) be on a FAT-formatted file system. The Linux operating system, however, requires a POSIX-compliant file system that can designate access permissions to individual files. Since <a rel="noreferrer noopener" aria-label="FAT file systems do not support access permissions (opens in a new tab)" href="https://en.wikipedia.org/wiki/File_system_permissions#Operating_system_variations" target="_blank">FAT file systems do not support access permissions</a>, the boot loader must be on a separate file system than the rest of the operating system on modern UEFI-based computers. A single partition cannot be <a rel="noreferrer noopener" aria-label="formatted (opens in a new tab)" href="https://en.wikipedia.org/wiki/Disk_formatting#Formatting" target="_blank">formatted</a> with more than one type of file system.</p>
<h3>The var partition</h3>
<p>One of the historical reasons for <a rel="noreferrer noopener" aria-label="putting the /var directory on a separate partition (opens in a new tab)" href="https://access.redhat.com/discussions/641923" target="_blank">putting the /var directory on a separate partition</a> was to prevent files that were frequently written to (<em>/var/log/*</em> for example) from filling up the entire drive. Since modern drives tend to be much larger and since other means like <a rel="noreferrer noopener" aria-label="log rotation (opens in a new tab)" href="https://linuxconfig.org/setting-up-logrotate-on-redhat-linux" target="_blank">log rotation</a> and <a rel="noreferrer noopener" aria-label="disk quotas (opens in a new tab)" href="https://docs.oracle.com/cd/E19253-01/819-5461/gazud/index.html" target="_blank">disk quotas</a> are available to manage storage utilization, putting <em>/var</em> on a separate partition may not be necessary. It is much easier to change a disk quota than it is to re-partition a drive.</p>
<p>Another reason for isolating <em>/var</em> was that file system corruption was much more common in the original version of the Linux <a rel="noreferrer noopener" aria-label="Extended File System (EXT) (opens in a new tab)" href="https://en.wikipedia.org/wiki/Extended_file_system" target="_blank">Extended File System (EXT)</a>. The file systems that had more write activity were much more likely to be irreversibly corrupted by a power outage than those that did not. By partitioning the disk into separate file systems, one could limit the scope of the damage in the event of file system corruption. This concern is no longer as significant because modern file systems support <a rel="noreferrer noopener" aria-label="journaling (opens in a new tab)" href="https://en.wikipedia.org/wiki/Journaling_file_system" target="_blank">journaling</a>.</p>
<h3>The home partition</h3>
<p>Having <em><strong>/</strong>home</em> on a separate partition makes it possible to re-format the other partitions without overwriting your home directories. However, because modern Linux distributions are much better at doing in-place operating system upgrades, re-formatting shouldn’t be needed as frequently as it might have been in the past.</p>
<p>It can still be useful to have <em>/home</em> on a separate partition if you have a dual-boot setup and want both operating systems to share the same home directories. Or if your operating system is installed on a file system that supports snapshots and rollbacks and you want to be able to rollback your operating system to an older snapshot without reverting the content in your user profiles. Even then, some file systems allow their descendant file systems to be rolled back independently, so it still may not be necessary to have a separate partition for <em>/home</em>. On ZFS, for example, one pool/partition can have multiple descendant file systems.</p>
<h3>The swap partition</h3>
<p>The <em>swap</em> partition reserves space for the contents of RAM to be written to permanent storage. There are pros and cons to having a swap partition. A pro of having swap memory is that it theoretically gives you time to gracefully shutdown unneeded applications before <a rel="noreferrer noopener" aria-label="the OOM killer (opens in a new tab)" href="https://lwn.net/Articles/317814/" target="_blank">the OOM killer</a> takes matters into its own hands. This might be important if the system is running mission-critical software that you don’t want abruptly terminated. A con might be that your system runs so slow when it starts swapping memory to disk that you’d rather the OOM killer take care of the problem for you.</p>
<p>Another use for swap memory is <a rel="noreferrer noopener" aria-label="hibernation mode (opens in a new tab)" href="https://www.fosslinux.com/184/what-is-difference-between-suspend-and-hibernate-in-linux.htm" target="_blank">hibernation mode</a>. This might be where the rule that the swap partition should be twice the size of your computer’s RAM originated. Ideally, you should be able to put a system into hibernation even if nearly all of its RAM is in use. Beware that Linux’s support for hibernation is not perfect. It is not uncommon that after a Linux system is resumed from hibernation some hardware devices are left in an inoperable state (for example, no video from the video card or no internet from the WiFi card).</p>
<p>In any case, having a swap partition is more a matter of taste. It is not required.</p>
<h3>The root partition</h3>
<p>The <em>root</em> partition (/) is the catch-all for all directories that have not been assigned to a separate partition. There is always at least one root partition. BIOS-based systems that are new enough to not have the 1024 cylinder limit can be configured with only a root partition and no others so that there is never a need to resize a partition or file system if space requirements change.</p>
<h3>The EFI system partition</h3>
<p>The <a rel="noreferrer noopener" aria-label="EFI System Partition (ESP) (opens in a new tab)" href="https://en.wikipedia.org/wiki/EFI_system_partition" target="_blank">EFI System Partition (ESP)</a> serves the same purpose on UEFI-based computers as the <em>boot</em> partition did on the older BIOS-based computers. It contains the boot loader and kernel. Because the files on the ESP need to be accessible by the computer’s firmware, the ESP has a few restrictions that the older boot partition did not have. The restrictions are:</p>
<ol>
<li>The ESP must be formatted with a FAT file system (<em>vfat</em> in Anaconda)</li>
<li>The ESP must have a special <a rel="noreferrer noopener" aria-label="type code (opens in a new tab)" href="https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs" target="_blank">type-code</a> (<em>EF00</em> when using <a rel="noreferrer noopener" aria-label="gdisk (opens in a new tab)" href="https://fedoramagazine.org/managing-partitions-with-sgdisk/" target="_blank">gdisk</a>)</li>
</ol>
<p>Because the older boot partition did not have file system or type-code restrictions, it is permissible to apply the above properties to the <em>boot</em> partition and use it as your ESP. Note, however, that the GRUB boot loader does not support combining the boot and ESP partitions. If you use GRUB, you will have to create a separate partition and mount it beneath the <em>/boot</em> directory.</p>
<p>The <a rel="noreferrer noopener" aria-label="Boot Loader Specification (BLS) (opens in a new tab)" href="https://systemd.io/BOOT_LOADER_SPECIFICATION/" target="_blank">Boot Loader Specification (BLS)</a> lists several reasons why it is ideal to use the legacy boot partition as your ESP. The reasons include:</p>
<ol>
<li>The UEFI firmware should be able to load the kernel directly. Having a separate, non-ESP compliant boot partition for the kernel prevents the UEFI firmware from being able to directly load the kernel.</li>
<li>Nesting the ESP mount point three mount levels deep increases the likelihood that an intermediate mount could fail or otherwise be unavailable when needed. That is, requiring <em>root</em> (/), then <em>boot</em> (/boot), then <em>efi</em> (/efi) to be consecutively mounted is unnecessarily complex and prone to error.</li>
<li>Requiring the boot loader to be able to read other partitions/disks which may be formatted with arbitrary file systems is non-trivial. Even when the boot loader does contain such code, the code that works at installation time can become outdated and fail to access the kernel/initrd after a file system update. This is currently true of GRUB’s <em>ZFS</em> file system driver, for example. You must be careful not to update your <em>ZFS</em> file system if you use the GRUB boot loader or else your system may not come back up the next time you reboot.</li>
</ol>
<p>Besides the concerns listed above, it is a good idea to have your startup environment — up to and including your <a rel="noreferrer noopener" aria-label="initramfs (opens in a new tab)" href="https://fedoramagazine.org/initramfs-dracut-and-the-dracut-emergency-shell/" target="_blank">initramfs</a> — on a single self-contained file system for recovery purposes. Suppose, for example, that you need to rollback your root file system because it has become corrupted or it has become infected with malware. If your <em>kernel</em> and <em>initramfs</em> are on the <em>root</em> file system, you may be unable to perform the recovery. By having the <em>boot loader</em>, <em>kernel</em>, and <em>initramfs</em> all on a single file system that is rarely accessed or updated, you can increase your chances of being able to recover the rest of your system.</p>
<p>In summary, there are many ways that you can layout your partitions and the type of hardware (BIOS or UEFI) and the brand of boot loader (GRUB, Syslinux or <a rel="noreferrer noopener" aria-label="systemd-boot (opens in a new tab)" href="https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/" target="_blank">systemd-boot</a>) are among the factors that will influence which layouts will work.</p>
<h2>Other considerations</h2>
<h3>MBR vs. GPT</h3>
<p><a rel="noreferrer noopener" aria-label="GUID Partition Table (GPT) (opens in a new tab)" href="https://en.wikipedia.org/wiki/GUID_Partition_Table" target="_blank">GUID Partition Table (GPT)</a> is the newer partition format that supports larger disks. GPT was designed to work with the newer UEFI firmware. It is backward-compatible with the older <a rel="noreferrer noopener" aria-label=" (opens in a new tab)" href="https://en.wikipedia.org/wiki/Master_boot_record" target="_blank">Master Boot Record (MBR)</a> partition format but not all boot loaders support the <a rel="noreferrer noopener" aria-label="MBR boot method (opens in a new tab)" href="https://en.wikipedia.org/wiki/Master_boot_record" target="_blank">MBR boot method</a>. <em>GRUB</em> and <em>Syslinux</em> support both MBR and UEFI, but <em>systemd-boot</em> only supports the newer <a rel="noreferrer noopener" aria-label="UEFI boot method (opens in a new tab)" href="https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#UEFIBOOT" target="_blank">UEFI boot method</a>.</p>
<p>By using GPT now, you can increase the likelihood that your storage device, or an image of it, can be transferred over to a newer computer in the future should you wish to do so. If you have an older computer that natively supports only MBR-partitioned drives, you may need to add the <em>inst.gpt</em> parameter to <strong>Anaconda</strong> when starting the installer to get it to use the newer format. How to add the <em>inst.gpt</em> parameter is shown in the below video titled <strong>“Partitioning a BIOS Computer”</strong>.</p>
<p>If you use the <em>GPT</em> partition format on a BIOS-based computer, and you use the <em>GRUB</em> boot loader, you must additionally create a one megabyte <em>biosboot</em> partition at the start of your storage device. The <em>biosboot</em> partition is not needed by any other brand of boot loader. How to create the <em>biosboot</em> partition is demonstrated in the below video titled <strong>“Partitioning a BIOS Computer”</strong>.</p>
<h3>LVM</h3>
<p>One last thing to consider when manually partitioning your Linux system is whether to use standard partitions or logical volumes. Logical volumes are managed by the <a rel="noreferrer noopener" aria-label="Logical Volume Manager (LVM) (opens in a new tab)" href="https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)" target="_blank">Logical Volume Manager (LVM)</a>. You can setup LVM volumes directly on your disk without first creating standard partitions to hold them. However, most computers still require that the boot partition be a standard partition and not an LVM volume. Consequently, having LVM volumes only increases the complexity of the system because the LVM volumes must be created within standard partitions.</p>
<p>The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. Most laptops do not have hot-swappable drive bays for adding or reconfiguring storage while the system is running. And not many laptop or desktop users have <a rel="noreferrer noopener" aria-label="clvmd (opens in a new tab)" href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/logical_volume_manager_administration/lvm_cluster_overview" target="_blank">clvmd</a> configured so they can access a centralized storage device concurrently from multiple client computers.</p>
<p>LVM is great for servers and clusters. But it adds extra complexity for the typical end user. Go with standard partitions unless you are a server admin who needs the more advanced features.</p>
<h2>Video demonstrations</h2>
<p>Now that you know which partitions you need, you can watch the sort video demonstrations below to see how to manually partition a Fedora Linux computer from the Anaconda installer.</p>
<p>These videos demonstrate creating only the minimally required partitions. You can add more if you choose.</p>
<p>Because the <em>GRUB</em> boot loader requires a more complex partition layout on UEFI systems, the below video titled <strong>“Partitioning a UEFI Computer”</strong> additionally demonstrates how to install the <em>systemd-boot</em> boot loader. By using the <em>systemd-boot</em> boot loader, you can reduce the number of needed partitions to just two — <em>boot</em> and <em>root</em>. How to use a boot loader other than the default (GRUB) with Fedora’s Anaconda installer is officially documented <a rel="noreferrer noopener" aria-label="here (opens in a new tab)" href="https://docs.fedoraproject.org/en-US/fedora/rawhide/install-guide/install/Installing_Using_Anaconda/#sect-installation-gui-storage-partitioning-bootloader" target="_blank">here</a>.</p>
<figure class="wp-block-embed-youtube aligncenter wp-block-embed is-type-video is-provider-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio">
<div class="wp-block-embed__wrapper">
<iframe title="uefi partitioning" width="616" height="462" src="https://www.youtube.com/embed/xu5OdY-5Ce0?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div><figcaption><strong>Partitioning a UEFI Computer</strong></figcaption></figure>
<figure class="wp-block-embed-youtube aligncenter wp-block-embed is-type-video is-provider-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio">
<div class="wp-block-embed__wrapper">
<iframe title="bios partitioning" width="616" height="462" src="https://www.youtube.com/embed/GkOlvUzWzxY?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div><figcaption><strong>Partitioning a BIOS Computer</strong></figcaption></figure>
</div>
https://www.sickgaming.net/blog/2020/01/...or-fedora/
<div><p>Operating system distributions try to craft a one size fits all partition layout for their file systems. Distributions cannot know the details about how your hardware is configured or how you use your system though. Do you have more than one storage drive? If so, you might be able to get a performance benefit by putting the write-heavy partitions (<em>var</em> and <em>swap</em> for example) on a separate drive from the others that tend to be more read-intensive since most drives cannot read and write at the same time. Or maybe you are running a database and have a small solid-state drive that would improve the database’s performance if its files are stored on the SSD.</p>
<p> <span id="more-30051"></span> </p>
<p>The following sections attempt to describe in brief some of the historical reasons for separating some parts of the file system out into separate partitions so that you can make a more informed decision when you install your Linux operating system.</p>
<p>If you know more (or contradictory) historical details about the partitioning decisions that shaped the Linux operating systems used today, contribute what you know below in the comments section!</p>
<h2>Common partitions and why or why not to create them</h2>
<h3>The boot partition</h3>
<p>One of the reasons for putting the <em><strong>/</strong>boot</em> directory on a separate partition was to ensure that the boot loader and kernel were located within <a rel="noreferrer noopener" aria-label="the first 1024 cylinders of the disk (opens in a new tab)" href="https://en.wikipedia.org/wiki/Cylinder_1024" target="_blank">the first 1024 cylinders of the disk</a>. Most modern computers do not have the 1024 cylinder restriction. So for most people, this concern is no longer relevant. However, modern UEFI-based computers have <a rel="noreferrer noopener" aria-label="a different restriction (opens in a new tab)" href="https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#EFI_system_partition" target="_blank">a different restriction</a> that makes it necessary to have a separate partition for the boot loader. UEFI-based computers require that the boot loader (<a rel="noreferrer noopener" aria-label="which can be the Linux kernel directly (opens in a new tab)" href="https://www.kernel.org/doc/Documentation/efi-stub.txt" target="_blank">which can be the Linux kernel directly</a>) be on a FAT-formatted file system. The Linux operating system, however, requires a POSIX-compliant file system that can designate access permissions to individual files. Since <a rel="noreferrer noopener" aria-label="FAT file systems do not support access permissions (opens in a new tab)" href="https://en.wikipedia.org/wiki/File_system_permissions#Operating_system_variations" target="_blank">FAT file systems do not support access permissions</a>, the boot loader must be on a separate file system than the rest of the operating system on modern UEFI-based computers. A single partition cannot be <a rel="noreferrer noopener" aria-label="formatted (opens in a new tab)" href="https://en.wikipedia.org/wiki/Disk_formatting#Formatting" target="_blank">formatted</a> with more than one type of file system.</p>
<h3>The var partition</h3>
<p>One of the historical reasons for <a rel="noreferrer noopener" aria-label="putting the /var directory on a separate partition (opens in a new tab)" href="https://access.redhat.com/discussions/641923" target="_blank">putting the /var directory on a separate partition</a> was to prevent files that were frequently written to (<em>/var/log/*</em> for example) from filling up the entire drive. Since modern drives tend to be much larger and since other means like <a rel="noreferrer noopener" aria-label="log rotation (opens in a new tab)" href="https://linuxconfig.org/setting-up-logrotate-on-redhat-linux" target="_blank">log rotation</a> and <a rel="noreferrer noopener" aria-label="disk quotas (opens in a new tab)" href="https://docs.oracle.com/cd/E19253-01/819-5461/gazud/index.html" target="_blank">disk quotas</a> are available to manage storage utilization, putting <em>/var</em> on a separate partition may not be necessary. It is much easier to change a disk quota than it is to re-partition a drive.</p>
<p>Another reason for isolating <em>/var</em> was that file system corruption was much more common in the original version of the Linux <a rel="noreferrer noopener" aria-label="Extended File System (EXT) (opens in a new tab)" href="https://en.wikipedia.org/wiki/Extended_file_system" target="_blank">Extended File System (EXT)</a>. The file systems that had more write activity were much more likely to be irreversibly corrupted by a power outage than those that did not. By partitioning the disk into separate file systems, one could limit the scope of the damage in the event of file system corruption. This concern is no longer as significant because modern file systems support <a rel="noreferrer noopener" aria-label="journaling (opens in a new tab)" href="https://en.wikipedia.org/wiki/Journaling_file_system" target="_blank">journaling</a>.</p>
<h3>The home partition</h3>
<p>Having <em><strong>/</strong>home</em> on a separate partition makes it possible to re-format the other partitions without overwriting your home directories. However, because modern Linux distributions are much better at doing in-place operating system upgrades, re-formatting shouldn’t be needed as frequently as it might have been in the past.</p>
<p>It can still be useful to have <em>/home</em> on a separate partition if you have a dual-boot setup and want both operating systems to share the same home directories. Or if your operating system is installed on a file system that supports snapshots and rollbacks and you want to be able to rollback your operating system to an older snapshot without reverting the content in your user profiles. Even then, some file systems allow their descendant file systems to be rolled back independently, so it still may not be necessary to have a separate partition for <em>/home</em>. On ZFS, for example, one pool/partition can have multiple descendant file systems.</p>
<h3>The swap partition</h3>
<p>The <em>swap</em> partition reserves space for the contents of RAM to be written to permanent storage. There are pros and cons to having a swap partition. A pro of having swap memory is that it theoretically gives you time to gracefully shutdown unneeded applications before <a rel="noreferrer noopener" aria-label="the OOM killer (opens in a new tab)" href="https://lwn.net/Articles/317814/" target="_blank">the OOM killer</a> takes matters into its own hands. This might be important if the system is running mission-critical software that you don’t want abruptly terminated. A con might be that your system runs so slow when it starts swapping memory to disk that you’d rather the OOM killer take care of the problem for you.</p>
<p>Another use for swap memory is <a rel="noreferrer noopener" aria-label="hibernation mode (opens in a new tab)" href="https://www.fosslinux.com/184/what-is-difference-between-suspend-and-hibernate-in-linux.htm" target="_blank">hibernation mode</a>. This might be where the rule that the swap partition should be twice the size of your computer’s RAM originated. Ideally, you should be able to put a system into hibernation even if nearly all of its RAM is in use. Beware that Linux’s support for hibernation is not perfect. It is not uncommon that after a Linux system is resumed from hibernation some hardware devices are left in an inoperable state (for example, no video from the video card or no internet from the WiFi card).</p>
<p>In any case, having a swap partition is more a matter of taste. It is not required.</p>
<h3>The root partition</h3>
<p>The <em>root</em> partition (/) is the catch-all for all directories that have not been assigned to a separate partition. There is always at least one root partition. BIOS-based systems that are new enough to not have the 1024 cylinder limit can be configured with only a root partition and no others so that there is never a need to resize a partition or file system if space requirements change.</p>
<h3>The EFI system partition</h3>
<p>The <a rel="noreferrer noopener" aria-label="EFI System Partition (ESP) (opens in a new tab)" href="https://en.wikipedia.org/wiki/EFI_system_partition" target="_blank">EFI System Partition (ESP)</a> serves the same purpose on UEFI-based computers as the <em>boot</em> partition did on the older BIOS-based computers. It contains the boot loader and kernel. Because the files on the ESP need to be accessible by the computer’s firmware, the ESP has a few restrictions that the older boot partition did not have. The restrictions are:</p>
<ol>
<li>The ESP must be formatted with a FAT file system (<em>vfat</em> in Anaconda)</li>
<li>The ESP must have a special <a rel="noreferrer noopener" aria-label="type code (opens in a new tab)" href="https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs" target="_blank">type-code</a> (<em>EF00</em> when using <a rel="noreferrer noopener" aria-label="gdisk (opens in a new tab)" href="https://fedoramagazine.org/managing-partitions-with-sgdisk/" target="_blank">gdisk</a>)</li>
</ol>
<p>Because the older boot partition did not have file system or type-code restrictions, it is permissible to apply the above properties to the <em>boot</em> partition and use it as your ESP. Note, however, that the GRUB boot loader does not support combining the boot and ESP partitions. If you use GRUB, you will have to create a separate partition and mount it beneath the <em>/boot</em> directory.</p>
<p>The <a rel="noreferrer noopener" aria-label="Boot Loader Specification (BLS) (opens in a new tab)" href="https://systemd.io/BOOT_LOADER_SPECIFICATION/" target="_blank">Boot Loader Specification (BLS)</a> lists several reasons why it is ideal to use the legacy boot partition as your ESP. The reasons include:</p>
<ol>
<li>The UEFI firmware should be able to load the kernel directly. Having a separate, non-ESP compliant boot partition for the kernel prevents the UEFI firmware from being able to directly load the kernel.</li>
<li>Nesting the ESP mount point three mount levels deep increases the likelihood that an intermediate mount could fail or otherwise be unavailable when needed. That is, requiring <em>root</em> (/), then <em>boot</em> (/boot), then <em>efi</em> (/efi) to be consecutively mounted is unnecessarily complex and prone to error.</li>
<li>Requiring the boot loader to be able to read other partitions/disks which may be formatted with arbitrary file systems is non-trivial. Even when the boot loader does contain such code, the code that works at installation time can become outdated and fail to access the kernel/initrd after a file system update. This is currently true of GRUB’s <em>ZFS</em> file system driver, for example. You must be careful not to update your <em>ZFS</em> file system if you use the GRUB boot loader or else your system may not come back up the next time you reboot.</li>
</ol>
<p>Besides the concerns listed above, it is a good idea to have your startup environment — up to and including your <a rel="noreferrer noopener" aria-label="initramfs (opens in a new tab)" href="https://fedoramagazine.org/initramfs-dracut-and-the-dracut-emergency-shell/" target="_blank">initramfs</a> — on a single self-contained file system for recovery purposes. Suppose, for example, that you need to rollback your root file system because it has become corrupted or it has become infected with malware. If your <em>kernel</em> and <em>initramfs</em> are on the <em>root</em> file system, you may be unable to perform the recovery. By having the <em>boot loader</em>, <em>kernel</em>, and <em>initramfs</em> all on a single file system that is rarely accessed or updated, you can increase your chances of being able to recover the rest of your system.</p>
<p>In summary, there are many ways that you can layout your partitions and the type of hardware (BIOS or UEFI) and the brand of boot loader (GRUB, Syslinux or <a rel="noreferrer noopener" aria-label="systemd-boot (opens in a new tab)" href="https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/" target="_blank">systemd-boot</a>) are among the factors that will influence which layouts will work.</p>
<h2>Other considerations</h2>
<h3>MBR vs. GPT</h3>
<p><a rel="noreferrer noopener" aria-label="GUID Partition Table (GPT) (opens in a new tab)" href="https://en.wikipedia.org/wiki/GUID_Partition_Table" target="_blank">GUID Partition Table (GPT)</a> is the newer partition format that supports larger disks. GPT was designed to work with the newer UEFI firmware. It is backward-compatible with the older <a rel="noreferrer noopener" aria-label=" (opens in a new tab)" href="https://en.wikipedia.org/wiki/Master_boot_record" target="_blank">Master Boot Record (MBR)</a> partition format but not all boot loaders support the <a rel="noreferrer noopener" aria-label="MBR boot method (opens in a new tab)" href="https://en.wikipedia.org/wiki/Master_boot_record" target="_blank">MBR boot method</a>. <em>GRUB</em> and <em>Syslinux</em> support both MBR and UEFI, but <em>systemd-boot</em> only supports the newer <a rel="noreferrer noopener" aria-label="UEFI boot method (opens in a new tab)" href="https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#UEFIBOOT" target="_blank">UEFI boot method</a>.</p>
<p>By using GPT now, you can increase the likelihood that your storage device, or an image of it, can be transferred over to a newer computer in the future should you wish to do so. If you have an older computer that natively supports only MBR-partitioned drives, you may need to add the <em>inst.gpt</em> parameter to <strong>Anaconda</strong> when starting the installer to get it to use the newer format. How to add the <em>inst.gpt</em> parameter is shown in the below video titled <strong>“Partitioning a BIOS Computer”</strong>.</p>
<p>If you use the <em>GPT</em> partition format on a BIOS-based computer, and you use the <em>GRUB</em> boot loader, you must additionally create a one megabyte <em>biosboot</em> partition at the start of your storage device. The <em>biosboot</em> partition is not needed by any other brand of boot loader. How to create the <em>biosboot</em> partition is demonstrated in the below video titled <strong>“Partitioning a BIOS Computer”</strong>.</p>
<h3>LVM</h3>
<p>One last thing to consider when manually partitioning your Linux system is whether to use standard partitions or logical volumes. Logical volumes are managed by the <a rel="noreferrer noopener" aria-label="Logical Volume Manager (LVM) (opens in a new tab)" href="https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)" target="_blank">Logical Volume Manager (LVM)</a>. You can setup LVM volumes directly on your disk without first creating standard partitions to hold them. However, most computers still require that the boot partition be a standard partition and not an LVM volume. Consequently, having LVM volumes only increases the complexity of the system because the LVM volumes must be created within standard partitions.</p>
<p>The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. Most laptops do not have hot-swappable drive bays for adding or reconfiguring storage while the system is running. And not many laptop or desktop users have <a rel="noreferrer noopener" aria-label="clvmd (opens in a new tab)" href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/logical_volume_manager_administration/lvm_cluster_overview" target="_blank">clvmd</a> configured so they can access a centralized storage device concurrently from multiple client computers.</p>
<p>LVM is great for servers and clusters. But it adds extra complexity for the typical end user. Go with standard partitions unless you are a server admin who needs the more advanced features.</p>
<h2>Video demonstrations</h2>
<p>Now that you know which partitions you need, you can watch the sort video demonstrations below to see how to manually partition a Fedora Linux computer from the Anaconda installer.</p>
<p>These videos demonstrate creating only the minimally required partitions. You can add more if you choose.</p>
<p>Because the <em>GRUB</em> boot loader requires a more complex partition layout on UEFI systems, the below video titled <strong>“Partitioning a UEFI Computer”</strong> additionally demonstrates how to install the <em>systemd-boot</em> boot loader. By using the <em>systemd-boot</em> boot loader, you can reduce the number of needed partitions to just two — <em>boot</em> and <em>root</em>. How to use a boot loader other than the default (GRUB) with Fedora’s Anaconda installer is officially documented <a rel="noreferrer noopener" aria-label="here (opens in a new tab)" href="https://docs.fedoraproject.org/en-US/fedora/rawhide/install-guide/install/Installing_Using_Anaconda/#sect-installation-gui-storage-partitioning-bootloader" target="_blank">here</a>.</p>
<figure class="wp-block-embed-youtube aligncenter wp-block-embed is-type-video is-provider-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio">
<div class="wp-block-embed__wrapper">
<iframe title="uefi partitioning" width="616" height="462" src="https://www.youtube.com/embed/xu5OdY-5Ce0?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div><figcaption><strong>Partitioning a UEFI Computer</strong></figcaption></figure>
<figure class="wp-block-embed-youtube aligncenter wp-block-embed is-type-video is-provider-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio">
<div class="wp-block-embed__wrapper">
<iframe title="bios partitioning" width="616" height="462" src="https://www.youtube.com/embed/GkOlvUzWzxY?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div><figcaption><strong>Partitioning a BIOS Computer</strong></figcaption></figure>
</div>
https://www.sickgaming.net/blog/2020/01/...or-fedora/