Installer forces you to install grub somewhere

Since I've seen others complain about this on the forums, I would mark this as confirmed, but I'm going to go ahead and skip to triaged since I'm setting the correct priority and I believe all information needed to fix the problem is here.

Very annoying "feature". I run a complex multi-boot environment where I do not want the Ubuntu installer to mess around with my boot loader(s) at all.

Running ubiquity -b will install Ubuntu without a bootloader, as ubiquity --help suggests.

That is nice Evan, but since you both have to know that ahead of time, and have the opportunity to run the installer with a command line argument ( which you don't if you choose to install directly from the boot menu ), that does not help. The GUI interface should still offer the option to not install, as it has in the past.

@Evan Dandrea:

Sometimes I find it hard to keep my cool on launchpad when people just mark a bug "invalid" - this is one such moment. I will not write a comment about ivory towers and nerds or some such, but just quote the Ubuntu motto:

"Linux for Human Beings"

It really doesn't matter that there is some more or less obscure command line switch to install Ubuntu without a bootloader. The GUI installer used to have the switch, it is important to many people - so it should be restored.

I tried installing Natty daily build today (8th feb) and on re-boot Grub didn't find my 'Lucid' OS on sda1 - only offered me the one option 'Natty' in sda5.

Being less technical than some I installed a duplicate 10.04 in sd5 and hey-presto grub offers me both options 10.04 or 10.04.

Sorry for somewhat simplistic description.

Doug

That does not seem to have anything at all to do with this bug Doug.

l3iggs, that is an incorrect use of the In Progress status. It should be set when the bug is assigned to someone actively working on it.

That's a major regression!

Phillip,

If you press Try Ubuntu, you can then open a terminal and launch ubiquity with the -b flag set.

Just because a particular bit of UI existed in the past is not sufficient reason alone for it to exist today. Part of the design goal of the desktop CD installer is to be simple, only do what it absolutely must, then get out of the way. If you need more flexibility than what it offers, please use the alternate CD. Though I must point out that this option did not go away, it's simply exposed in a different way.

If you find my response insufficient, can you please cite a sufficiently large use case where someone would be familiar enough with bootloaders to know that they did not need one, but not familiar enough with the terminal to use it?

Stephan,

I did not "just mark the bug Invalid," and I do not appreciate any suggestion that I closed it without consideration for the contents or without formulating a response. I explained how this functionality is now exposed, then closed the bug. I could have left it open to avoid offending you, but that would mislead people into believing that a different decision had been made.

This is not a matter of ivory towers, but this is not design by committee either. Scope needs to be defined for any project lest it fall into the perils of feature creep, and we have done so here.

It is not a "more or less obscure command line option". The option exists and it is documented. Furthermore, your comment that "it is important to many people" is baseless. What people? I am only interested in cold hard numbers here, not endless speculation. If you feel that the lack of this option fails to address a significantly large use case, then please detail that use case with some data to back up any assertions you make.

Thanks

@Evan:

I am sure you are a very good panelist, as you are brilliant at twisting the discussion in a way that makes it impossible to get in a good answer. I will answer any way:

- You don't have hard numbers to support the removal of the "Don't install boot loader option". You Just assume there is no reason for it to be there. So: no numbers from you.

- At the same time, you demand "hard numbers" from those with an opposing view, knowing that such statistics don't exist.

- As a hint: anybody installing more than one Linux distro on the same machine - or trying to support you by testing alpha and beta versions - may have his or her reasons to have the boot loader left alone by the Ubuntu installer.

- In the end, it just boils down to you telling us that you have decided that it will be that way and we can go to hell.

Personal Note: probably this is moot for me anyway, since the installer in Natty (from alpha1 to current beta) has failed to do one single install for me without crashing.

There are a number of more advanced users that understand that if they want to install Ubuntu and try it side by side with another install, that they do not want it to take over the boot loader. While they likely have at least some level of familiarity with the command line, that does not mean that they could or would discover that they could run ubiquity -b to get the desired results.

At the end of the day, this WAS a feature so the burden of proof should be on the side arguing to remove it ( or make it significantly more difficult to discover/use ). The feature was put in before for good reason, so the question is, has anything changed to justify removing it? Even if there was, the removal of features should be documented in the changelog for ubiquity, as well as the release notes for Ubuntu.

Furthermore, there already exists a drop down list to choose the location to install grub to ( that is only shown on the manual partitioning / advanced installation screen anyhow ); adding one more entry for NOWHERE would not add one bit of additional confusion to the user interface.

Phillip,

I'm happy to add your suggestion of having a "nowhere" entry in the drop down for 11.10 (as we're well beyond UI freeze for natty). It honestly hadn't occurred to me, given the old structure of the option as a checkbox. Thanks a bunch!

