How should I install GRUB2 for multiboot?

[aajax]

I'm salvaging a computer by starting with nothing installed on a new hard drive to be used for booting. The intention is to install multiple instances of bootable systems. One or more will be Ubuntu. I want each system to be capable of being completely independent (i.e., self contained). In that, I could set the partition it resides in active and it will boot. Also, the failure of any of the systems does not affect the others. However, because there are multiple systems I'd like to be able to select which one I want to run when booting the computer.

To do this I think I need a small partition which is only used to run GRUB2, which will normally be the active partition. Then a completely self contained Ubuntu system is installed in another (i.e., 2nd) partition. Likewise another completely self contained system can be installed in another, 3rd, partition.

It looks to me like I may need to start by installing a complete Ubuntu system (using LiveCD). Let's say into Partition 2. From there I can install grub2 into a different partition by using the grub-install script. Let's say that Partition 1 is the target for grub-install.

Assuming that the above is a valid interpretation of how Ubuntu installation can be done, what is not clear is the minimal requirements for the partition (i.e., size, file system, etc.) that is to be the target of grub-install. The choice of file system likely affects the choice of system to used for emergency repair or update, which means what choice of filesystems is possible?

If this approach is valid what is the best choice for partition size and file system for the grub2 partition (i.e., Partition 1)?

If this is either not valid or a bad approach what is good approach?

[oldfred]

I have multiple Ubuntu installs.
With grub2, you do not need a grub only partition.
Back with grub legacy, I did use one of those, but you totally have to manually maintain it.

With BIOS, you only have one MBR per device, so last system installed takes over control of MBR and then booting. Most Linux now use grub2.

Active partition is mostly a Windows thing. That tells the Windows boot loader where to find more boot code. But Lilo & Syslinux also use boot flag.
Grub does not use Active partition which in Linux is the boot flag.

I use 25GB for / (root) including /home, but then have a large data partition which I mount in every install. But all my installs are Ubuntu or a flavor of Ubuntu.

And then I can boot a partition not the specific grub entry. Debian based installs have a link in / that is to most current kernel after update. So you boot link and can then boot an updated install without having to manually edit 40_custom or run sudo update grub in every install to have most current kernel in grub.cfg for os-prober from booting install to find and add to boot menu.

How to: Create a Customized GRUB2 Screen that is Maintenance Free.- Cavsfan
https://help.ubuntu.com/community/Ma...tomGrub2Screen
https://help.ubuntu.com/community/Grub2/CustomMenus

[grahammechanical]

If you intend to install any version of Microsoft Windows, then install it first. The Linux boot loader (Grub) will detect Windows and list it in the boot menu. But the Windows boot loader only detects other versions of Windows. So, if you install Windows after Ubuntu or any Linux distribution then you will not be able to boot into Linux because it will not show up in the Windows boot menu.

Also, it makes a difference if the motherboard has a BIOS or a UEFI boot system. The advice will be different.

As a minimum Ubuntu needs two partitions. One for Ubuntu (mounted / ) and one for swap. As we can only use one OS at a time, other installs of Linux will use the same swap partition. If you intend to hibernate (suspend to disk) the swap partition will need to be a little larger than the amount of RAM as the state of the OS in memory is stored in the swap partition during hibernation.

The amount of RAM will determine the size of the swap partition. If the amount of RAM is large enough so that swap is rarely used then swap can be 1 or 2 GB. If RAM is 1 or 2 GB then you might want 2 or 3 GB swap.

Regards.

[yancek]

Choose a system you plan to keep, Ubuntu? and install Grub2 to the MBR if you are using an MBR system. When you install more systems, use a Manual or Expert option which should give you the option to install Grub to the partition on which you are installing the new system. Re-boot Ubuntu and run sudo update-grub. If you allow each new installation to install to the MBR on one of the auto-install methods, you eliminate the need to update-grub from Ubuntu but if the installation fails, your computer is bricked and you need to go through a convoluted process to reinstall Grub.

[aajax]

I understand that multiboot can be done without a dedicated boot partition. However, I want/prefer a dedicated boot partition because this allows each system to be independent. I want to be able to backup and restore systems (i.e., root partitions in Linux terms) using captured images (e.g., as created by partimage). If one of the systems is also required to boot another system then there are different scenarios that must be followed depending on which system you might want to replace with one of the images. I also realize that there is some FSTAB editing that is required when you relocate a partition (e.g., restore an image to a different partition than the one where the backup came from). My idea, which I've done in the past with both grub and something called bootmagic, is to have a dedicated partition that handles only the booting. In that, because it is single purpose there is no backup/restore needed for it. If something happens to it you simple reinstall it.

