From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Date: Sun, 05 Apr 2020 10:46:26 +0100 [thread overview]
Message-ID: <7085532.EvYhyI6sBW@lenovo.localdomain> (raw)
In-Reply-To: <20200405081741.o32ew747jluxa3qg@solfire>
[-- Attachment #1: Type: text/plain, Size: 3995 bytes --]
Hi Meino,
On Sunday, 5 April 2020 09:17:41 BST tuxic@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.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-04-05 9:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-04 17:34 [gentoo-user] ...recreating exactly the same applications on a new harddisc? tuxic
2020-04-04 17:59 ` [gentoo-user] " Ian Zimmerman
2020-04-04 18:03 ` tuxic
2020-04-05 17:41 ` Ian Zimmerman
2020-04-05 19:53 ` Jack
2020-04-05 19:57 ` Jack
2020-04-04 21:26 ` Neil Bothwick
2020-04-04 23:46 ` Peter Humphrey
2020-04-04 18:05 ` [gentoo-user] " Mark Knecht
2020-04-04 18:23 ` tuxic
2020-04-04 18:57 ` Mark Knecht
2020-04-04 18:33 ` Dale
2020-04-04 21:42 ` John Covici
2020-04-04 22:24 ` Dale
2020-04-04 18:25 ` Ashley Dixon
2020-04-04 19:05 ` tuxic
2020-04-04 19:29 ` Ashley Dixon
2020-04-04 19:30 ` Mark Knecht
2020-04-04 19:59 ` tuxic
2020-04-05 9:21 ` [OT] " Peter Humphrey
2020-04-05 9:29 ` Peter Humphrey
2020-04-04 21:56 ` Grant Taylor
2020-04-05 8:17 ` tuxic
2020-04-05 9:28 ` Ashley Dixon
2020-04-05 12:52 ` Neil Bothwick
2020-04-05 12:56 ` Ashley Dixon
2020-04-05 13:37 ` Michael
2020-04-05 14:56 ` Neil Bothwick
2020-04-05 18:08 ` Peter Humphrey
2020-04-05 19:39 ` Neil Bothwick
2020-04-06 10:17 ` Peter Humphrey
2020-04-06 21:02 ` antlists
2020-04-06 21:15 ` Neil Bothwick
2020-04-06 23:38 ` Michael
2020-04-07 15:23 ` antlists
2020-04-11 15:37 ` Marc Joliet
2020-04-08 1:02 ` William Kenworthy
2020-04-05 9:46 ` Michael [this message]
2020-04-05 10:52 ` tuxic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7085532.EvYhyI6sBW@lenovo.localdomain \
--to=confabulate@kintzios.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox