Handbook Talk:AMD64/Installation/Disks

GPT not recognized
To get my bios to recognize my GPT, I had to set the protective MBR flag to "on" in parted, thusly:

disk_set pmbr_boot on

Without this flag set, GRUB wasn't even recognized. This may help some people, and may be a good tidbit/candidate for including in the handbook!


 * , good to know. Thanks. Be be sure to sign you comments using the signature button found in the toolbar above. --Maffblaster (talk) 18:12, 7 May 2016 (UTC)

Paragraphs of "Alternative: Using fdisk to partition the disk" is not clear
I think we are using a MBR disk label. True?

In "Alternative: Using fdisk to partition the disk" it say "Mark the partition for EFI purposes:". What means this. It suppose we are in a BIOS boot, not EFI boot.

The command box say "Changed system type of partition 1 to 4 (BIOS boot)". The type of partition for code 4 is "FAT16 <32M" on fdisk.

In the next command box /dev/sda1 is changed and now show "EFI (FAT-12/16/32)"

Are these some mistakes? Quilosaq (talk) 00:16, 29 September 2015 (UTC)

The paragraph of "Introduction to block devices" is confusing for newbies. Why is not there a step by step guide what to do to get partitioned disk when using MBR and an another guide when using EFI?

It is not clear what to do to get a filesystem on BIOS boot partition? Which filesystem should there created out there? --Best, Pál (talk) 11:18, 11 February 2016 (UTC)


 * Hi Pál,


 * I see your dilemma and concur a change needs to be made defining BIOS and EFI disk partitioning. I'll work on making the changes a bit later today. --Maffblaster (talk) 13:01, 7 May 2016 (UTC)

This has yet to be corrected and is not only confusing, but is also incorrect for the stated purpose of this part of the guide, which is:


 * "The instructions given below assume that the partition layout being used is MBR."

When using MBR, there is no need to have a BIOS boot partition. According to this Wikipedia entry:


 * "A BIOS boot partition is needed because GPT uses the disk sectors immediately following the Master Boot Record (MBR) to hold the actual partition table, whereas the traditional MBR-based partitioning scheme does not..."

It even states clearly in a paragraph further up in this guide titled What is the BIOS boot partition? that


 * "the BIOS boot partition is needed when GPT partition layout is used with GRUB2, or when the MBR partition layout is used with GRUB2 when the first partition starts earlier than the 1 MB location on the disk."

When creating the boot partition for the MBR partitioning scheme, it is more than enough to start at 2048 (as is written in the guide, yet incorrectly associated with GPT partitioning schemes). You can even emphasis this if you like.

The entire chapter titled Creating the BIOS boot partition should either be removed from this section, or as an alternative the chapter should be renamed to Creating the BIOS boot partition (BIOS based systems only) in order to emphasis the purpose of this chapter. And even then, it needs to be corrected as mentioned in the next paragraph.

Furthermore, as mentioned by Quilosaq in the opening of this conversation, this same chapter includes incorrect information starting at "Mark the partition for UEFI purposes:". Assuming this chapter is meant as a guide for using fdisk to produce a GPT partitioning scheme, Quilosaq is correct in his assertion that choosing number 4 results in FAT16 <32M. The code example results show "Changed system type of partition 1 to 4 (BIOS boot)", which is simply incorrect, and not the result of choosing number 4...the code should be "ef" not "4" if the examples of printing out the partition table throughout the rest of the guide is meant to be accurate for a GPT partitioning scheme...because it sure as hell isn't correct for an MBR partitioning scheme, which brings up the next point.

Throughout the rest of the guide, the examples of printing out the partition table in fdisk shows that the boot partition is set as EFI (FAT-12/16/32) which are also completely and utterly incorrect for an MBR partitioning scheme and only serves to further confuse users on what they need to do for MBR partitioning schemes.

My suggestion to correct the confusion is to have separate sections:

Default (what most users will have/do)
 * 1. UEFI based systems.
 * 1a. UEFI based systems using GPT partitioning scheme with parted.
 * 1a1. same but with fdisk.
 * 1b. UEFI based systems using MBR partitioning scheme with fdisk.
 * 1b1. same but with parted.

Alternative (still lots of BIOS based systems around)
 * 2. BIOS based systems.
 * 2a. BIOS based systems using MBR partitioning scheme with fdisk.
 * 2a1. same but with parted.
 * 2b. BIOS based systems using GPT partitioning scheme with parted.
 * 2b1. same but with fdisk.

