I have a PC that started out with Vista. 300 GB HD. I shrunk the Windows partition, made a 40GB partition (and a swap partition), installed Lubuntu. Then another 40GB, installed Mint Cinnamon, then another Mint XFCE, then another Peppermint.

Maybe I will install a couple of other distros to try them out. I purposely am not using a VM so I can see how each installs and runs 'natively' on the same actual hardware.

Each new install (re)installs grub in its own file system and puts itself the top of the GRUB boot menu.

I decide I like XFCE the best so I go to the /etc/default/grub of the last distro I installed (Peppermint) and set GRUB_DEFAULT=the appropriate line number on the menu.

Now I update Cinnamon from 18.2 to 18.3. It displaces Peppermint from the top of the list and also its grub takes over. So now to get Mint XFCE as the default option, I go /etc/default/grub in Mint Cinnamon as opposed to Peppermint and make the appropriate GRUB_DEFAULT entry and again it works.

But when the Mint XFCE 18.3 is released and I update it, then XFCE will put itself at the top and take over grub. That happens to be OK since I probably will still want XFCE as the default. but if I install another distro, it will take over.

I'm reading all kinds of opinions about a separate GRUB partition which seems like it might solve the problem but what I get is you shouldn't do that.

So is there a way to do it?

a grub partition? no. a boot partition, maybe.
i doubt it will be useful here.

i think you can manually define the default entry on your favorite, grub.governing distro.
maybe there's also a way to keep further upgrades from touching grub; idk. for apt-based distros, i'd look up apt documentation.

