On 04/05 10:46, Michael wrote: > 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.
Hi Michael, Your posting helps me a LOT!!! :) Thank you very much!!! :) Cheers! Meino
