Handbook Talk:AMD64/Installation/Disks/Archive
The following sections are completed discussions previously found on the Handbook Talk:AMD64/Installation/Disks/Archive page. They have been moved here for archival purposes.
When moving discussions here, try to keep these discussions in chronological order. The date of a discussion's creation can usually be found in the first signature.
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:
- The incorrect information in section "Alternative: Using fdisk to partition the disk" is still confusing users. I don't think there is a rush to do a major restructuring of the article, but, IMO, at the very least, subsection "Creating the BIOS boot partition" should be removed for the reasons already pointed out, and partition table examples in other subsections (and accompanying expanatory text) should show only the root, /boot and swap partitions, starting at sector 2048 to make space for the bootloader. — GuillermoDH (talk) 18:49, 13 February 2021 (UTC)
- These concerns have been addressed. Please let me know if there's anything else lacking or unclear. Thank you. --Maffblaster (talk) 08:24, 20 February 2024 (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)
- 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)
- Revisiting here. We now recommend 1 GB size for the ESP, therefore if handbook readers take this recommendation, then they will not run into limits on larger 4k native drives. Thanks! --Maffblaster (talk) 08:27, 20 February 2024 (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 remaining 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)
- We no longer suggest the use of a BIOS boot partition. fdisk from utils-linux works well for either EFI/GPI or legacy BIOS/MBR setup and is included in Gentoo live environments. We will not detail another disk utility tool at the moment, but if we did it would be parted. Thanks! --Maffblaster (talk) 00:46, 20 February 2024 (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)
- I agree that offering separate instructions for MBR and GPT could ease the navigation and understanding for newcomers. The usual "careful reading necessary" is an added burden that could be avoided. Although I am completely new to linux, I was able to complete a GPT partitioning scheme by "carefully reading" the entire section but at the cost of an extra 10 minutes of reading. Separate instructions wouldn't hurt and help in the overall adoption of gentoo.
- About the "dos tools" it is not necessary. As of today, dosftools are included in the minimal install "CD".--Neyuru (talk) 17:57, 5 April 2020 (UTC)
- The minimal Gentoo live environments do indeed support EFI mode now, so there is no longer an issue. The Handbook does now provide instructions for EFI/GPT and legacy BIOS/MBR setups. The handbook does explicitly mention partition labels and partition UUIDs, but does not recommended using PARTLABELs in fstab, since it doesn't recommended setting any labels... we'll leave that part to other places on the wiki. Thanks! --Maffblaster (talk) 08:33, 20 February 2024 (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)
- Please add a short explanation to the Handbook. When and how do we exactly need the 2 MB?--Jonas Stein (talk) 23:59, 23 May 2020 (UTC)
- The handbook no longer suggests the use of a BIOS boot partition (only needed when using GRUB with a particular, niche hardware configuration). This discussion is stale. --Maffblaster (talk) 00:41, 20 February 2024 (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)
- Added a tip here: Special:Diff/1282910/1282914. Thanks! --Maffblaster (talk) 06:40, 20 February 2024 (UTC)
Finding this topic still open, I would like, in a spirit of appreciative collegiality, to add observations and suggested edits of my own to Wowpetr's above.
As a new user working my way through the Handbook, I am in a good position to notice where the Handbook is vague, not literally accurate, or could be more helpful. Mounting the root partition is such a section.
"Use the mount command, but don't forget to create the necessary mount directories ..."
For a reader unfamiliar with gentoo, it is not a matter of forgetfulness. The Handbook is silent on what directories are "necessary" and where they should be created. An example involving a second mount directory, or explanatory text, could suffice to put the reader on the right track.
"... for every partition created."
Further, it is not literally true that a directory is needed for "every" partition created, but only for non-boot, non-swap partitions that will actually be mounted. I suggest the authors/editors change the wording to make this clear.
A comment in Gentoo Forums, Installing Gentoo, root partition / mounting directly after creating partitions, by cboldt, Thu Apr 20, 2017 8:32 pm, was helpful in clarifying this matter for me.
--VetusDonatus (talk) 19:55, 9 July 2022 (UTC)
- VetusDonatus, mentioned that mounting additional partitions may be necessary. See Special:Diff/1282697/1282909. --Maffblaster (talk) 06:40, 20 February 2024 (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)
- I tend to agree with the OP. At the very beginning of the entire page a warning looms: "If a FAT variant is not used for the ESP, the system's UEFI firmware is not guaranteed to find the bootloader (or Linux kernel) and most likely be unable to boot the system!" and the instructions offer: "The instructions for parted below contain the necessary pointers to correctly handle this operation." which is not entirely accurate because no specific instructions for the ESP in UEFI are given anywhere below. Furthermore, the webpage clearly states: "The Handbook authors suggest using GPT whenever possible for Gentoo installations." but as previously shown, the final example (the one the OP comments) applies to MBR not GPT partitioning. An obvious solution would be to cut and paste the section Using UEFI from the beginning of the webpage to somewhere in the subsection Applying a filesystem to a partition at the end of the webpage, probably after the statement "For instance, to have the boot partition (/dev/sda2) in ext2 and the root partition (/dev/sda4) in ext4 as used in the example partition structure, the following commands would be used:", creating one example for MBR (the one shown) and another for GPT (with the correct instruction mkfs.fat -F 32 /dev/sda2).--Neyuru (talk) 18:18, 5 April 2020 (UTC)
- Its seems like inserting links from the grub2 page such as GRUB#Partitioning_for_UEFI_with_GPT could alleviate this. --Snakejr (talk) 08:21, 11 September 2020 (UTC)
- This discussion is stale. The AMD64 and X86 handbooks are better on EFI/GPT and legacy BIOS/MGR disklabel. Please reopen if there's anything outstanding. Thanks! --Maffblaster (talk) 00:40, 20 February 2024 (UTC)
User should be warned about making filesystem
User should be warned in section Handbook:AMD64/Installation/Disks/Archive#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)
- I think this is inherent in filesystem creation, however I have added this note: [[Special:Diff/1282288/1282689}}. Thanks! --Maffblaster (talk) 00:34, 20 February 2024 (UTC)
Standardise to UEFI examples
Hi Handbook team,
I wondered if it is time to standardise on UEFI and ensure all the defaults are for UEFI.
I ran through the instructions for a new install and although I read about needing VFAT for booting UEFI I missed that the example actually used ext2.
root #mkfs.ext2 /dev/sda2
It was only when the Grub install command reported the /boot partition was not UEFI ready that I realised what had happened. I had enough knowledge to change the partition type reformat it and reinstall the kernel to it, but I am worried that someone else may not.
Thank you for considering my suggestion. --Bluenuht (talk) 21:35, 14 November 2019 (UTC)
- It is mentioned in the Using UEFI section. But I agree having a reminder in the Applying a filesystem to a partition section or even harmonizing the latter with the first would be beneficial.
- --Charles17 (talk) 08:30, 15 November 2019 (UTC)
- IMHO "careful reading" is not a good excuse to not make any modifications. This particular section, can be greatly enhanced if only the subsection Using UEFI is moved farther below in the Applying a filesystem to a partition subsection. The current positioning of the Using UEFI subsection has no place in the surrounding text. It currently violates the wiki guideline "Sections should be added on an as-needed basis. In other words, new sections should not be added until there is content with which to fill them. "--Neyuru (talk) 18:43, 5 April 2020 (UTC)
- I ran into *exactly* this issue today. I've done many Gentoo installations over the years, and consider myself very experienced with Gentoo. Nevertheless, despite doing my usual careful read and following of the Handbook, I mistakenly made my boot partition ext2 instead of vfat. It's fine to keep the UEFI vfat reminder text where it is, but I think it would be very helpful to have it partially duplicated during the `mkfs` section of the page, repeating that UEFI systems should have the `/boot` partition formatted with fat32. :--Pistos (talk) 07:18, 17 May 2020 (UTC)
- I concur with the idea that there should be a UEFI/GPT-only description. Could that be addressed by splitting off AMD64/MBR into a different handbook, or a footnote, or conversely do a "AMD64 for new systems or users" containing only the most straight-forward setup - UEFI/GPT, ext4, grub, desktop profile - i.e. forget about choice to get the newcomer started faster? Or is this an inordinate amount of extra work and complexity?--Goverp (talk) 19:16, 14 March 2021 (UTC)
- The EFI/GPT vs. Legacy BIOS/MBR disklabel situation has been fixed. It is more delineated, clear, and more modularized now. Thank you! --Maffblaster (talk) 00:38, 20 February 2024 (UTC)
Add some text about NVME in section 'Block devices'
Giving NVME devices are more and more popular, is it possible to add some description about NVME device in section Block devices? Such as '/dev/nvme0n1*', and give an example instruction to check it on the machine, such as 'lsblk -o MODEL,NAME,SIZE' or simply 'lsblk'. Shunlir (talk) 02:18, 28 February 2020 (UTC)
- Looks like Andreas K. Hüttel (Dilfridge) handled this request back in May, 2020. See Special:Diff/852359/867428 --Maffblaster (talk) 17:01, 12 October 2021 (UTC)
User should be guided creating BIOS boot partition
The UEFI Partitioning section mentions to create /dev/sda1. However, the remainder of the book does not mention how and where it is used (e.g. how to format and where, when and how to mount). This leads to confusion when installing grub2.
Markjolesen (talk) 01:13, 14 May 2020 (UTC)
- But that's the point. A user should NOT format nor mount a "BIOS boot partition". --Grknight (talk) 17:17, 14 May 2020 (UTC)
- And it should not be Mark the partition for UEFI purposes as presently written in Creating the BIOS boot partition. That sentence might be moved to the next section?--Charles17 (talk) 07:03, 15 May 2020 (UTC)
- BIOS boot partition is no longer recommended/suggested in the handbook since it's such a niche case and generally unnecessary. It now clearly delineates Legacy BIOS from EFI firmware steps. Thank you! --Maffblaster (talk) 06:23, 19 February 2024 (UTC)
Explain only one tool for partitioning (explain parted, remove fdisk)
Handbook:AMD64/Installation/Disks/Archive#Default:_Using_parted_to_partition_the_disk default parted and alternative fdisk result in different partitions at the moment. I suggest simply to delete the fdisk part, as long there is no important benefit. We do not explain how to use any of the other partitioning tools too and we see that it is difficult to keep it in sync. --Jonas Stein (talk) 00:06, 24 May 2020 (UTC)
- A fix was provided (explain fdisk, remove parted : Special:Diff/929472). --Blacki (talk) 19:12, 15 July 2022 (UTC)
ext2/fat32 for /boot
The handbook is not consistent in the examples about using ext2/fat32 for /boot --Jonas Stein (talk) 00:11, 24 May 2020 (UTC)
- This was fixed long ago. --Maffblaster (talk) 01:45, 18 February 2024 (UTC)
Suggestions for Improvement
Quoted material is from Preparing the disks.
"Unless a extended partition is created, DOS disklables supports a maximum of four partitions."
Ungrammatical, and there are two mispelled words:
Unless an extended partition is created, DOS disklabels support a maximum of four partitions.
"... there is practically no limit on the amount of partitions for a GPT disk. Also the size of a partition is bounded by a much greater limit (almost 8 ZiB - yes, zettabytes)."
The number of partitions is discrete {1, or 2, or 3, etc.}. The second sentence is very wordy, and badly punctuated. I suggest
...there is practically no limit on the number of partitions for a GPT disk. Also, the maximum partition size is much larger (almost 8 ZiB -- yes, zettabytes).
"Newcomers beware: although fully supported LVM is outside the scope of this guide."
Strike "although" -- it's not just superfluous; it is confusing.
Newcomers beware: fully supported LVM is outside the scope of this guide.
- A fix was provided (Special:Diff/897200). --Blacki (talk) 02:10, 17 July 2022 (UTC)
"If this suffices and the reader going the GPT route ..."
A word has been omitted:
If this suffices and the reader [is] going the GPT route ...
- A fix was provided (Special:Diff/929445). --Blacki (talk) 02:10, 17 July 2022 (UTC)
"If a FAT variant is not used for the ESP, the system's UEFI firmware is not guaranteed to find the bootloader (or Linux kernel) and most likely be unable to boot the system!"
A word has been omitted.
... the bootloader (or Linux kernel) and [will] most likely be unable to boot the system!
- A fix was provided (Special:Diff/929463). --Blacki (talk) 02:10, 17 July 2022 (UTC)
"Now that the partitions are created, it is time to place a filesystem on them."
How can one filesystem occupy multiple partitions?
Now that the partitions are created, it is time to add a filesystem to each one. Or
Now that the partitions are created, it is time to place filesystems on them.
Enough for today, already. Back again tomorrow. --Davidbryant (talk) 19:43, 22 July 2020 (UTC)
Picking up where I left off.
"Those who like the user interface of fdisk can use gdisk (GPT fdisk) as an alternative to parted."
I cannot find the program "gdisk" on my copy of the minimal installation CD. Why mention it if it can't be used?
- A fix was provided (Special:Diff/929445). --Blacki (talk) 02:10, 17 July 2022 (UTC)
"Although recent fdisk should support GPT, it has still shown to have some issues with it."
Clumsy syntax, and a missing word. I suggest
Although recent fdisk should support GPT, there are still some issues with it."
I'm also curious what those issues are. It appears as if this admonition may no longer be needed. I have hunted in vain for any current bug reports about fdisk. Just sayin'.
- A fix was provided (Special:Diff/929472). --Blacki (talk) 02:10, 17 July 2022 (UTC)
"This will generally quadruple the number of inodes for a given file system as its "bytes-per-inode" reduces from one every 16kB to one every 4kB. This can be tuned even further by providing the ratio:"
root #mkfs.ext2 -i <ratio> /dev/<device>It took me quite a while to understand what this ratio ought to be. I finally chased it down in the man pages --
Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since in that case more inodes would be made than can ever be used. Be warned that it is not possible to change this ratio on a filesystem after it is created, so be careful deciding the correct value for this parameter. Note that resizing a filesystem changes the number of inodes to maintain this ratio.
I think some clarification is needed.
This can be tuned even further by providing the ratio bytes-per-inode. Do not make this ratio too small -- it should be 512 at a minimum, and at least 4,096 for larger (>512MB) hard disk devices.
root #mkfs.ext2 -i <ratio> /dev/<device>That's it for this chapter of the "Handbook". --Davidbryant (talk) 15:36, 23 July 2020 (UTC)
- Handbook now suggests using ext4, and passing
-T smallat creation time for smaller partitions/filesystems. This solves the problem with inodes. Thank you! --Maffblaster (talk) 01:01, 20 February 2024 (UTC)
Reiserfs
Reiserfs is included in mainline Linux kernel --Nikitastepanov (talk) 11:17, 30 August 2020 (UTC)
- Duplicate of Handbook Talk:Parts/Installation/Disks#Reiserfs (as this page inherits that article) --Grknight (talk) 13:17, 31 August 2020 (UTC)
Gentoo ebuild repository default location
The subsubsection "How many partitions and how big?" of the Subsection "Designing a partition scheme" of Section "Introduction to block devices" of the Gentoo AMD64 Handbook reads: "In most situations, /usr/ is to be kept big: not only will it contain the majority of applications, it typically also hosts the Gentoo ebuild repository (by default located at /var/db/repos/gentoo) which already takes around 650 MiB."
This is completely misleading as to where the Gentoo ebuild repository should be located. At least, it raises the following questions:
- Does the Gentoo ebuild repository default location is /var/db/repos/gentoo but virtually everybody relocate it to /usr/ during the installation process?
- Why not change its default location to /usr/ in this case?
I have asked these questions on gentoo-user mailing list and got the answer that the Gentoo ebuild repository was historically in /usr/portage, it's now in /var/db/repos/gentoo.
Moreover, I was told that the handbook maintainers would appreciate a patch or a bug. So, I decided to check if it indeed so. :)
In my view, if the explanation above was correct, the quoted phrase should be re-formulated to completely exclude any mention of the Gentoo ebuild repository as irrelevant, for example, as follows: "In most situations, /usr/ is to be kept big as it contains the majority of applications."
Moved here from bug #760321. Moved by --Jonas Stein (talk) 14:25, 3 January 2021 (UTC)
- This section has been rewritten and I've also commended on source bug bug #760321. Thank you for forwarding the bug here so we found it, Jonas Stein (Jstein) ! See this diff: Special:Diff/842471/917809 --Maffblaster (talk) 19:23, 4 January 2021 (UTC)
Forget about ext2 and ext3 already?
There's not a lot of point in mentioning ext2 or 3 these days; ext4 is almost always better, and if you really want to save the journal space you can configure it without one. I'd even go so far as to drop jfs and Reiser except perhaps with a link to a discussion elsewhere; I guess this depends on whether you consider the handbook as a guide for new users, or as also a reference for old hands.
I think the reference to ntfs should appear in a different paragraph, as it's not viable for a working linux system or home directory; similarly vfat/fat32 are only needed for (a) EFI system partition or (b) interchange. (at which point case folding support could rear its head - as an ex IBM sysprog, I'd actually prefer case folding, but I don't have the courage to try it!). Goverp (talk) 19:16, 14 March 2021 (UTC)
- Paul Gover (Goverp) , thank you for the thoughts. You're right, we probably can link to the Filesystem article if we have not already in the Handbook so that our users can see an article that's updated by the community. I will remove the references to ext2 and ext3, since they are covered in the aforementioned article.
- As for NTFS and vFAT, they are both included in the kernel at this time (with the Paragon adding in-kernel support as of Linux 5.15). I think it is important to keep these options - but perhaps draw more attention to why a user would include partitions of these filetypes: EFI partitions and data interchange as you mention above. --Maffblaster (talk) 18:03, 12 October 2021 (UTC)
A section on adding linux to an existing Windows setup
OK, it would open a can of worms, but there should be at least a pointer to a different article for anyone wishing to add linux to a Windows machine? Neophytes will almost certainly have an existing OS to fit Gentoo alongside, almost certainly Windows. Typically, this would be a laptop or packaged desktop with a preinstalled Windows system. In which case the process is to (a) resize Windows smaller, (b) create swap and linux partitions per usual, (c) get fstab right and (d) hope grub-install sorts it all out. Goverp (talk) 19:16, 14 March 2021 (UTC)
- I do not think this would be appropriate since it basically boils down to resizing some partitions and making sure Gentoo is on an MBR partition. Users should intuitively know what to do after their first Gentoo install. Even if not then, at best this would be its own article.Shidouuu (talk) 00:31, 18 August 2023 (UTC)
- Guides exist elsewhere on the wiki. The Handbook project will not cover dual boot scenarios at this time. --Maffblaster (talk) 01:00, 18 February 2024 (UTC)
Recommendation on swap scape is outdated
"As a general rule, the swap space size is recommended to be twice the internal memory (RAM)."
Is that really true? Consider a machine with 64 GB RAM. Does it really need 128 GB swap space?
Red Hat's recommendation (see Table 15.1. "Recommended System Swap Space" on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace) seems to make more sense.
See https://forums.gentoo.org/viewtopic-p-8649772.html#8649772 as well.
Mike155 (talk) 18:55, 21 August 2021 (UTC)
- Implemented a table which should help our readers make a more informed and reasonable choice when determining swap sizes. See: Special:Diff/1214646/1282171. Thanks! --Maffblaster (talk) 01:42, 18 February 2024 (UTC)