Single OS booting:

1-limits opportunity to real-world test or experiment with any new (or copy of existing) OS before committing to it (live images by their nature offer only a subset of a regular installation, a particular example of which is updating)

2-limits opportunity to contribute to FOSS development via alpha/beta testing and bug reporting (testing of your specific hardware cannot be entirely valid, or possibly at all, with of a VM layer interposed)

3-keeps/gets you working quickly after something goes wrong with a new installation and available time runs out and/or you can't identify the original installation media or the USB stick you made bootable too long ago to remember

Simple is good for many, maybe most, but simple is not always as simple as it looks or one might want - one scenario cannot best fit all. Operating systems need occupy only a small fraction of space available on multi-TB storage media or the larger SDDs, so allocating space to another full OS, or more, can be a very smart choice.

Ubuntu is a Debian distribution so there won't be issue dual booting both Operating Systems, as long as the first one was properly installed. Ubuntu is a variant of Debian OS so in this case, during installation you could ignore the installation of the bootloader or you install it in a separate partition. The first bootloader in the /boot sda partition will be read, first, into memory before reaching the lower partition(s) in the hierarchy.

If you still have any issues, post your grub.conf script here for guide on how you could manually edit the script to read from the sda**, where you have installed the second OS.

You're absolutely right, however, every linux OS is going to offer to install grub. It's completely painless. And it puts your new OS at the top of the grub list. Plus, how much time does it take to let it install grub? How much time does it take to have to boot to ubuntu and update-grub?

More competent users such as the other posters in this thread understand that it is actually simpler to maintain when set up. People don't want to boot up a different OS whenever they update a kernel as well as rely on os-prober to generate meaningful entries.

Actually os-prober may detect the kernels but will often generate useless entries in grub.cfg that need to be hand edited. os-prober has many shortcomings and they are mentioned by grub developers. The use of a hierarchical setup with configfile loading is desceribed in official grub2 documentation as a recommended approach.

There is a very recent thread in LQ about a poster who is actually doing what "you recommend" and wants to abandon grub as a result. After being informed of the configfile approach they used it.

http://www.linuxquestions.org/questi...9/#post5731173

Everyone has a favorite method of dealing with multiboot on MBR-based systems. I do too.

• 1st Linux distro install on a hard drive - /boot gets its own partition (I label it Boot) mounted on /boot; grub installed to HDD's MBR
• Boot into 1st Linux.
• Unmount Boot partition from /boot, remount at /mnt/Boot
• As root, copy contents of /mnt/Boot to /boot
• Forcibly install grub to Linux distro's root partition
• Modify /mnt/Boot/grub/grub.cfg to chainload Linux distro's grub
  
  Code:

  menuentry 'GF27 on sda7' {
      insmod part_msdos
      insmod ext2
      set root='hd0,msdos7'
      chainloader +1
  }

• When installing a new (additional) distro, force grub into the new distro's root partition
• Manually add another entry to Boot partition's grub/grub.cfg

