Installation of GRUB to MBR should always be confirmed

Bug #47135 reported by Mark Warriner on 2006-05-28
This bug affects 12 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Colin Watson
Declined for Karmic by Colin Watson
Nominated for Lucid by Mark Warriner

Bug Description

Binary package hint: grub-installer

This bug applies to GRUB installation in the dapper-RC Alternate Install CD (text-mode installer).

In standard mode, when no operating systems are detected, GRUB installs to the MBR of the primary hard disk, without any confirmation. This will overwrite a custom boot manager software, or other data stored in the first track of the hard drive without the user's knowledge.

For example, I use the BootIt NG boot manager to test multiple Linux distributions. BootIt NG uses a non-standard partition table called EMBR, stored in the first track after the MBR, to allow access to more than 4 primary partitions (great for creating snapshots to test upgrades). This gets completely wiped out by GRUB, requiring me to boot a rescue disk, then restore it from a backup.

Suggested fix:
In standard mode, always ask the question whether to install GRUB to the MBR, even if no other operating systems are detected, similar to what happens in expert mode now.

This should be a simple fix. I think this is important to get it into the dapper release. I am available to help with testing at any time.

Colin Watson (cjwatson) wrote :

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.

Colin Watson (cjwatson) wrote :

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.

Colin Watson (cjwatson) on 2006-06-05
Changed in grub-installer:
status: Unconfirmed → Confirmed
Prognathous (prognathous) wrote :

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.



Mark Warriner (warriner) wrote :

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.

Roman Polach (rpolach) wrote :

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?

Mark Warriner (warriner) wrote :

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...

Roman Polach (rpolach) wrote :

minimal solution (and least controversial) filled separately at

Mark Warriner (warriner) wrote :

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.

Mark Warriner (warriner) wrote :

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.

Mark Warriner (warriner) wrote :

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

Mark Warriner (warriner) wrote :

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.

   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.

Ryan Anderson (ryan-ghruaim) wrote :

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.

Ryan Anderson (ryan-ghruaim) wrote :

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

hvoss (hvoss) wrote :

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

Russell Gadd (rustleg) wrote :

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.

Colin Watson (cjwatson) on 2010-03-26
Changed in grub-installer (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → Colin Watson (cjwatson)
Launchpad Janitor (janitor) wrote :

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

Changed in grub-installer (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers