I'm relatively inexperienced with Linux and I have nagging doubts on how things with the GRUB bootloader work.

I have Ubuntu installed in /dev/sda1 and its GRUB bootloader is installed in /dev/sda.

Now I want to install Debian in /dev/sda2 (keeping Ubuntu in /dev/sda1) and the installer is asking me where I want to install its GRUB bootloader.

I figure that since I have already Ubuntu's bootloader installed in /dev/sda I should not even have to install a second bootloader. Am I right? All I would need to do, after installing Debian, is to bring Ubuntu's command line up and launch Right?

And yet Debian wants to know if I want its bootloader in /dev/sda or /dev/sda2.

I did some research online about all this but I've gotten even more confused. Can somebody help?

PS: These are standard OS installations on a BIOS (not UEFI) PC with EXT4 partitions, if that helps.

Hi tb75252 ... You are correct - you do not need to install a second instance of Grub after installing another OS (Debian or otherwise). Updating Grub in the Ubuntu session should detect Debian and add it to the boot menu.

Cheers,

Yes that will work.
If you install Debian boot loader to sda2, you could create an entry in /etc/grub.d/40_custom to chainload the debian bootloader. By doing so would eliminate the task of going back to Ubuntu to update grub every time there is a kernel update in debian.

Interesting suggestion! And I suppose that if it were Ubuntu to have a kernel update, the chainloading for Debian in /etc/grub.d/40_custom would not be affected, right? In other words, when Ubuntu "rebuilds" GRUB due to a kernel update it would not get rid of the chainloading. Am I correct?

I can't seem to be able to find a good example of chainloading two Linux distros. All I find is chainloading examples with Microsoft Windows. Does anyone know of a chainloading tutorial with only Linux OSs?

I realize that you're going to be using Ubuntu and Debian, but the ArchLinux Wiki is an excellent resource and its entry on Grub is quite extensive, including sections on chainloading. It wouldn't be a waste of time, in my opinion, were you to consult it.

Cheers.

2 members found this post helpful.

If you actually see an option in the Debian installer to not install Grub then that should work and reboot to Ubuntu and sudo update-grub.
If you want to chainload you need Grub.

Sample chainload I use on a flash drive to boot a second partition which is what you want below;

you will have to run update-grub after editing /etc/grub.d/40_custom for the chainloader entry to show on your grub menu

I second Rickkkk's suggestion of checking out the Arch linux wiki. While there are some things that will be more distribution specific, I would say most things are fairly universal among the linux distros. Especially relating to grub, being that grub boots before linux, it is really platform independent

You may run into problems by trying to install to a partition as it may complain about using blocklists. An ext4 file system has only 1024 bytes free at the start of the partition. This is far too small for the core.img (32K) second stage so a list of sectors is sometimes put in this 1K of space to point to the core.img in the file system. Recent versions of grub don't like to do this easily with MBR partitioning. With BIOS/GPT booting you have a separate 1 MiB BIOS Boot partition in which to place the core.img.

There is another easier way to get a similar effect to chainloading and that is connfig file loading. In this approach the grub of Ubuntu will load the config file of Debian in its /boot directory. You will need to have the grub system files in your /boot directory but don't have to install boot code to the 1K PBR.

In my case I load the config file of Fedora 24 from the grub controlled by Centos 7 with the following entry in my /etc/grub.d/40_custom. This approach will boot faster as there is only one grub executable and is simpler as there is no need to install boot code to the 1K PBR. I have a separate /boot partition so the uuid is of the /boot filesystem and the config file path is shorter. If you don't have a separate /boot partition the uuid will be of the / file system and you will have configfile /boot/grub2/grub.cfg.

As a multibooter for more than 2 decades, I like tofino_surfer's suggestion a bit more than colorpurple21859's. That said, if your Ubuntu Grub ever fails, then Debian boot will be unavailable too until Ubuntu's Grub is repaired.

What I do is install Grub only on primary partition(s) never to be mounted to /boot or root, and use standard MBR code pointing to the Grub primary partition. IOW, I never put any Grub on any MBR. I maintain the bootloader on the primary partition(s), and make all root partitions logicals. Consequently if one distro's bootloader fails for any reason, one or more others will always remain available, both for normal use, and for facilitated repair of any broken one. This equally applies when Windows is also installed, whether before or after installing Linux(es).

mrmazda What bootloader do you use in the MBR or it is just nulled out and let bios handle it?


tofino_surfer I have seen a few ops mentioning chainloading with config files. I have considered doing it on my efi system versus using the efind bootloader I use now. I've never really thought about it on a bios system, mostly because I'm using lilo with some of the distros I multiboot. May swap everything over to grub, and give configfile chainloading a whirl.

Neither. All a BIOS does is load and start execution of the MBR sector's code block. If it were null, you'd get nothing post-POST completion. "Standard MBR code" is DOS/OS2/Windows/Lilo/Grub/etc.-compatible code, which does no more than locate the primary partition with the boot flag set, loads its PBR, and starts its execution. If the flag is set to a Windows partition, Windows' bootloader starts. If the flag is set on a partition with some other bootloader on it, that bootloader is started. If Windows' bootloader starts, such as immediately after Windows installation, but you want Grub to start, it's a very simple matter to boot into Windows and use one of its MBR sector tools to move the boot flag to a primary partition containing Grub. If Windows refuses to perform updates because it has not boot control, it's again a simple matter to move the flag to the Windows primary, let Windows update, then move the flag back to the primary with Grub. Thus Windows can be installed or reinstalled at any time without (more than nominally) disrupting any installed FOSS OS. Meanwhile, no installed distro's bootloader will wrest control from any other, due to each having been installed to its own root (or /boot). And, by (optionally) disabling os-prober, each distro's boot menu can be kept simple, providing only stanzas applicable to that one distro, which can be very welcome on machines with more installed OS than can fit in a single screen boot menu.

I didn't think it would work with a nulled MBR, but wasn't sure. On My bios system I also have the os-prober disabled to keep things simpler.

It can be handy to have an alternate boot-device, which you can quickly flip-to on a BIOS or system-firmware screen, which is also capable of correctly booting the computer.

I don't care for the additional complexity and complications of chain loading or even a second boot setup.

My preference would be:

1) Do NOT install grub at all in the second OS (Debian).

2) Boot into Ubuntu as necessary to run "update-grub" - it will autodetect the Debian install and set up appropriate boot option in Grub for it.

3) Create a minimal Debian (or Ubuntu) install on a usb drive.

If for some reason the Ubuntu grub is borked, do the following steps:
Fundamentally, this strategy minimizes the maintenance effort involved. There's just one "mastermind" OS controlling a simple centralized grub setup. If for some reason that setup gets borked, then I go through the small extra effort of updating grub on a minimal USB install. This utility USB thumbdrive is a useful rescue OS for all of my computers, not specific to just one. As such, its grub setup will be specifically set up for whatever the heck was the last computer setup I ran "update-grub" on. Too much effort and too silly to try and "maintain" that grub setup. I just run "update-grub" when necessary to help rescue a system.