In Ubuntu I can partition a HD (to be entirely used for Ubuntu) before I install. The installer sees the partitions and installs into them rather than into its singular [default] "OS" partition.

That is particularly slick because the install process remains automated, rather than interactively slow and more open to typos during an interactive full-install.

Some advantages of this 'modular' partitioning of '/':
1) my /var/ folder can have its own partition so that I can have a database installed and developed in there; if I have to re-install Ubuntu, that process will preserve my database.
2) my /home/ with all of its users' dot-files and specifics will not be lost.
3) all of my locally-installed (downloaded, installed, licensed, and configured) local tools will remain safe.
4) I can backup single partitions on a schedule based upon the access to and use of that partition's content.

So, I'm looking at Fedora and am uncertain if the same pre-partitioning is viewed by the installer?

Restating, can I partition before a Fedora installation, or, does the install just give a 'choice' between me either accepting its default partitions or doing my partitioning through the installer's interactive steps?

Thanks,
"frank"

i 've never used Fedora (yet) but mostly every time i do a new Slackware installation I set up partitons for types (swap) ext4, ext3 and sizes . In my experience doing a slackware installation , during installation the installer simply says "swap" recognizes , do you want to format , check it bad blocks yes ,no etc.

Partition added to fstab.

So nothing unusual there.

The Fedora Project site has extremely detailed instructions on installation. If you don't want the standard install and want to set up partitions, you will have the option to select "I will configure partitions" which is shown in Figure 12 at their site at the link below.

https://docs.fedoraproject.org/en-US...sing_Anaconda/

I have not seen an installer that does not let you partition it out however one wants. but lets not forget that it an be changed after an install anyways. it's called "flexibility"

Thanks yancek. I agree. Fedora does have great doc, unlike FreeBSD.
As well, its installer is flexible.
Link appreciated.

Thanks,
"frank"

Thanks BW-userx! My Fedora install went well. Both the sda (Ubuntu 18.04) and sdb (Fedora 31) came up in my menu list. The sdc (FreeBSD 12) install came up initially but was not availed after a reboot. W/r/t multi-boot, it is poorly documented, as is finding with today's made-useless [Google-dominate] search engines any documentation specifically dealing with multi-booting OSs all on separate internal disks and Grub 2.

So, after deleting sdc partitions and data, my working plan is to disconnect both ada and sdc before installing FreeBSD onto sdc, so that it will not mess with either Ubuntu or Fedora in any way. Then I will reinstall Ubuntu and Grub onto sda, with hopes that it will see and configure for both Fedora and FreeBSD bootloaders found in their own boot partitions, pulling the correct lines into the lone Grub (on sda).

I would think that each drive/OS needs both an EFI and boot partition (for its specific bootloader) and that only the reinstalled sda (Ubuntu) will have the knowledge in its Grub menu where all system OS bootloaders reside.

Doc regarding how to prevent he 2nd-3rd-etc. installations from overwriting grub with themselves only is the hazy zone for me. Also, if I have to stuff bootloader or EFI lines from the 2nd-3rd-etc. installed OSs into the default Grub and/or /etc/grub.d/40_custom files, where I am supposed to find the parameters (and which args to even send) is a mystery as well.

Too many web sources do not match the conditions if their conditions are even disclosed, and, few have OSs on their own drives rather than sharing a drive with multiple OSs.

Any pointers, example code, and/or commands to find the menuentry parameters is greatly-appreciated.

best wishes,
"frank"

so you're booting efi? all of them?
simple enough. I do suppose, I got my freeBSD on partition 7 boot efi via slackware grub.
40_custom
the hd is 0 = 1st drive, 1 = 2nd drive, 2 = 3rd drive, partition numbering, is 1,2,3,,4 etc...

you can use Linux wto open gparted and figure out what partition freeBSD is on.

mbr booting if not gpt partiton table.
this is a maybe because it is a separate drive but still numbering may change.
two if you disconnect your dries then install then boot, expect to fail to single user mode.
vi or nano if you got to install that or whatever else to edit /etc/fstab. then change your mount points, and if you did not know, FreeBSD HAS to be on a primary partition to boot.

