I have an X86 computer that I am dedicating to Linux

Essentially I plan to put quite a few distros on it

I know how to partition and am just installing Ubuntu but I am really stuck

Is Grub Menu going to be automatic with this initial install?

or

Do I need to make a partition for it and load it manually somehow?
If so I need a lot of help with it - like when and how?


I am assuming that I will need only one SWAP partition for all distros - correct?

As additional Linux distros are installed will the Grub Menu be updated automatically?

or

Is this another manual operation? If so again I need help


Thanks in advance, Rick

Yes - and I would suggest you get comfortable with just one distro for a while. The reason(s) will become obvious quite quickly.I tend to, but it will be easier easier to just allow each distro to install into the root (base) directory.That is what I do but requires you to ensure you have the swap specified by device not UUID - all the "popular" distros use UUID by default.The grub for the distro currently being installed will be - not all the others.

Nothing is ever as easy as it first seems.

Thee are "stand-alone" boot-managers (plop for example) that handle some of these issues - I haven't tested any of them in years.

Multiboot is as much art as science. There are many ways to fail, and to succeed.

Yes, with emphasis on this or initial.

It will need a filesystem to live on. Something or someone will have to create one. Things are already fuzzy. Are you referring to Ubuntu the OS, or to its bootloader?

Depends on what and when. Most of the earliest loading is done automatically via a bootloader menu or an /etc/fstab.

Before getting into "quite a few" you need to get a grasp on some basics, and do some planning.

Technically quite correct, but this is easier said than done. The Debian installer and distros based on Debian make it tricky to implement by insisting on formatting swap with each installation. The workaround is to install such distros specifying no swap, then manually adding swap to /etc/fstab after installation has completed.

Grub2's default configuration is to assume it is supposed to be, and act accordingly, as the bootloader. Included in this assumption is to discover all existing installations and include at least one stanza intended to boot each. A separate utility os-prober is called to do this. With more than one installation remaining in this configuration, each update that triggers a boot menu rebuild will cause it to usurp control from the last updated. It doesn't take long for circular dependencies to mushroom each's grub.cfg.

Thus you must at some point intervene. There are three basic methods of avoiding this usurpation:

1-Let the first installation do and continue to do as it pleases, which with most means it will write Grub to MBR, and have os-prober enabled. Subsequent installs will need to be directed to either install no bootloader, or install their own bootloader on their own filesystem. All the other bootloaders should have os-prober disabled.

2-Create a primary partition to host a bootloader that you will manage yourself, set the boot flag on it and no other, and most probably use generic (Windows compatible) MBR code. This is known as MBR neutral. All installations will be instructed to install either no bootloader, or its bootloader on its own filesystem.

3-UEFI booting. This does not totally avoid the problem, bug simplifies it greatly, since the UEFI software plays a much bigger role in booting than a non-UEFI BIOS with MBR. Each installation will make an entry on the ESP partition. The problem is only in managing which presents the initial boot menu. That depends in large part on the particular UEFI BIOS. There is only modest similarity in behavior among them. You'll have to experiment with the one you have and act according to what you learn.

If you are planning on just trying out a few distros, using virtualised guests might be a simpler option. Relatively easy to setup, and they are "independant", so also easy to tear down and throw away.