The current guide as it is remains a combination of BIOS/UEFI systems with examples for MBR partitioning schemes with fdisk showing (incorrect) results for GPT partitioning schemes with fdisk and is very confusing to say the least.

--Platoxia (talk) 08:05, 11 July 2016 (UTC)


 * Yes, this disk section has needed some work for quite some time. The errors need addressed and the sections need revised to cover more of possible disk combinations. I'll try to implement some of your recommendations after I get finished testing all the possible modes in my VM. I hope to close this out soonish. Kind regards, --Maffblaster (talk) 10:38, 2 January 2017 (UTC)

Creating the partitions
Why naming it primary and right after that rename it? Make it simple:

mkpart grub 1 3 mkpart boot 3 131 mkpart swap 131 643 mkpart rootfs 643 -1

--StalkerNOVA (talk) 08:53, 21 October 2016 (UTC)


 * Primary is not a name. It is (with extended) a partition type. --Quilosaq (talk) 14:36, 21 October 2016 (UTC)


 * Not for GPT --StalkerNOVA (talk) 14:37, 21 October 2016 (UTC)


 * Sorry. I was wrong. --Quilosaq (talk) 16:10, 21 October 2016 (UTC)


 * Correct, primary is just defining that the partition is not a logical partition. :) Closing discussion! Kind regards, --Maffblaster (talk) 22:37, 30 December 2016 (UTC)

Switch UEFI /boot (ESP) fs type recommendation from vfat to fat32
The UEFI specification requirements for ESP is fat32. vfat might (probably does) work but I believe this is a coincidence.

If you do 'mkfs.vfat /dev/sda2' and then open up 'parted', you will see that parted detects the filesystem type as fat16. From what I read here:

http://unix.stackexchange.com/a/263731

It says that vfat is a backwards compatible version of FAT16 that added long file name support.

FAT32 is basically an enhancement of FAT16 that not only added long file name support, but also support for larger disks. Due to the similarities of vfat and fat32, usually (if not always) the same driver is used.

An empty fat16 and vfat partition are indistinguishable at the driver level, apparently, one would need to create a file that has a long file name in order for the driver to specify that it isn't vanilla fat16 but instead vfat.

Arch Linux's EFI System Partition documentation explicitly recommends doing 'mkfs.fat -F32':

https://wiki.archlinux.org/index.php/EFI_System_Partition#Format_the_partition

This is more of a recommendation since I don't know too much about it and I just ended up successfully installing my first gentoo system on UEFI-GPT rather than what I've been doing before BIOS-MBR or BIOS-GPT.

If you guys believe with confidence that we won't have any future problems with using vfat rather than fat32 explicitly, then we can leave as is. If we decide to change this, we should go through the documentation to update any 'vfat' references to 'fat32' in order to avoid confusion.

--Fearedbliss (talk) 22:11, 29 December 2016 (UTC)


 * Thanks, I'll look it over. Please remember to sign your contributions to discussion pages with the signature button found in the formatting toolbox. Kind regards, --Maffblaster (talk) 22:08, 29 December 2016 (UTC)


 * After performing the necessary research (according to Wikipedia), it looks like you are correct: it is probably best to specify F32 here, rather than taking the defaults of the command. VFAT looks to be a long-name support enhancement of all FAT variants. :) Thanks for the due diligence. I'll update the relevant parts of the installation Handbook to reflect these changes. --Maffblaster (talk) 22:35, 30 December 2016 (UTC)

Add info about installations using Advanced Format 4K native disks
4Kn disks require UEFI to boot (due to different logical sector size - 512B vs 4kB), see [|this Dell data sheet].

Also minimal partition size for ESP is 260 MB for 4Kn disk [|see here] due to FAT32 internals. Most probably formating the partition using

mkfs.vfat -F32 /dev/sdXY

will return

WARNING: Not enough clusters for a 32 bit FAT!

In this case you have to use -s 2 option for mkfs.vfat. If you use partition smaller than 260MB no warning or error will be displayed and UEFI won't be able to detect ESP at all!

I spend quite some time figuring this one out because the partition seemed fine from live OS. Only problem was UEFI wasn't able to detect any file system on the block device so I spend few hours in UEFI shell debuging this and trying different things.

Vlkodlak (talk) 12:02, 26 January 2017 (UTC)


 * , thank you for the time you spent researching and documenting you're research here. Especially as drives continue to increase in capacity, seems like it's entirely reasonable to mention this in the Handbook. I'll add it to my list of things to do and close the discussion once I get a paragraph added. --Maffblaster (talk) 19:08, 26 January 2017 (UTC)