Ubiquity manual partitioning offers to install grub in a way that breaks Windows boot

Bug #1049549 reported by YannUbuntu
38
This bug affects 8 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The "Something else" option (= manual partitioning screen) allows the user to change the location where GRUB stage1 will be installed.
("Device for bootloader installation" combobox).
AFAIK, the default entry in this combobox is /dev/sda. Currently the combobox also allows to select any partition (eg /dev/sda1 , /dev/sda2...)

The following entries break Windows boot and MUST be removed:
- all partitions (eg /dev/sda1 , /dev/sda2...) containing Windows boot files (bootmgr, ntldr). In other words, all partitions detected as "Windows" by os-prober.

Probably the problem is the same with systems other than Windows, so I recommend to remove all partitions detected by os-prober.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

If I have multiple linux distributions I may want to re-install grub to the partition with '/boot' from the other install, not the current one.

There are no conflicts on EFI partitions, as when we install in UEFI mode grub uses it's own subdirectory as per UEFI spec.

Why should I not install on top of Windows partitions? Maybe I'm done with windows, do not want to boot it but want to keep it for accessing it's files?

Just because these options are useless for you, it doesn't mean that grub cannot be installed into them and be useful to somebody else.

Changed in ubiquity (Ubuntu):
status: New → Incomplete
Revision history for this message
YannUbuntu (yannubuntu) wrote :

"If I have multiple linux distributions I may want to re-install grub to the partition with '/boot' from the other install, not the current one." ----> why would you want to do that?

"There are no conflicts on EFI partitions, as when we install in UEFI mode grub uses it's own subdirectory as per UEFI spec." ----> ok

"Why should I not install on top of Windows partitions?" ----> erasing Windows for Ubuntu installation is another subject. What I am talking about in this bug, is that when you install GRUB in the PBR of a Windows boot partition, the consequence is that Windows won't boot anymore. This is a very frequent problem on forums.

"Maybe I'm done with windows, do not want to boot it but want to keep it for accessing it's files?" ----> in this case you don't need to install GRUB into Windows PBR.

Changed in ubiquity (Ubuntu):
status: Incomplete → New
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

"If I have multiple linux distributions I may want to re-install grub to the partition with '/boot' from the other install, not the current one." ----> why would you want to do that?
because grub is multi-os bootloader. Regardless of where it is installed: so if I have /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 and my /boot is on /dev/sda2 and fedora on /dev/sda1 & ubuntu on /dev/sda3, it actually does makes sense to install grub-pc stage1 bootcode into /dev/sda. (we are not talking about the extra files which will still end up on the file system)

"Maybe I'm done with windows, do not want to boot it but want to keep it for accessing it's files?" ----> in this case you don't need to install GRUB into Windows PBR.

Well it is recommended by grub upstream to install stage1 onto /dev/sda and not the partitions e.g. /dev/sda3

---

Just to be clear:
If Windows is installed onto /dev/sda1 you are saying it is potentially harmful to install grub into /dev/sda1 or /dev/sda?

summary: - Ubiquity proposes useless options that break Windows boot
+ Ubiquity manual partitioning offers to install grub in a way that may
+ break Windows boot
Revision history for this message
YannUbuntu (yannubuntu) wrote : Re: Ubiquity manual partitioning offers to install grub in a way that may break Windows boot

"if I have /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 and my /boot is on /dev/sda2 and fedora on /dev/sda1 & ubuntu on /dev/sda3, it actually does makes sense to install grub-pc stage1 bootcode into /dev/sda." ---> exactly.

"Well it is recommended by grub upstream to install stage1 onto /dev/sda and not the partitions e.g. /dev/sda3" ---> I know.

"If Windows is installed onto /dev/sda1 you are saying it is potentially harmful to install grub into /dev/sda1 or /dev/sda? " -----> sda1 only. And this is not "potential" but SYSTEMATIC.

description: updated
summary: - Ubiquity manual partitioning offers to install grub in a way that may
- break Windows boot
+ Ubiquity manual partitioning offers to install grub in a way that breaks
+ Windows boot
YannUbuntu (yannubuntu)
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :

