Quote:
Originally Posted by RickM
I have an X86 computer that I am dedicating to Linux
Essentially I plan to put quite a few distros on it
|
Multiboot is as much art as science. There are many ways to fail, and to succeed.
Quote:
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?
|
Yes, with emphasis on
this or
initial.
Quote:
or
Do I need to make a partition for it
|
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?
Quote:
and load it manually somehow?
|
Depends on what and when. Most of the earliest
loading is done automatically via a bootloader menu or an /etc/fstab.
Quote:
If so I need a lot of help with it - like when and how?
|
Before getting into "quite a few" you need to get a grasp on some basics, and do some planning.
Quote:
I am assuming that I will need only one SWAP partition for all distros - correct?
|
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.
Quote:
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
|
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.