Hi Meino, On Sunday, 5 April 2020 09:17:41 BST tu...@posteo.de wrote:
> Hi, > > a new morning... :) > > Being on the way to install/setup the base system (mostly getting > stage3 uptodate) I came accross kinda inconsistency -- or at least > it looks like for me. > > The system uses a 3T harddisc (and later a SSD) and therefore GPT. > GPT is the sister/brother of an U/EFI boot. > > For that the documentation (AMD64 handbook): > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Using_UEFI > > says: > Default partitioning scheme > Throughout the remainder of the handbook, the following partitioning scheme > will be used as a simple example layout: I think the following table provided in the handbook was probably written some time ago, when the migration was happening between legacy BIOS and UEFI MoBos. Others may know more about the rationale behind the partitioning scheme given as an example in the handbook, but for what it's worth I share my understanding below: > Partition Filesystem Size Description > /dev/sda1 (bootloader) 2M BIOS boot partition The above is probably a manually created 'GPT protective MBR'. This is now created as a default by modern partitioning tools, but not if you're using some old Knoppix CD you had burned in the early '00s. Its purpose is to add some code in the first 1M of the disk (LBA 0) to signify to a legacy BIOS or OS the partition table is not bootable. Old partitioning tools/OS' will show the disk as already partitioned with 'Unknown Partition Type', thus prompting the user not to mess up the partition table/partitions on this disk. If you use a modern fdisk/gptdisk/parted, etc. you won't see this first partition mentioned above, but you will see the first partition starting at 1M, or on a 512B sector size at 2048. > /dev/sda2 ext2 (or fat32 if UEFI is being used) 128M Boot/EFI system This the partition the UEFI firmware will jump to and load bootable code from. The GRUB efi boot binary (grubx64.efi) and any other kernel/initrd efi code will be stored here. > and later on at > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System > > FILE /etc/fstabA full /etc/fstab example > > /dev/sda2 /boot ext2 defaults,noatime 0 2 > /dev/sda3 none swap sw 0 0 > /dev/sda4 / ext4 noatime 0 1 > > /dev/cdrom /mnt/cdrom auto noauto,user 0 0 > > Here /boot changes from fat32 to ext2. I think this is because the handbook really needs to be updated. It mixes old with new. All UEFI MoBos require a VFAT partition to boot from. > Since this is my first U/EFI system I am a little confused. > > Currentlu it looks like the vmlinuz binaries will be installed on > a FAT32 filesystem. Since the kernel can be launched from a ext4 > filesystem I cannot see, why this have to be a FAT32 filesystem. You can chainload a vmlinuz binary stored on any other partition number and type from a boot manager (e.g. GRUB). The boot manager will have to be stored on the VFAT EFI boot partition for the MoBo UEFI firmware to be able to boot it. Future UEFI firmware may be able to boot from ext2, but AFAIK not presently. > My plan (if this is possible), is to U/EFI-boot grub, from which > I can select the kernel in question as it has been on my old > system (MBR based). > > My current partition table looks like (only relevant parts shown): > > Number Start End Size File system Name Flags > 1 1049kB 3146kB 2097kB grub bios_grub > 2 3146kB 137MB 134MB fat32 boot boot, esp > 3 137MB 674MB 537MB linux-swap(v1) swap > 4 674MB 269GB 268GB ext4 root Unless you intend to use the disk both on MBR and on UEFI MoBos interchangeably, I suggest you stick with the GPT partitioning scheme and a VFAT EFI Boot partition where GRUB and vmlinuz will be stored. HTH.
signature.asc
Description: This is a digitally signed message part.