Just run grub-update from the distro you want to use as your grub manager. Do it again whenever you need to (i.e. if you've done a system update on one of your other distros and you see on your next boot that the grub menu has changed). It's the simplest solution.

The grub partition is only used when you have a gpt disk but you want to boot it from an old-style bios (or a uefi chip in legacy mode). Then the first stage of grub must go into the mbr and you need some place to put the second stage. It's no use for anything else.

On a a legacy system(I assume that is what you have with vista) I install each grub into its own partition I then create chainloader(or boot from the configfile) entries in /etc/grub.d/40_custom with the distro grub that I want to have install to the mbr.

Install grub to the MBR with the distro you want to boot into, & then install the other distros grub to their partition, not the MBR. Whilst not a single grub, it is a solution to your problem.

a boot partition in the size of 120MB is always a good idea.

--

especially make it more complicated by generating new config files in /etc directory for self destructing grub. make it more complicated by providing a man page, examples which do not really work or are self explenatory.
10 xxx, 20 xxx, 30 xx, 40 should be your other linux distro. I tried it several times barely worked. At the time I tried to use that stupid 40.xx custom kernel thing for grub the manpages were a mess, the docs were a mess and the configuration files were a mess. Gentoo was in the grub 1 area. Linux mint was in the grub 2.0 area already.

Basically you just add that new section somewhere in /etc for the grub software, so it duct tape, not well designed scripts just moves that section from there to /boot.

Where is the benefit in those scripts? Additional space used. You need to have the grub software installed, takes also space.

When your box boots, you can reuse that bootloader as long as you want. Until UEFI forgets your mappings which happens for certain cases. Some are ASUS bios bugs, some are intentional.

When your bootloader is installed, you can unmerge grub in gentoo linux. You just need the bits and pieces corresponding in the folder of /boot. The only requirement for kernel updates later is to use an editor and replace the files and file names in your grub.cfg

--

Linux mint guys are idiots.
Where is the hard task to parse the grub.cfg for my own linux mint previous generated config files?
When I found them replace those lines and replace the boot files. Finished.

Check if grub is bootable. This can not be that hard for a developer right?

No they wipe everything. It is never a good practise to just wipe something without asking the user or confirmation.

Gentoo has the policy to not touch the configuration files in /etc. I think that should also apply for any boot related files.

Definitely not.

Linux mint even does not asks the user and just wipe the grub.cfg during the ordinary update process.

--

Any grub configuration, I used both versions, are just plain text files which can be edited.

Move over the files and just add a new entries for everything you want to boot.

I think it is very bad practise to use those self destructing scripts which the grub project provides, or how the binary distros, especially linux mint handles them.

--

It's good practise to be able to boot a recovery media, and manually setup your bootloader including the corresponding boot entries.

--

You never want your boot to be on the same /. There are only a few cases when /boot should be mounted at all when an OS is running.

+ Than add the kernel files and boot entries to your main grub in the boot partition.

Note: Certain binary distros and Windows will just expect I am the only one and will overwrite any boot related area and config file. You may have backups to revert

Are you aware of the concept of a package manager?
Are you aware of the concept of a graphical login manager?

Quote: installed Mint Cinnamon, then another Mint XFCE, then another Peppermint.

No idea what peppermint is. But XFCE can be for sure installed with the package manager in your existing mint cinnamon. than you use your graphical login manager like, lxdm for example to choose at the login screen, which user and which desktop environment to load.

The topic if swap is needed is another topic.
Swap was needed in my point of view on a pentium 120 with 128MB RAM.
Some boxes may need it with 1 or 2GB RAM, at 4 or 8 or 16GB of RAM you may double check on how much SWAP is really needed. You may check your requirements than.
Binary distros have the habbit to say, I wnat a swap partition and than they bareley touch it. I had it in the past with a penryn cpu with 3GB of RAM on several binary distros. HARDWARE was ASUS K70. Quite outdated.
Usually when you want to try out distros 20-25GB are more than enough without any SWAP when the box comes with at least 3GB of RAM and a penryn cpu or better

On my MBR-based systems, I have a single boot partition (I label it Boot) that I set up with the first Linux install. Upon first boot, I unlink Boot from /boot, copy the contents of Boot to /boot, and then install grub in the root partition of my Linux install. Next, I modify the grub.cfg file in Boot/grub to point to the Linux partition's grub. With subsequent Linux install, grub goes into the partition containing that Linux's root partition, and I update grub.cfg in Boot manually.

A typical layout for my older computers:
sda1 Windows
sda2 Boot
sda3 extended
sda5 Fedora
sda6 Ubuntu
sda7 Pictures (shared by all distros)
sda8 Common (also shared by all distros)

Yes this is a 2008 Compaq (Pentium Dual Core) BIOS system, originally Vista. I am using it as a test bed and also to run digital communications programs for ham radio. Some only work on Windows so I kept Vista. Having it in the 'shack' makes it easy to keep learning more about Linux.

I am doing a lot of upgrades for customers from Vista or XP to Linux. Lubuntu for older P4 low ram XP, Mint for more 'powerful' PCs.

Peppermint is basically an 'enhanced' version of Lubuntu, still lightweight LXDE but with more applications and designed to be more 'cloud-centric.'

I specifically did not want to install alternate DEs on the same distribution, I wanted to evaluate stand-alone distros.

fatmac, I guess I don't understand installing grub in the MBR. I thought that's what happened when I did the first linux installation. It replaced the Windows boot code.

But it doesn't install all of itself because there is not room, so it it looks on the system partition (or I guess boot partition if there is one) for other files. So apparently when another distro is installed in a different partition, or updated to a new version, it goes back to the MBR and modifies grub to look on its partition for the grub config files.

Sorry Roman I agree with your observations about grub xx files seeming to be 'duct tape' but I am not really understanding what you are trying to tell me about an actual solution.

Swap partition I'm not worried about. Doesn't take up much room and only one is needed. Whether swap is really used much I don't much care at this point. I think it is a fine point of performance optimization.

I find grub documentation to be less than adequate. The 10xx etc customization files are not clear to me and even if I used them in the situation I am describing it would not solve the problem.

I got pretty good at understanding the Windows boot process, booting multiple Windows, and and how to fix it when it breaks. I had a system with 98, 2000, and XP. Occasionally something would screw up boot and always the solution was to go back to the first installation (98) and fix the boot code.

Now I am trying to understand multiboot with Linux. It would be nice to have the same situation where the part of the boot code that is not in the MBR doesn't change location.

If I understand it correctly one problem with a boot partition is unless you make it big, or manually uninstall old kernels, is eventually with enough updates or upgrades it will fill up and system won't boot.

So if there was a way to just install all the non-MBR grub files once that seems like it might solve my problem.

RockDoctor I'm not quite follwoing you procedure. Also tou say 'With subsequent Linux install, grub goes into the partition containing that Linux's root partition' which sounds like it doesn't eliminate the problem of each new installation or upgrade to a new version of an existing installation grabbing hold of grub.

The default on all these systems is to overwrite the MBR and have that code point to the OS partition which you are installing. If you want to keep the boot code of a specific system in the MBR, install that system accepting the default to the MBR (/dev/sda) and then use the manual method referred to as 'Something Else' in these Ubuntus. You then will have the option to install Grub to the same partition on which you are installing the new OS. In the installation window, there is a 'Device for bootloader installation' option at the bottom and you should be able to click the down arrow to the right of it and select the OS partition there, thus keeping the original in the MBR.

My experience with the Ubuntu's is if it is not installed in the MBR, it isn't going to put itself there or overwrite it unless you tell it to with a specific command. There is a major difference between updating Grub and upgrading or re-installing an OS.



That happens because you accept the default and don't select the partition as described above.

We have been able to chain load for many years if you don't want a single grub (or other loader). There are still some boot managers that work for these things too.

Not all OS's allow you to easily select by the installer. Some cases you have a more powerful option to use an older text installer that lets you have more control.

Think of it this way. Normally, the bootloader (grub) is installed in two parts; part 1 goes into the MBR and part two goes somewhere else, either in its own partition, or in the distro's root partition. It's also possible to install both parts in a distro's root partition. Also, grub is capable of chainloading - one installation of grub can hand off control to another.

My first Linux installation (Fedora on sda5) puts grub into the MBR and a small Boot partition (say sda2). The Boot partition is initially mounted at /boot. I unmount sda2, remount it at /mnt/Boot, copy its contents to /boot, then install grub in Fedora's root partition. Then I change Boot's grub.cfg file to chainload Fedora's grub, identifying the Fedora partition by device (sda5 in this case).

My second Linux install (Ubuntu on sda6) only puts grub in Ubuntu's root partition (sda6). I then modify Boot's grub, adding a stanza to chainload Ubuntu's grub.

I want to wipe Ubuntu and install PCLinuxOS. I just wipe sda6 and install PCLinuxOS and its grub in sda6. No change needed to grub.cfg in Boot (other than perhaps changing the name from Ubuntu to PCLinuxOS)

I have a very simple solution to such experiments: "external hard drives!"

Without touching your (Windows?) host OS in any way, spend $50(USD) or so for a multi-terabyte external hard drive at your friendly neighborhood office-supply store. Partition it as you wish. Now, boot from it and off you go.

When you want to boot into the native host, boot from the internal drive.

O-r ... use virtual machines, such as VirtualBox, which is a free, full-featured (no "hobbled horses" here) virtual machine monitor, that runs on everything and that is backed by one of the wealthiest software corporations in the world. Point a virtual-machine at this external hard-drive, and away you go, running Linux in a window on the host.