Now that we have seen the partitions created automatically, what does Anaconda allow you to do, if you decide to create partitions manually. The first step to creating partitions manually, is to select “Create Custom Layout” from the partitions methods step.
The next set of screenshots are used to show what will happen if you attempt to create partitions, but miss a few steps, or use the wrong installation image. Note that a Live CD image was used for this tutorial, and the objective is to install Fedora 16 on a btrfs file system. The target disk is ready, so to start, select it and click Create.
Normally, if you wanted to install a Linux distribution on a btrfs file system, you would create a boot partition, one for Swap, a third for root, formated with btrfs. But that is for a system using MBR table. To create a GPT-based system, the first partition has to be a Standard partition with the bios_boot flag. Note that this step will have to be repeated for all partitions that will be created.
Here, you can specify the properties of the partition. For “File System Type,” select “BIOS Boot.” For “Size,” 1 MB is recommended. That is all you need to specify to create a “BIOS Boot” partition.
With the first partition created, select the free space and click Create.
As in the previous step, we are going to create a Standard partition. Create.
This partition will be mounted at /boot. By default, Anaconda allocates 500 MB to this partition. OK.
For the last partition, select the mount point (/), btrfs as the “File system Type” and “Fill to maximum allowable size, if you intend to use the rest of the available space. Optionally, you may encrypt the partition. OK.
This is the final set of partitions. But will this work?
Apparently, it will not because the Live CD editions of Fedora 16 do not support creating anything other than the default LVM partitioning scheme. Also, if you noticed, there is no Swap partition. The reason is explained in the image below. Now we know what will not work if we try to create partitions manually. In a follow up article, a step-by-step guide on how to install Fedora 16 on an encrypted btrfs file system will be presented.
Extra tips from Official Fedora channels:
Starting in Fedora 16, on non-EFI x86 (32 and 64 bit) systems, Anaconda will default to creating GPT disklabels (partition tables) instead of MSDOS disk labels. On these systems, when booting from a GPT-labelled disk, it is strongly recommended (not necessarily required in all cases, depending on the system’s BIOS/firmware) to create a small (1 MiB) BIOS boot partition. This partition will be used by the bootloader (GRUB2) for storage.
Automatic partitioning will create the partition when appropriate, but users who choose custom partitioning will have to create this partition for themselves. This BIOS boot partition is only necessary on non-EFI x86 systems whose boot device is a GPT-labelled disk.
Thanks for writing this article, it’s nicely done and almost entirely correct. However, it’s not true to say that “Apparently, it will not because the Live CD editions of Fedora 16 do not support creating anything other than the default LVM partitioning scheme.” The live installer is restricted, but not that restricted. The restriction is that the root partition (in fact, any partitions which contain files from the actual system image, so if you were to split out /usr or /var, for e.g., the restriction would apply to those too) must be ext4. You can create a partition layout manually, have the sizes be whatever you want, use LVM or not, use encryption or not – but the partitions with system files on must be ext4. The reason is simple: Fedora live images are actually compressed snapshots of an ext4 filesystem, and the live installation process does not take actual .rpm package files from a disc or repository and install them one by one, as the ‘traditional’ installer does, it just essentially writes the filesystem image directly onto the disk. To do this, the target filesystem(s) have to be the same as the source, i.e., ext4. You can’t write an ext4 filesystem image to a btrfs partition.
Who cares? If it is a server you reboot it once ayera or less. If ir is a desktop you suspend it and only power it off when you are leaving for a week or so. And anyway even if using systemd activating LVM is only a small part of boot time.
About people saying LVM is slower, it is like peole saying you should compare your own kernel: none of them has bothered running a benchmark. Now, logically LVM should be slower or at least use more CPU time. It doesn’t. Now if you think at it the overhead for finding the right block is something in the order of a couple dozens of CPU cycles. Also my LV was in pristine condition: if it is fragmented due to having ben extended multiple times then it _will_ be slower than a partition because there will be head movements but of course the point is moot because the partition would have become full and if you were able to carve a new one then you could have done the same thing with LVM.
Also there is a nice thing with LVM: you can give them significanty names so you don’t need neither mounting them nor running a special tool (for reading labels) to know what you have stored in them.
I personally have used LVM since it became the default in Fedora. And yes, its flexibility helped me considerably (and this is why I kept using it).
Anyway, searched a little and it seems that you are right that LVM doesn’t degrade performance much by itself.
I’m going to agree with your Anaconda… statement with one small hiccup – Time Zone selection is very finicky due to the small size of the world map.
True. I wish they will use the same system employed by Ubuntu.
Non-LVM partitioning has an advantage over LVM method: speed…
I benchmarked LVM vs non-LVM on the same physical partition and there was no difference.
I have not compared it myself but I have read it in many places. Even in the case you mentioned, it is *possible* to achieve higher boot speeds if you don’t use LVM (you’ll need to disable some services running at boot by systemd).
Are these “higher” (faster) boot speeds really that much? At best, are we not talking no more than 2 or 3 seconds here? The benefits of LVM far outweigh that reduced boot time.
Well, apparently it could be around 8 seconds for a machine: http://lists.fedoraproject.org/pipermail/devel/2011-October/157732.html
But yes, LVM benefits might outweigh the gains.