A bit of work to set up and runs the risk of overflowing the PBR (hasn't happened yet), but if I choose to overwrite one distro with another, I don't need to change anything in the Boot partition

Speak for yourself. I am "people" and I'd rather have everything under the control of my main OS than to have to do some extra weird work to boot into another OS in order to repair its chainloading bootloader, and figure out precisely where something was broken to even figure out where something was messed up.

With pure Debian/Ubuntu family OS's and Windows, the os-prober does a fine job. And what's wrong with having an entry that's still pointing to the older kernel? It'll still boot, and it can be fixed up at one's leisure with update-grub.

Is it for everyone? No, not everyone. But I'm completely competent at setting up and maintaining the bootloaders on my systems - probably a hell of a lot more competent at customizing network and ramboot boot options than you, and my solution is the one that is best for me, after many years of using Linux. I hate dealing with chain loading bootloaders. I love having it all in one place where I can control everything, making it easy to clone and migrate stuff to different partitions on different computers, and even sync them up just by using rsync on the file systems rather than worrying about some sort of weird crap for partition level chain bootloaders also.

That user who you convinced to switch methods? Maybe he'll be happy with the way things turn out with that. Maybe not. But I'm not the one patronizingly insulting others saying there's only one "competent" correct way of doing things. I state my preference and recommendation, and the completely accurate reasons for it.

You are describing yourself as two different people, a competent one who wants to control, another who wants an OS to control.

I want control, so I give no OS or its bootloader control over anything except the (optional) bootloader on its own root filesystem. It's up to me, myself and I to keep the primary bootloader doing its job, without any interference from as many as 55 installed operating systems and nearly as many different bootloader versions, all on one HD per PC.

Giving up control to an OS probably works best for those less competent and those with only 2-4 installed operating systems. As the installed OS count goes up, it makes more and more sense for the admin to be more involved. The beauty is both kinds of admins have that choice available, and representatives of each type stand ready here to help those in need.

You think I am giving up control, but this makes no sense. Do you hand code your own bootloader (not GRUB or LILO, but your own bootloader, written from scratch in C or some other suitable language)? Do you write your compiler from scratch? Do you wire up the mainboard by yourself? Did you design the firmware yourself? No, of course not. And yet you think you control it, right? That's the thing about control. You don't need to control each and every detail in order to have overall control. You use tools, and if you are competent at using those tools you control them. If you are comfortable with the level of control you have, and you get the job done, then you've got it.

I have full control, I'm just doing it in a smarter way for my purposes. I am perfectly competent at hand coding a fully customized GRUB2 boot entry, and I have to do so in order to do some of the more esoteric things I use (like NFS-RAMBOOT). But my ability to utilize the os-prober to assist maintaining other entries makes me better at maintaining my systems than if I laboriously hand customize boot entries for the more normal entries. In fact, I've figured out how to take advantage of the os-prober's behavior in order to have it automatically generate the correct RAMBOOT entries (not practical with NFSROOT entries, since an nfs root location must be specified, unless I hard code it into the initramfs scripts, which then makes it impossible to share a single initramfs among multiple NFS-RAMBOOT systems).

The bottom line is that I know what the os-prober will do, and I guide things so that it does precisely what I want it to do. That's not giving up control. That's controlling it. The reason it generates good RAMBOOT entries isn't because the upstream developers anticipated my custom situation and accounted for it. The reason is because the os-prober is flexible enough to recognize particular common situations, and I devise my RAMBOOT techniques to look like one of them in a way to generate the working results I want. Not just for myself personally, but also to make it easier for someone using my how-to blogs to get the technique working for them. Fewer steps and fewer places to make a mistake is better for this!

Again, this pernicious idea that there is just one correct way and every other way is a sign of incompetence is just insulting and inaccurate.

What pernicious idea?

In your first post in this thread you essentially insulted everyone who uses a hierarchical approach which is recommended by grub developers. The shortcomings of os-prober are also mentioned by grub developers. By the way the word maintain does not require quotes.

You don't appear to understand this but with config file loading there is only one bootloader executable running and that is the one of your main OS. The config files are hierarchical but only one bootloader is running. If Ubuntu was your main OS controlling grub and you updated a kernel in Debian you would just run update-grub in Debian to update its grub.cfg and that would be it. You wouldn't need to boot into another OS such as your main OS. The config file for Debian and any other distributions would be referenced form the main grub.

You also don't seem to understand that by trying to maintain a single grub.cfg you would constantly need to boot back into your main OS Ubuntu every time something was changed in another distribution. This actually adds more work each time which is why that other user wanted to abandon grub entirely and was happy with my suggestion. They certainly didn't find it silly. Once entries for referencing the config files of other distributions are added to the main grub in 40-custom you never need to boot back into that OS. Once it is set up it is far less effort to maintain which is why grub developers recommend this approach.