[gentoo-user] Re: MBR & GPT dual compliant format

[James]

Tom H <tomh0665 <at> gmail.com> writes:



> > > I you're using GTP but want to stick to MBR, then you create 1MB
> > > partition to hold the boot loader, then /boot and the rest.

Hello,

The idea is to be able to set up a batch of 2T+ disks now and in the future,
all pretty much the same (generic) layout for both bios based systems and
efi systems, so the drives do not have to have the partition tables changed.
A standard partition scheme will put the extra disk space (according to
size) all into the /usr/local partition. A wide variety of File systems will
be imposed on the /usr/local and maybe the other 
(3) partitions:: /; /boot/: /usr File systems can change, especially what 
is on /usr/local. Distributed file systems will be routinely tested too.
All drive will keep the default boot-drive partitions, maybe for multiple
different systems/kernels (all linux though) so if a drive is to be used
as a non-boot drive, the some of the partitions may not be mounted for a
particular experiment (cluster/codes) configuration. I hope this clearly
states the ultimate goal so the myriad of bios systems I have can be used,
but also the same scheme with many new embedded and efi based systems with
many different processors (and Soc) on the mobo. Much of the testing will
be only changing codes on gentoo systems. But there will be time when a
*buntu cluster is tested, keeping all the hardware identically the same
as a gentoo reference run.


Testing a wide (wild?) variety of clusters will constantly mix and match
disks to various motherboards and embedded systems (with sata) interfaces.

So what I'm looking for is for someone to edit the partition table I
post below, so that it looks like what I need. I have tons of verbiage of
what to do, but not a single, example  partition table of what it would
actually look like (perhaps as viewed by several different (CLI)
partitioning tools (gdisk, fdisk, parted) to highlight the minutia
of the partition table.. A companion fstab (ext2/3/4) that works, would be
keenly appreciated. I only ask because I have failed at this effort in the
past and currently.

> > > About the 100MB EFI-partition: it's a Microsoft recommendation:
> > > https://wiki.archlinux.org/index.php/EFI_System_Partition, read the
> > > "create the partition" section.

I intend to only use grub-legacy for this effort. But, some explanation
as to when I would absolutely need grub-2, if that case even exists, would
be keen knowledge to have. Some other common distros, when I cannot get
something to work with gentoo, would be alpine and arch, when a gentoo
solution evades me. I might even spin up a complete (DC/OS) like mesosphere
or CoreOS for benchmarking. The idea is to take a small cluster and spin it
up with several different (cluster centric) solutions to problems and
measure the performance in a variety of test surveys. The suspected outcome
is that gentoo  that is minimized and optimize (including kernel and
compiler and framework tweaks), is always the performance king of the
clusters. At this point my evidence is anecdotal and not 'publishable
grade'.  I want to be fair to the bloated vendor communities and have a
consistent hardware platform, for these test-surveys.

Additionally, searching out details of kernel tweaks that optimize 
a particular problem-set of cluster-code-solutions is also of keen interest
to me.

> > Please bottom-post.

Agreed.


> > The OP wants a partition scheme for both "standard" and efi firmware,
> > so he wants an EF02 (gdisk name) of 1MB and an EF00 (also gdisk name).

Guys, the drives are 2T and larger, so the ridiculously largest partition
size needed in the worst case scenario, that works as specd-above is the
best answer.


> > The OP wanted the EF02 to be mounted as "/boot" so it has to be larger
> > than 100MB in order to accommodate multiple kernels (and possibly
> > initramfs "thingies" as they're sometimes called here).

I have never had a linux system with less than 6 kernels, often many more,
just for that one system. I use to hack kernels for breakfast (2.2-early
3.x) so yes tons of space for kernel hackery is warranted. All kernels will
also be archived to a separate backup machine/system. Kernel tweaks (as
found in kernel sources, as well as many codes in the wild, pretty much
means that endless kernel tests are warranted and that does require gigs of
disk space and organized back end storage and notations.


> Then the OP is lucky as the handbook describes this exact scheme the OP
> wants. Only one adjustment should be considered - I would recommend
> around 500 MB for /boot if the OP wants to use multiple systems and if
> disk space is of no special concern.

I was think 2G for /boot. Here is a common partition table and subsequent
fstab that folks are encourage to edit as to what they would use for this
universal partitioning scheme.....


#parted -l /dev/sda
Model: ATA WDC WD20EARX-00P (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  211MB   210MB   primary  ext2            boot
 2      211MB   139GB   138GB   primary  linux-swap(v1)
 3      139GB   952GB   813GB   primary  ext4
 4      952GB   2000GB  1049GB  primary  ext4

corresponding fstab::
/dev/sda1   /boot        ext2    defaults,noatime     0 2
/dev/sda2   none         swap    sw		      0 0
/dev/sda3   /         	 ext4    defaults,noatime     0 1
/dev/sda4   /usr/local   ext4    defaults,noatime     0 1


All comments and examples are most welcome. I do need some 'thinking out of
the box' on this effort. Request for automating of tools, ipxe to ansible
will be subjects of future needs.


TIA,
James