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]] 10:54, 5 November 2024 (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)