My experience is limited to BIOS based computers and the one I want to salvage is also a BIOS computer. My understanding is that the Master Boot Record (MBR) is something the BIOS needs to figure out which partition contains the boot loader. In that the MBR is not OS specific it should be the same for either Windows or Linux. Making a partition active has the affect of designating where the boot loader resides. I am aware that, beginning with Windows Vista, Microsoft changed the boot mechanism where it essentially now uses a separate boot partition, which is normally also used for system restoration, and the installation process changed as a result and it has become quite unnatural to do multiboot but I have figured that out and have W7 systems running multiboot without system restore (i.e., the way I'd like to run Linux). Microsoft even claims that this new boot loader can be used to boot Linux but I'd prefer avoiding the need to figure that out assuming that grub2 can do the job.

It looked to me like the grub-install script is used, from a running Linux system, to install grub2 into another partition. I think that what grub2 calls chain loading is how it can find a boot loader in the same manner as the BIOS does but for a Linux system there is no need for a chain loader because grub2 is sophisticated enough to know how to find the Linux kernal and start it without a boot loader. Therefore, in my proposed method of operation the dedicated grub2 partition is active and it displays a menu, using grub2, which allows the desired system to be selected for booting. I would want each of those system to also have grub2 installed in a manner that it could boot that particular system. This provides backup for failure of the dedicated grub2 partition. In that, you make the partition active and it can be booted using the boot loader it contains (but which isn't used when operating in the multiboot mode).

So far the replies have not said that this cannot be done and I'm not persuaded that the alternative approaches are better than what I'm after. Of course if what I'm after cannot be done then they would have to be considered better if they, at least, work.

[oldfred]

Grub2 does not like to be installed to a PBR - partition boot sector. That is the way you would have to install grub to be able to change a boot flag and boot a partition.
Grub does not use boot flag or the active partition. It searches for and finds boot files.

With Linux you have to think & work differently than with Windows.

I keep a copy of a bootable flash drive, and you can easily reinstall grub to MBR to boot whichever system you want to boot.
https://help.ubuntu.com/community/Gr..._Broken_System

But I often have a grub boot on a flash drive which I can manually edit to boot just about anything.

To get each MS to have its own boot loader make a second primary NTFS partition and set its boot flag on, then install the 2nd product in it. Multibooters, Pictures here worth 1000+ words - Vista but all Windows with BIOS/MBR
http://www.multibooters.com/guides/v...-sequence.html
http://www.multibooters.co.uk/multiboot.html
http://www.multibooters.com/
http://www.multibooters.co.uk/articl...ows_seven.html
More tech info - BIOS boot process & some UEFI
http://homepage.ntlworld.com./jonath...t-process.html
https://iam.tj/kb/pc/boot/#a_bootloader

[grahammechanical]

So far the replies have not said that this cannot be done and I'm not persuaded that the alternative approaches are better than what I'm after. Of course if what I'm after cannot be done then they would have to be considered better if they, at least, work.

I am certainly not going to even try to persuade you that it is not possible. It is called freedom. Human knowledge is increased when someone looks at a matter from a different direction and is willing to do things differently.

[yancek]

My understanding is that the Master Boot Record (MBR) is something the BIOS needs to figure out which partition contains the boot loader.

The BIOS doesn't need to "figure out" anything. You set the specific drive to boot, usually a BIOS will have a 'boot' tab with an option under it to set boot priority. If you have two hard drives, drive A and drive B for example and you have drive A set to first boott priority, the BIOS will go to sector 1 on that drive which will have boot code pointing to the location/partition on which the rest of the boot files exist. The sector is far too small to contain all the necessary boot code for any current operating system.

Making a partition active has the affect of designating where the boot loader resides

Simply marking a partition as active/bootable won't boot it, at least with Linux. The active/bootable doesn't mean a thing with Linux systems and isn't used as pointed out above.

Microsoft even claims that this new boot loader can be used to boot Linux

Earlier versions of windows, even xp, could be used to boot Linux and you can certainly do it with the newer bcdedit. I've done this myself just to test it but it is a much more convoluted process that the Linux Grub bootloader.

Therefore, in my proposed method of operation the dedicated grub2 partition is active and it displays a menu, using grub2, which allows the desired system to be selected for booting. I would want each of those system to also have grub2 installed in a manner that it could boot that particular system. This provides backup for failure of the dedicated grub2 partition

Again, the first part of the above quote, it doesn't matter if it is marked active. Even if you have Grub installed on the other partitions, whether you are using one base system without a boot partition or you are using a boot partition, you can only have the code in the MBR pointing to one location so what you are suggesting won't work, at least not without reinstalling Grub to point to that partition. Again, simply marking the partition as active is not going to magically boot another system on a different partition.

You can certainly boot any number of systems directly or by chainloading from Grub2, either on a root filesystem partition or on a separate boot partition.

I don't see how what you appear to want, at least as I understand it, would work. Maybe someone else will have an idea.

[aajax]

oldfred says, "But I often have a grub boot on a flash drive which I can manually edit to boot just about anything."

This sounds pretty much like what I want to do but I'm willing to consume a partition on a hard drive for this purpose. Therefore I have some questions.

1. Is the flash drive bootable? If so, does it only run grub or is it a complete Linux system? If only grub how was it created?
2. How big does the flash drive need to be?
3. What filesystem is used on the flash drive?

Based on feedback received I've followed up and done a little more study. In the GRUB Manual under 3.4 BIOS Installation it says "The partition table format traditionally used on PC BIOS platforms is called the Master Boot Record (MBR) format; this is the format that allows up to four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition."

Based on above it sounds like what I want is the second choice whereas what appears to be recommended and what most of the replies to this post reference is the first choice. However, in my case I don't want anything else in the subject file system and based on other research it looks like many different file system can be used. I would think that the software, possibly booted from an emergency repair disk of some kind, that might need to be used to make a repair would influence the choice of file system.

Let me try to describe a hypothetical scenario to see if it helps explain my objective.

1. I want to run multiple different Linux systems on the same computer. These system are used for testing and experimentation.
2. Lets say I have 2 different systems one in Partition A which is used for booting the other Partition B.
3. Each partition is used for experimenting with software and partimage is used to make backups of configurations that are worth saving.
4. An experiment on Partition A leads to undesirable results that may include the system becoming unusable.
5. Partition A needs to be restored and the image I would like to restore was made from Partition B.
6. An image made from Partition B is restored to Partition A but Partition B was never used for booting.

Note: In the above scenario it is necessary to edit some configuration files in the restored version of Partition A before it will load and work but the restoration does not mess up the grub2 needed for booting if it were located elsewhere.

Where does that leave me when it comes to grub2?

[yancek]

Given you 6 step scenario outlined above, if your Partition A is corrupted and you want to boot Partition B, you could chroot into Partition B from a Live CD/flash drive and install Grub to the MBR rather than moving/restoring it to partition A. Then you could format Partition A and install some other system.

You could install a minimal system, such as Lubuntu if you want an Ubuntu derivative which should be less than a 4GB partition. Have Grub in the MBR pointing to this partition to boot and don't use/change anything on it. After installing another OS to another partition and installing it's Grub to it's partition, reboot Lubuntu and run sudo update-grub which should create a menuentry for the new system. This would seem to be the simplest solution unless you have a very tiny hard drive.

Another option is to use a flash drive and create a boot directory on it and from a working system with Grub2, install Grub to it with a command similar to the one below. You would have to determine the UUID for the flash which should show in the /media/user directory when you plug it in. Change the entry below for user to what you actually have on your computer and also change the UUID to what its is on your system. You would then need to manually create a grub.cfg file. You can use a current grub.cfg or find a simple template online to use and then just put in a chainloader entry for each partition and when you install the new OS, make sure you install Grub to the partition on which you are installing the OS. The command below assumes the flash drive is /dev/sdc so make sure you get the correct drive or you will overwrite the Grub code on one of your other drives.

sudo grub-install --force --no-floppy --boot-directory=/media/user/USB20FD/boot /dev/sdc

menuentry 'CHAINLOAD TEST' {
insmod ext2
set root=(hd0,1)
chainloader +1
}

If the systems you are installing are all Linux, you can put any number of entries in the grub.cfg using this type entry changing only the set root line to reflect the correct partition.