FYI, here are examples of XP that couldn't boot because GRUB stage1 has been installed in its PBR:
http://paste.ubuntu.com/1144006
http://paste.ubuntu.com/1145142
Bug #1050653 (remark: this is NOT a duplicate)

Here are examples of Windows7 that could not boot because stage1 was in its PBR:
http://paste.ubuntu.com/1102905
http://paste.ubuntu.com/1167512
http://paste.ubuntu.com/1158396 (separate Windows boot partition)
http://paste.ubuntu.com/1109157

FYI, see also how to fix a PBR (to remove stage1 from it): https://help.ubuntu.com/community/BootSectorFix

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Another recent example : bug #1059623

Revision history for this message
Max Vi (maxoudevi) wrote :

This bug affects me too, as a new Ubuntu12.04 user, I installed GRUB inside the Windows partition, because I thought it would make Windows boot first. However, this broke my Windows.
I can only boot on Ubuntu now.
Anyone knows how to delete the grub inside windows?
Afterward I think by simply restoring the MBR, it would be fixed, right?

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Max,
Ubiquity broke your Windows bootsector (not the MBR) by putting GRUB in it.
This can be fixed either via TestDisk or via a Windows recovery disc, see https://help.ubuntu.com/community/BootSectorFix

Revision history for this message
Max Vi (maxoudevi) wrote :

Thanks for your help but unfortunatly it doesn't work,
I end up with:
_____________________________________________________
Disk /dev/sda - 320 GB / 298 GiB - CHS 38913 255 63
     Partition Start End Size in sectors
 1 * HPFS - NTFS 0 1 1 32604 251 4 523799014

Boot sector
Status: OK

Backup boot sector
Status: Bad

Sectors are not identical.

A valid NTFS Boot sector must be present in order to access
any data; even if the partition is not bootable.

 [ Quit ] [ List ] [Org. BS ] >[Rebuild BS] [ Dump ]
_________________________________________________________

any ideas?

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Then TestDisk cannot help. Try via a Windows disc: https://help.ubuntu.com/community/BootSectorFix#Via_a_Windows_disc

Revision history for this message
oldfred (oldfred) wrote :

We still see this. I see about one user a week having this issue and I have to have them use testdisk to restore backup or use Windows repairs to fix.

It seems to be in several different places. Original install under Something Else or dpgk reinstall of grub. But in all cases it seems that partitions with essential boot code already in them are offered as choices for grub2 to install into.

Supposed fixed long time ago?
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/576724

Revision history for this message
mue.de (emuede) wrote :

I had a functioning dual-boot system with ubuntu-12.04.4 LTS and Windows Vista (which was previous installed).

I wanted to setup a home-Server with that elder fujitsu-siemens Desktop (pae-capable) and had the problem of too less space at the /home-directory at the original 40GB (!!) drive.
I spent a second sata-drive with 160GB and move the home-Folder to a new partition: everthing worked fine.
Then the root-Partition went out of space: so i decided to move the windows-Partition (8GB) at the end of the first harddisk (with gparted, booted from a live-dvd) to get more room for the ubuntu root-Partition '/'.
I didn't had problems with gparted so far, but now: none of the systems is bootable anymore.
I just see the grub rescue prompt
[code]
Booting
error: no such partition
grub rescue>
[/code]
I tried testdisk and ran the boot_info_script, which results can be found at http://paste.ubuntu.com/7923979/
(the /etc/fstab shows at that point some attached usb-drives, that are normally not mounted)

How can i get the system booting again?

Thanks for any advice

Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

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.

Changed in ubiquity (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
Revision history for this message
aaronfranke (arnfranke) wrote :

This bug is still valid in Ubuntu 20.04. Selecting partitions individually for bootloader installation will corrupt that partition. Only drives should be selectable as options, not their partitions. Selecting a partition is never valid and the ability to select them needs to be removed.

Changed in ubiquity (Ubuntu):
status: Expired → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.