Yea, the old structure was somewhat cumbersome. I like the new layout much better, it just needs that one additional entry in the drop down box.

Is this not something that a freeze exception could be granted for, since it is a relatively small change ( at least UI wise ) and is fixing a regression?

It's not a regression from Maverick, as that also had this functionality, and I'm just not comfortable making non-critical changes around the bootloader hours from the final freeze. I'll make sure it gets in early doors in O.

Not seeing updates to this for last month, so explicitly assigning it to team, so gets back on the radar.

Since I do ISO testing sometimes, it is impotant for me too that a new Ubuntu installation doesn't replace my bootloader.
Allthough I got used to always start Ubiquity with the '-b' option, I liked the behaviour of previous versions a lot more, where you could just select graphically that Grub shouldn't be installed.

Kind regards,
Jan

What on earth is "incomplete" about this bug? How hard can it be to add an option "Do not install boot-loader (Advanced Users Only!" to a drop-down menu?

When running from Precise (20111119) I can confirm the same behavior, but in addition to that, when I check the man-pages of ubiquity, there is no -b option at all. Is there now _no way_ at all to not install a boot loader from the ubiquity program? This can't really be the intention?!
According to dpkg ubiquity version 2.9.2 is installed.

EDIT: The -b option seems to be a hidden feature, when I used it, the Device for boot loader installation: dropdown menu was empty, and it looked like it did not install any bootloader.

OK, this bug is well documented and everybody can reproduce it. Since nobody gave any reason for the "incomplete" status, even after asking for arguments a week ago, it is time to set this to confirmed.

Offering a choice of where or if to install a bootloader is something very minimal that an installer must do.

A lot of people are actually scared of using command line. This needs to be in the installer.

The big picture:

It may not be as simple as competing operating system installers, but keep in mind that this is GNU/Linux.

Simple or not, compatibility with multi-boot environments is a fundamental feature.

GNU/Linux was also designed with the ambition to run on just about any kind of hardware.

The little picture:

Personally, I am concerned about this bug since I install ubuntu on a RAID:0.

Theoretically this works (since Jaunty) but the past installers have all failed to install grub to /dev/mapper/raiddrive.

Usually, the installer just fails, but sometimes asks or tries to install to /dev/sda and then fails.

Unless I choose not to install grub and later install it manually from the livecd in a chroot, I don't get a bootable system.

Ideallly, raid installation will be fixed and my issue will be gone, but having the choice is still important.

Oneiric has been released, and since it's a non-LTS release it will not have point images created, so it actually cannot be fixed in oneiric any more.

Precise will have more point releases, but this is a significant feature & UI change as well. This does not qualify for an SRU, as per current policy.

os-prober has improved and now complex multi-boot environments are actually handled better than before.

But I can still see slight benefit of not installing bootloaders. This needs design specification changes, as by default we want to make sure users don't even need to know what a boot loader is and still be able to boot their windows/mac/previous install effortlessly. Also, chances of selecting no bootloader installation by accident should be avoided as much as possible, as recovering/reinstalling grub by hand is not for faint hearted.

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.

This report is still valid for all recent Ubuntu versions (including Focal).

Thanks for the update Jan.