Installation of GRUB to MBR should always be confirmed

I recognise your concerns, but it's been like this since at least Hoary (in fact, I'm pretty sure Warty behaved the same way) and I don't think it's urgent to spend the limited time available to me before release on changing this for Dapper, particularly since this was one of the things I was explicitly asked to do in pursuit of the goal of reducing the number of questions asked by the installer. I think it's more appropriate to visit this at more leisure after the Dapper release.

Reducing severity since it's really very rare indeed for this to be any kind of data loss; those with custom boot managers generally have suitable rescue disks available.

I'd also like to see this confirmation added. As far as I recall, Dapper overwrote my MBR without asking first, and I do have many other operating system installed on the machine. I'm using System Commander.

Thanks!

Prog.

I would like to re-open this discussion.

I think always confirming GRUB install to MBR in standard mode of the Alternate Install CD (Debian Installer) is the most appropriate action for the following reasons:
1. Avoids overwriting data or boot manager programs that might be stored in the MBR or first track.
2. Reducing the number of questions asked is less critical now that the Desktop CD is the primary installation method for most users.
3. It is a question that would be asked anyway if another OS, such as Windows, were detected.
4. There are cases where the detection fails to actually find other OS, e.g. hidden or encrpyted root. It is very nice to have a catch-all confirmation for such cases.
5. We say on the download page that the Alternate Install CD supports "installing GRUB to a location other than the Master Boot Record". It is misleading to deny this choice in some cases.

If the team agrees, can we target this fix for Edgy 6.10, and possibly Dapper 6.06.2?
Please let me know how I can help in any way.

I thing the reasonable solution would be that installation process
asks for confirmation on rewriting MBR at least when another *non-windows*
system on disk partitions is detected... because this case means:
1) those another systems are probably linux/bsd/... systems and there
is probably already grub/lilo/... installed which user may want to preserve
2) this also means that user is as far experienced as he/she prefer one more confirmation dialog over data loss.

Another solution would be display this confirmation dialog if and only if user
choose manual disk partitioning... because of 2)...

I really thing this is one of most critical bugs (if not the most critical one) in ubuntu.. could be fixed for feisty?

I think we should have confirmation on where to install GRUB in all cases, due to the reasons I outlined previously. This is also the simplest and lowest risk change.

I would love to see this fixed in Feisty...

minimal solution (and least controversial) filled separately at https://bugs.launchpad.net/ubuntu/+bug/97174

rpolach,
The bug you reported (#97174) applies to ubiquity: the graphical installer on the Desktop CD. This bug (#47135) applies to the text mode installer on the Alternate Install CD and Server CD.

Can this be considered in the upcoming Intrepid 8.10 and Hardy 8.04.2 releases?

To clarify, we would like to see the original Debian and Ubuntu behaviour restored, with the initial dialog box asking if it is OK to install GRUB to the MBR, followed by the optional second screen asking where to install it with some examples given. I think this should be done regardless of the result of any OS detection for the reasons I outlined above in my 2006-09-21 comment.

Given the current focus on installer QA, can this be addressed for Januty 9.04?

I've nominated this bug for Karmic 9.10.

Reasons why I think this issue should be addressed:
   1. Special boot managers or important data stored in the first track of the hard disk can be overwritten by the automatic installation of GRUB. For example, an Extended MBR (used by BootIt NG) is completely overwritten, resulting in loss of all partitioning information. Even with Windows installation, only the first sector (MBR itself) is overwritten, which is a well known behaviour and much easier to recover from.
   2. Currently, the text mode installer provides a choice of GRUB install location only if other operating systems are detected, or certain partitioning options are chosen. The problem is OS detection is not always accurate. I have test cases that demonstrate this. Why not play it safe and always confirm?
   3. On some systems, BIOS issues may make the detection of which device is the first hard disk unreliable in some cases, e.g. booting from USB CD-ROM or installing to a USB hard disk. If the install location of GRUB is always confirmed, these issues can be worked around much more easily.
   4. For several releases, the graphical installer (both old and new design) has had the ability to choose a GRUB installation location, regardless of OS detection status. The alternate text mode installer should also have this choice, since it provides a superset of the installer functionality, with options such as RAID, LVM, and encryption.
   5. The consistent confirmation of GRUB install location was originally removed in order to simplify the Ubuntu installation process at a time when the graphical installer did not exist. Since the alternate text mode installer is now only used for special cases, this should no longer be a concern.
   6. This bug has been open with Medium importance for 3.5 years now, and based on Colin's comment was originally planned to be addressed (or at least considered) in the Edgy 6.10 cycle.

Recommendation:
   1. Always ask the Yes/No question of whether GRUB should be installed to the Master Boot Record of the first hard disk, regardless of OS detection results or partitioning options.
   2. If the user chooses 'No', present the standard dialog for specifying GRUB install location.
This is consistent with the original debian-installer operation, and would address all concerns outlined above.

I just applied updates, through the update manager, and it overwrote the MBR on a new disk I had installed for VMware. Please ask in any instance like this.

Ignore that; sorry, the order got swapped and I jumped to conclusions.

This error still occurs in Ubuntu 10.04 (Lucid Lynx) Beta 1.

I can confirm the behaviour Ryan experienced: I applied a normal update which included an update to grub (not sure whether via update manager or synaptic) and it overwrote the MBR. Updates shouldn't break the system.

Also like Mark Warriner I use BootitNG which embeds its own code in the MBR and also allows you to hide partitions from the currently running OS. So it may not be possible to detect whether there is another OS present, therefore this shouldn't be relied upon in order to decide whether to offer a choice to the user.

Mark's proposals are well argued and I support them.

This bug was fixed in the package grub-installer - 1.49ubuntu9

---------------
grub-installer (1.49ubuntu9) lucid; urgency=low

  * Ask grub-installer/only_debian at high priority again (LP: #47135).
    Originally, in Warty, we ensured that this question wouldn't be visible
    by default to support simple installations of Ubuntu with as few
    questions as possible. However, since then, we wrote Ubiquity, which
    has taken over responsibility for the simple installation case, and it's
    become clear that automatically installing GRUB to the first disk's MBR
    is inadequate for many more complex situations. Ironically, Ubiquity
    makes this option easily accessible from the "Advanced" dialog box, but
    Ubuntu's d-i required a special boot parameter to display it.
  * Update grub-installer/bootdev text to avoid GRUB device naming that
    changed between GRUB Legacy and GRUB 2, and to use libata-style device
    naming since that is more accurate for most people (LP: #391775)
 -- Colin Watson <email address hidden> Fri, 26 Mar 2010 11:34:43 +0000