Handbook Talk:AMD64/Installation/Disks
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~
), and indent successive comments with colons (:
).
Add new sections at the bottom of the page, under a heading (== ==
). Please remember to mark sections as "open for discussion" using {{talk|open}}
, so they will show up in the list of open discussions.An important note for Handbook editors: most of the discussion points on this page will be concerning the content in the Parts Handbook.
Some closed discussions have been moved to an archive subpage: Handbook Talk:AMD64/Installation/Disks/Archive.
GPT: Note about Windows needs to be corrected...
Under GUID Partition Table (GPT), the note says:
- Using GPT on a BIOS-based computer works, but then one cannot dual-boot with a Microsoft Windows operating system. The reason is that Microsoft Windows will boot in UEFI mode if it detects a GPT partition label.
This is wrong, because the logic is reversed. The boot mode is not determined by the partition table. At the stage where Windows (or its boot loader) takes over, the boot mode is a given. (And "Windows will not boot in UEFI mode if it detects a GPT partition label"... It simply cannot change the boot mode that easily...)
The opposite is true: When Windows is booted in BIOS mode (UEFI CSM), it will refuse to boot unless the system partition is a legacy MBR partition. Likewise Windows will refuse to boot in (U)EFI mode when the partition is not a GPT partition. This is even then the case when the partition used for \WINDOWS is absolutely accessible during the boot process (in which case the refusal to continue is simply a design decision)...
Correct is:
- BIOS → MBR
- (U)EFI → GPT
Wrong is:
- MBR → BIOS
- GPT → UEFI
However, it is also true that certain UEFI implementations will start the CSM if a (hybrid) MBR (or at least more than just a protective MBR) is detected. Notably certain Macs use this method, most likely for Boot Camp to function correctly. Most PCs use a manual method: if a CSM is loaded or not has to be enabled or disabled in the firmware setup. Thus UEFI on a PC will always be in (U)EFI mode, even with an MBR, when the CSM is disabled in the firmware setup. And the boot option for a legacy MBR, with CSM enabled, will always end up in BIOS mode, which will only load the boot block, block 0, which is the (protective) MBR, even when using a GPT (like with GRUB and a "BIOS boot partition", or to e.g. boot Windows in legacy/BIOS mode using hybrid partitioning on a Mac).
See also: GRUB#Dual-boot with Windows
Suggestion for correcting the note:
- Using GPT on a BIOS-based computer works, but then one cannot easily dual-boot with a Microsoft Windows operating system. The reason is that Microsoft Windows has to be booted in UEFI mode to use a GPT partition as its system partition.
Luttztfz (talk) 10:46, 10 October 2021 (UTC)
- TL;DR:
- Under GUID Partition Table (GPT), the note says:
Using GPT on a BIOS-based computer works, but then one cannot dual-boot with a Microsoft Windows operating system. The reason is that Microsoft Windows will boot in UEFI mode if it detects a GPT partition label.
- This is false — the firmware determines whether the OS boots in UEFI or BIOS mode, usually based on whether CSM/legacy boot is enabled. What Windows actually does is refuse to boot if it's not on a BIOS+MBR or UEFI+GPT setup.
- Proposed changes - Please make edits here until a final revision is agreed upon.
Using GPT on a BIOS-based computer works, but the user won't be able to dual-boot with a Microsoft Windows operating system, since Microsoft Windows refuses to boot from a GPT partition when in BIOS mode. - — glibg10b 19:51, 2 April 2024 (UTC)
Outdated description of f2fs
Under Handbook:AMD64/Installation/Disks it says 'As of Q2, 2016, this filesystem is still considered immature...', should this be updated?
Jmcb (talk) 14:51, 8 December 2021 (UTC)
- I agree this isn't right nowadays. I've fixed that now at Special:Diff/1246975. --Sam (talk) 07:10, 30 June 2023 (UTC)
No remark to remember to set boot flag
In the section Handbook:AMD64/Installation/Disks, there is nothing to indicate that it is necessary to set the boot flag on the first partition, and fdisk does not appear to automatically do this. I (and looking at forum threads a few other gentoo newbies) got stuck on this for a while, and although I eventually fixed it, I lost a lot of motivation and would have been a lot more excited if first boot instantly worked. I think a reminder should be added to set the boot flag. Esoteridesu (talk) 14:15, 21 February 2022 (UTC)
- The boot flag, assuming you are talking about MBR tables here, is a relic and most systems do not need it. That is why it is not mentioned. Linux never needed this and it is often ignored. You likely changed something else beyond this to get your system going. --Grknight (talk) 14:30, 21 February 2022 (UTC)
- I do not know which systems need it, however my laptop could not boot without the flag set and I am positive it is the only thing I changed. (my laptop is based on Intel Sandybridge architecture and is from approx. 4 years ago, so fairly recent. Esoteridesu (talk) 15:04, 21 February 2022 (UTC)
- The Handbook does now have a step for setting the bootable flag on the MBR (DOS) disklabel disk. --Maffblaster (talk) 00:04, 18 February 2024 (UTC)
Its unclear that mkfs.ext4 /dev/sda3 should be ran
In Handbook:AMD64/Installation/Disks, under Applying a filesystem to a partition the reader should more directly be told to mkfs.ext4 on /dev/sda3. It is told to make the filesystem on /dev/sda3 but the impression is given that you should only do that with an EFI system. Perhaps the two commands given for EFI systems should be refractered to just the first one leaving the second command as a one that should be ran regardless? timestamp
Officereso (talk) 23:07, 4 April 2022 (UTC)
- There is an explicit command to format the rootfs now. --Maffblaster (talk) 23:37, 17 February 2024 (UTC)
Increase boot partition suggested size
256M seems low to me nowadays for this. I frequently run into the partition filling up, with five kernels or less, and if I'm not careful it crashes the gentoo-kernel emerge. Some people on IRC seem to agree, and suggest that some kernels have got bigger over time... -- Ris (talk) 16:24, 17 November 2022 (UTC)
- I've gone ahead and changed this to 1GB given both what you've said & our new recommendation of XFS too. Thanks! --Sam (talk) 07:09, 30 June 2023 (UTC)
Don't imply that /boot must be separate partition ?
I remember installing a system, and including /boot on the root partition. I liked it: I didn't have to worry about mounting /boot, or running out of space. I'm on ext4 so grub and most other things just handle it.
Last time I installed Gentoo though, I remember thinking "well, the handbook says to use a separate boot partition, so I better should". Could we suggest the option of having /boot as part of root partition ? -- Ris (talk) 16:33, 17 November 2022 (UTC)
- I recently updated the instructions on EFI System Partition to include some autofs magic for the best-practice management of /boot (automatic mounting and unmounting). Does that address at least some of your issues with the guidance?
- Agree though: We should have an article that consolidates all of the information about different /boot and /efi configurations into one place and goes over the pros and cons to enable users to make a suitable discussion - it probably doesn't need to be _in_ the handbook either, just linked to from it to enable informed decision making.
- Off the top of my head I can think of the following cases that should be documented:
- ESP mounted to /efi; /boot on rootfs
- ESP at /efi and shared(?) XBOOTLDR at /boot
- /boot and /efi on removable media (subtype of the above?)
- Monolithic ESP mounted to /boot
- We need to update our docs to use autofs or systemd-automatic mounts for /boot and /efi anyway, so it might be worth consolidating that information
- Due to some recent updates, the handbook no longer suggests /boot as a separate partition when using an EFI/GPT setup. In my opinion, autofs stuff is beyond the scope of the handbook, and I don't think we need to cover all the cases outlined by Kangie above. Only the possible locations already detailed in the disks sections from a fresh install. It maybe something to consider in the Complete Handbook, however... --Maffblaster (talk) 00:56, 20 February 2024 (UTC)
/mnt/gentoo is lacking also in Gentoo LiveDVD
I am not sure if it's a bug in LiveDVD generation or we should simply suggest people to create the directory (over current suggestion pointing to it being needed only in non-Gentoo media Handbook:AMD64/Installation/Disks#Mounting_the_root_partition)
Thanks --Pacho (talk) 14:47, 16 October 2023 (UTC)
- This has been fixed with this change: Special:Diff/1278126/1282144. --Maffblaster (talk) 23:27, 17 February 2024 (UTC)
Update ESP text
The current text says
When installing Gentoo on a system that uses UEFI to boot the operating system (instead of BIOS), then it is important that an EFI System Partition (ESP) is created.
This would be better as:
When installing Gentoo on a system that uses UEFI to boot the operating system (instead of BIOS) it is essential that an EFI System Partition (ESP) is created.
The "(instead of BIOS) can probably go too, but I've left it in for now -- Kangie (talk) 05:58, 18 October 2023 (UTC)
- Done, thanks! See Special:Diff/1281487/1282147. --Maffblaster (talk) 23:35, 17 February 2024 (UTC)
XFS warning
In the "Creating file systems" section, there's a warning that says
[...] Some Intel SSDs in particular (600p and 6000p) require a firmware upgrade for critical bug fixes avoid data corruption induced by XFS I/O usage patterns (though not through any fault of the filesystem). [...]
Aside from the sentence being ungrammatical, since the main topic of the hyperlink are the reported bugs, not the "critical bug fixes" as it says, I think it'd make more sense to say
"Some Intel SSDs in particular [...] require a firmware upgrade for possible data corruption induced by [...]".
--Ppw0 (talk) 17:41, 7 February 2024 (UTC)
- Implemented. See Special:Diff/1282689/1282697 Thanks! --Maffblaster (talk) 00:52, 20 February 2024 (UTC)
Commands missing /mnt/gentoo in their paths
The four commands in "Mounting the root partition" subsection of the "Preparing the disks" Section of the AMD64 Handbook are broken due to missing "/mnt/gentoo". The commands in Handbook:Parts/Installation/Disks are correct.
"mkdir --parents" Should be "mkdir --parents /mnt/gentoo"
"mkdir --parents /efi" Should be "mkdir --parents /mnt/gentoo/efi"
"mount /dev/sda3" Should be "mount /dev/sda3 /mnt/gentoo"
"chmod 1777 /tmp" Should be "chmod 1777 /mnt/gentoo/tmp"
Goobernetes (talk) 01:58, 19 February 2024 (UTC)
- Fixed for AMD64 and X86. I just had missed setting one of the properties due to late night editing. Thank you for pointing that out! --Maffblaster (talk) 06:20, 19 February 2024 (UTC)
Creating /mnt/gentoo/efi before mounting rootfs to /mnt/gentoo
the instructions instruct to create /mnt/gentoo and then /mnt/gentoo/efi (and others) before mounting the root partition to /mnt/gentoo. MihailMihov (talk) 21:16, 7 March 2024 (UTC)
- I propose simply moving that part after the mounting of the root partition.
- The variables don't render on this talk page, but the MediaWiki in this proposal can be copied verbatim to Handbook:Parts/Installation/Disks#Mounting the root partition.
<!-- T: -->
comments have been kept with their respective paragraphs.
Certain live environments may be missing the suggested mount point for Gentoo's root partition (), or mount points for additional partitions created in the partitioning section:
root #
mkdir --parents
Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.
With mount points created, it is time to make the partitions accessible via mount command.
Mount the root partition:
root #
mount
For EFI installs only, the ESP should be mounted under the root partition location:
root #
mkdir --parents
- For easy examination, here's the above proposal with the variables substituted in:
Certain live environments may be missing the suggested mount point for Gentoo's root partition (/mnt/gentoo), or mount points for additional partitions created in the partitioning section:
root #
mkdir --parents /mnt/gentoo
Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.
With mount points created, it is time to make the partitions accessible via mount command.
Mount the root partition:
root #
mount /dev/sda3 /mnt/gentoo
For EFI installs only, the ESP should be mounted under the root partition location:
root #
mkdir --parents /mnt/gentoo/efi
- — glibg10b 20:13, 2 April 2024 (UTC)
- Change 1 of 2: (the 2nd change must be done in "Installing the Gentoo base system") .Please delete this (checked by @negril and me) because it is handled in "Preparing for a bootloader - UEFI systems":
For EFI installs only, the ESP should be mounted under the root partition location: root #mkdir --parents /mnt/gentoo/efi Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command. With mount points created, it is time to make the partitions accessible via mount command.
-- Pietinger 14:50, 17 April 2024 (UTC) with help from @negril in IRC TODAY