Much appreciated!
Sorry that it took me over a week to get back to the forum and your reply.

I've been replacing 1TB internal drives (containing Ubuntu) with 2TB drives this week.
I'm using a Restore flash put together by Dell for my two Dell Precision 5820s, which originally came with the AMD 2100X graphics card and Dell frozen-out AMD drivers. AMD sold them the cards before the drivers were available and supported by Canonical and Ubuntu 16.04. Hence, the "login loop" issue. The addition of multiple sources of hardware/software/firmware makes a code freeze very susceptible to issues when communication and full testing get tabled, reduced, and/or eliminated to meet engineering's schedule deadlines and/or to sustain the business' cash flow: a "perfect storm" brewing ever more when so many (Canonical, Dell, AMD) are so integrally-involved.

So, I keep wondering why the Ubuntu installer always slams 1M before my first partition? MBR?
I have been using the following:

? mbr mbr partition scheme* legacy_boot "legacy bios bootable" is checked
/dev/sda1 fat32 /boot/efi efi system* boot, esp
/dev/sda2 fat32 /biosgrub bios boot* bios_grub, legacy_boot "legacy bios bootable" is checked
/dev/sda3 ext4 /boot extended boot*
/dev/sda4 ext4 / linux root* "x86_64" is selected over "x86"
/dev/sda5 ext4 swap linux swap*
/dev/sda6 ext4 /tmp
/dev/sda7 ext4 /usr
/dev/sda8 ext4 /usr/local
/dev/sda9 ext4 /usr/ports
/dev/sda10 ext4 /var
/dev/sda11 ext4 /home /home*
unallocated (free space)

* = flagged and/or labelled

I had no difficulties with one system, however, the second started to boot up the GUI (in low-res graphics mode, always done before filtering-up through the graphics card into high-res) and then went off into an unresponsive "(initramfs)" command line mode where even an "exit" wouldn't elicit a response. Sop, I did a full disk erase-based install in the installer's default partitioning scheme. That worked, however, I want parttioning over a giant clump. I started up another install - this time doing the partitioning while inside the install procedure, rather than doing it with gparted from another OS's drive, beforehand. It worked and I am at the setup phase in hi-res about to set static ipAddress, admin passwd, etc. ... and, with all of my beloved partitions. Hurrah!

thanks again for the thoughtful support and patient guidance,
"frank"

It's a convention most partitioning tools have been using for over a decade. It serves two purposes I'm aware of: 1-keeps partitions aligned on 4k boundaries for the benefit of performance on rotating rust with 4k sectors internally; & 2-provides ample space on the boot "track" for bootloader code.

Beforehand is the only way I ever partition, using a 5-way cross-platform tool that logs what it does. I use the logs to track what is located where across multiple multi-multi-boot PCs.

As to: I limit grub to installing on partitions only, with a master grub on a primary on MBR disks that is never mounted to /boot. On GPT/UEFI disks I don't mount the ESP except in the sole distro on which I have grub installed, where I use custom.cfg via /etc/grub.d/06_CUSTOM to make os-prober irrelevant except as a convenience for booting prior kernels. Really, there is only one bootloader needed per Gnu/Linux PC. Having more than one is an unneeded complication.

2TB drives requires a gpt type disk label. This partition is needed when booting a gpt type disk in legacy mode using the grub bootloader. The 1M is used on a gpt disk for grub to put it's boot code that use to go in the space between the mbr and first partition on a msdos type disk. This space doesn't exist on a gpt type disk. The lilo bootloader doesn't need this partition to work on a gpt disk in legacy mode
Why the installer does it when booting in efi mode, I don't know unless it is to allow to boot the disk in legacy mode with grub if the need arises.

Greater than 2TiB (4,294,967,295 or 2^32-1 512 byte sector) drives require a GPT disk label (for full access to the entirety of the drive by common tools and operating systems).
2 TB = 1.818989404 TiB