This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Handbook Talk:AMD64/Installation/Disks
User should be warned about making filesystem
User should be warned in section https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Applying_a_filesystem_to_a_partition about that all data on that partition will be removed. (to make it fool-proof for new commers)
--Kreyren (talk) 13:45, 15 September 2018 (UTC)
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!
- Avery , 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)
- Splitting the guide in a similar way as suggested above is a must. A few quick-fixes should be applied ASAP. Suggestions:
- copy the UEFI FAT32 requirement warning to the Creating file systems - users apply all FSs in that part, so it will be noticed there
- separate the
set 1 bios_grub online from the parted cmd list and instruct users about using eitherbios_gruborboot- so they won't end up with both Yuri69 (talk) 21:41, 22 April 2017 (UTC)
- Splitting the guide in a similar way as suggested above is a must. A few quick-fixes should be applied ASAP. Suggestions:
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)
- 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 mkfs.vfat 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 [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 spent 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 spent few hours in UEFI shell debuging this and trying different things.
Vlkodlak (talk) 12:02, 26 January 2017 (UTC)
- Vlkodlak , 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)
Using sgdisk as an easy alternative for disk partitioning for GPT
Lately I've looked into different ways for semi-automatic installation of basic system on quite new enterprise grade hardware. I've spent a lot of time fiddling with GPT, UEFI, ESP and so on because with the 4Kn disks it's a requirement.
Fastest and most easy way I found IMHO is using sgdisk as follows (according to scheme in handbook, however, personally I see no point in using both BIOS boot partition and ESP at the same time unless using both legacy boot and UEFI...):
sgdisk -n 0:0:+2M -t 0:ef02 -c 0:"BIOS Boot Partition" /dev/sda sgdisk -n 0:0:+512M -t 0:ef00 -c 0:"EFI System Partition" /dev/sda sgdisk -n 0:0:+1G -t 0:8200 -c 0:"Swap partition" /dev/sda sgdisk -n 0:0:-100M -t 0:8300 -c 0:"Linux Root" /dev/sda
Those commands will create appropriate partitions on the disk in no time (I always think of using parted or any other menu-based tools for disk partition manipulation as a great pain...). They will create partitions in sequence as they are executed with proper size using next available space. Last command will use all the remaing space but the last 100MB (It's a habit I adapted because of RAID arrays). It also handles boot flags etc on its own, see its man page.
However, those commands can be quite dangerous because there are almost alwaysno confirmations when they are executed. Also, I only tested this using UEFI boot. However, I don't see any reason apparent reason why it won't work with Legacy BIOS unless the firmware is having trouble using GPT for legacy BIOS booting. If someone is interested in these problems then this web site is a very good source, especially this page.
If you think it can be useful for someone using the handbook, please feel free to add it as you see fit.
By the way, if you find it interesting for the handbook, I can give you here some of my notes about using UEFI and ESP in BTRFS RAID1 when I'm done testing it.
--Vlkodlak (talk) 20:57, 26 January 2017 (UTC)
Need some changes based on my experiences
I just built a new system after a long hiatus. I decided to go with UEFI this time. This was not as easy as it should be.
I think the page needs to be re-organized as discussed above, with one track for MBR and a second track for GPT. On the GPT track, we need explicit directions for creating the file system on the boot partition:
emerge dostools mkfs.vfat -F32 /dev/sda2
We also need a warning that it is not possible to complete a UEFI installation using the mimimal CD, or more generally, that a UEFI installation will require that the installing OS must itself be booted from UEFI It is not sufficient that the installing OS is itself UEFI-aware: it must have been booted using UEFI. I suppose that this warning could be done earlier in the manual, but I feel that it should be reiterated here, since this is the first place that the UEFI versus non-UEFI decision is discussed.
While it is useful to create partition labels, I think it should be made clear that partition labels are distinct from file system labels. This is not important here, but is becomes crucial later. /etc/fstab can refer to either the FS label using LABEL=, or the partition label using PARTLABEL=. This page currently recommends partition labels, but it just calls them "labels". I messed this up later in the manual, when I was building my /etc/fstab, and that page should also be changed.
Thanks. -Arch dude (talk) 04:29, 9 March 2017 (UTC)
Boot Partition Sizing
How useful is a 2 mb boot partition?
If building a kernel using genkernel, the boot partition will not be able to contain the kernel and the command will fail during the install step.
--Rage (talk) 4:58, 26 June 2017 (UTC)
- The 1-2 MiB partition is needed for GRUB, not for the kernel. It's a BIOS boot partition, not simply a boot partition. The real boot partition comes next, and of course should be much larger because it must include the kernels. Another difference is that the BIOS boot partition should not be formatted, while the boot partition should be. Fturco (talk) 08:16, 28 June 2017 (UTC)
Mounting the root partition
It is good to mention that if you interrupt the installation process at any stage later (e.g. by rebooting), you need to mount the root partition again. --Wowpetr (talk) 09:01, 12 July 2017 (UTC)
Use correct command for formatting an ESP partition
The Using_UEFI section says "The ESP must be a FAT variant..." and shows the command
root #mkfs.fat -F 32 /dev/sda2
to format the partition. Then, the Applying_a_filesystem_to_a_partition section states
root #mkfs.ext2 /dev/sda2
to format the ESP partition as located in the default partitioning scheme. Should this be changed to mkfs.fat -F 32?
Presently it tells the user to format the ESP partition as ext2 which according to the Using_UEFI section might not work.
--jcarpenter2 (talk) 18:47, 11 August 2018 (UTC)
- Reading carefully you should see the second command you mentioned does not apply to ESP but to »have the boot partition (/dev/sda2) in ext2 and«.
Anything to be adjusted in the EFI System Partition article?--Charles17 (talk) 05:24, 12 August 2018 (UTC)