Handbook Talk:AMD64/Installation/Disks
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 00:47, 12 January 2025 (UTC) :: Your reply ~~~~
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.
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/gentooContinue 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/gentooFor EFI installs only, the ESP should be mounted under the root partition location:
root #mkdir --parents /mnt/gentoo/efi- — Waldo Lemmer 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
- Fixed in Special:Diff/1305360/1313987, thanks!
- --csfore (talk) 15:36, 20 September 2024 (UTC)
DSP specification doesn't need Partition UUID set to Type UUID
'Partitioning the disk with GPT for UEFI section' has each 'Creating the X partition bit' contain the instruction "Optionally, to have the ESP conform to the Discoverable System Partition (DSP) specification, switch to expert mode and perform the following extra step to set the partition's UUID", with the partition uuid set to the same as the type uuid for that partition type using the expert interface of fdisk.
The only instruction in the specification (https://uapi-group.org/specifications/specs/discoverable_partitions_specification/) for Partition UUID is for the Verity partitions and is not to set it to the type uuid. The only other mention of partition uuid is in the faq and is referring to the partition type uuids being platform-specific.
I believe the "Optionally, to have the root partition conform ..." bits should just be removed.
Peter (talk) 10:36, 21 June 2024 (UTC)
- Yes, I think so too. See also the Handbook Talk:Main Page discussion Do I need to modify PARTUUID to conform DPS?
- The partition UUID that is unique for every partition and that is random doesn't have to be the same in any way. The only thing that matters specification-wise is the partition type, which happens to be a UUID as well. The confusion seems to stem from too many UUIDs, because the partition table itself has one too, as has the filesystem.
- GPT (partition table): has a unique UUID, random at time of creation, so every GUID partition table is distinguishable. lsblk:
PTUUID - partition type: standardized UUID defining the type of every partition. This is the one, we're interested in, and only this one. lsblk:
PARTTYPE - partition (unique) UUID: random at time of creation, makes every partition distinguishable. lsblk:
PARTUUID - file system UUID: only for filesystems that support this, but most do. This can be different for different filesystems. Linux translates these unique filesystem identificators to a unique UUID, i.e. it can be found in /dev/disk/by-uuid/* and can be referred to in /etc/fstab (with UUID=); lsblk:
UUID. Example: FAT uses a A0B1-89EF type of "volume identifier" (4 bytes in hex 00 to FF, in two groups of two with a dash in between), while NTFS uses double (8 bytes) in the form of 0123456789ABCDEF (no dashes, no groups). Most Linux filesystems use a UUID. The form of a UUID is standardized, i.e 128 bit integer, most commonly displayed as URN in the form 8-4-4-4-12 (i.e. five groups of hexadecimals of different lenghts, with dashes).
- GPT (partition table): has a unique UUID, random at time of creation, so every GUID partition table is distinguishable. lsblk:
- As a side note: If you have ever copied a Windows installation from one drive to another, and in the process you happen to have rearranged partitions (but not the first part where Windows is installed) and did that by manually recreating the partition structure, you may have found that Windows would not boot. Even though it seems that everything is exactly the same, the unique UUIDs are not, namely the GPT unique UUID itself (every time you create a new GPT, it gets one randomly assigned, lsblk: PTUUID) and the unique UUID of each created partition (lsblk: PARTUUID). Thus, if you list the partition table, you'd have the same layout, sizes, everything... except for the unique UUIDs, which are NOT normally listed.
- And this is what I could find out: if you manually set those unique UUIDs, Windows will boot just fine after being transferred to a new drive. Thus, it seems like the BCD store does identify configured Windows boot entries also by the unique partition UUID, and fails otherwise, because it cannot find the "system/boot partition" (which is where C:\WINDOWS is located).
- TL;DR Delete. The unique partition UUID (PARTUUID) is NOT the same as the partition type (PARTTYPE, which happens to be a UUID as well, but this one is what the specification is referring to, the one that has to follow the specification)...
- Luttztfz (talk) 10:58, 22 June 2024 (UTC)
- Fixed in Special:Diff/1316835/1316836, thanks!
- --csfore (talk) 18:27, 23 October 2024 (UTC)
Units in Byte
When prompted for the last sector, type +1G to create a partition 1 GByte in size:
should be rewritten to:
When prompted for the last sector, type +1G to create a partition 1 gibibyte in size:
And,
almost 8 ZiB -- yes, zettabytes
should be rewritten to:
almost 8 ZiB -- yes, zebibytes
--Duxsco (talk) 21:55, 6 September 2024 (UTC)
- Fixed in Special:Diff/1308887/1316776, thanks!
- --csfore (talk) 22:08, 19 October 2024 (UTC)
BTRFS as the default Gentoo filesystem
I noticed that Gentoo switched from ext4 to xfs the last time I looked at the handbook; this was due to a discussion on the #gentoo-wiki IRC. I agree that xfs is better than ext4 mainly due to its Copy-on-Write (CoW) feature; but this had me wondering why not btrfs?
There are some features btrfs has that I think Gentoo could take advantage of:
- CoW filesystem (just like xfs and can take advantage of reflinks)
- Transparent compression (can be used for directories such as /var/cache/distfiles to shrink the stored source-code of packages)
- Asynchronous discards (better discard performance and can help with the lifespan of SSDs)
- Online filesystem resizing (both shrink and growth)
- Checksumming without fsck (the checksum is calculated before writing and verified after reading the blocks from devices)
- Auto-repair on read (this is only true for "metadata" and "system" because they are set to DUP by default; "data" needs to be explicitly set for DUP)
There are other features that btrfs has, but I don't think they contribute much to Gentoo (I could be wrong; I'm just a user). From my research, the only advantages xfs has over btrfs are:
- longer reputation
- faster in certain workloads
I'm sure there's someone smarter than me that can explain why xfs was chosen, or why btrfs was never considered; either way, I'd like to start a discussion of why we should continue to use xfs or switch to btrfs or something else.
FlyingBullets (talk) 19:51, 2 December 2024 (UTC)
- It's a fair and reasonable question. Someone asked me about this a month or two ago. XFS was an obvious upgrade over ext4 because we gained CoW functionality while only losing shrinking. It's still a traditional FS in the same way that ext4 is, and the way that btrfs and zfs aren't - in that they both handle volume management and so on themselves.
- btrfs still unfortunately has major showstopper bugs in the kernel which I hit myself. For example, it was only two (?) kernel releases ago where balance was broken and would end up eating much of the metadata space on the disk. Bugs of course happen everywhere but it lasted a while even after it was reported and the fix took a while to trickle down to releases.
- That brings me to one of my other concerns: btrfs requires maintenance in a way that other filesystems don't. btrfs and zfs both require balancing / scrubbing which requires people to adjust their sysadmin habits. In turn, that involves the handbook needing a bunch of changes too.
- Because of its "non-traditional" properties, we'd also need to rework a bunch of the handbook. That's not a reason not to do it by itself, but it's a reason to be put off doing it. It would definitely involve figuring out a recommended subvolume scheme including some naming conventions.
- Note that compression isn't going to be useful at all for distfiles given that they're almost always compressed already.
- One of my bigger concerns would be that the handbook is often too complex to follow as it is. Having to cover a new generation of FS would complicate it further.
- I think we might end up changing at some point, but I don't really feel like the benefits are compelling, obvious enough, and overwhelming s.t. it'd be nearly wrong to not change. There may be more or better reasons, but this is what came to mind from recalling the last time someone asked about this privately. --Sam (talk) 20:48, 2 December 2024 (UTC)
- I see your point across your several statements -- yeah, btrfs has a bunch of features that new users might find confusing; but no one has to use those features. Personally, the only changes I made to my installation script was change
mkfs.ext4tomkfs.btrfsand modify the fstab file. With the latest kernel and btrfs version, most of the features get applied on mount (async discard, etc...) without additional configuration.
- I see your point across your several statements -- yeah, btrfs has a bunch of features that new users might find confusing; but no one has to use those features. Personally, the only changes I made to my installation script was change
- I considered btrfs, as well as any other filesystem, to be a "set it and forget it" type filesystem; especially after what I read on btrfs.readthedocs.io. I might be misunderstanding the low-level details, but the docs seem to present btrfs as a filesystem that takes care of itself (due to the list of features I listed in my original post).
- I saw that there's a package (sys-fs/btrfsmaintenance) for things like balancing and scrubbing, but these manual tasks seem optional or are for sanity checks.
- Update: okay, now I'm starting to see what you mean with the whole balancing issue -- there's a difference between "free space", "data/metadata/system space/chunk", and "workspace". Problems can arise when the drive fills up and "data" and "system" say that there's available space, but there's no more metadata space/chunks -- thus, it needs to be re-balanced (I'm not sure if I have that correct)? Is this what you mean when you said btrfs is a "non-traditional" filesystem?
- As for the bugs... yeah, I can see those being a showstopper for many -- no excuse for that; but, they don't seem to be corruption bugs. I'm not saying that's acceptable, it's just that when people say a filesystem has bugs without specifying what kind, I tend to think, "I'm going to lose my data if I use this."
- When you said, "...it was only two (?) kernel released ago...", were you talking about the latest stable Gentoo release (6.6.y) or the latest stable upstream release (6.12.y)?
- Please don't take this as me trying to push btrfs, as I would like to clear up some confusion I might have with it. I'm currently using it and would like to know if I'm using it wrong. I understand if the decision is, "We don't want to use btrfs because it's not polished enough." I chose btrfs because:
- - it's labeled as stable in the kernel.
- - I wanted to see if the hate surrounding it was valid (I guess people still don't trust it because it initially had problems, but every filesystem goes through this).
- - Meta/Facebook uses it (if it's good enough for them, then it should be good enough for me).
- Either way, I will continue to read the docs and man pages.
- FlyingBullets (talk) 17:12, 3 December 2024 (UTC)
- I regularly read which patches are included in a new minor kernel version here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.6.y
- I had the feeling that there are patches for btrfs in almost every version. I have now checked to what extent my feeling is wrong and have counted - for XFS and btrfs:
- 6.6.61: B 1
- 60: X 1
- 58: B 2 X 21
- 57: B 2
- 55: B 4
- 54: B 6
- 52: B 1
- 51: B 5
- 50: B 1
- 49: B 2
- 48: B 16
- 46: B 4
- 45: B 2
- And there are certainly patches for errors of a certain scope. Long story short: I have no confidence in a file system with this frequency of patches.
- Pietinger 19:03, 3 December 2024 (UTC)
The resume note (bookmark)
Would place it a few lines up together with swapon, to re-activate swap. --Adr (talk) 07:18, 4 December 2024 (UTC)