[karmic] grub re-writes boot sector on wrong drive on fresh install

Log files from /var/log/installer on USB drive....

Log files from /var/log/installer on USB drive....

Log files from /var/log/installer on USB drive....

Log files from /var/log/installer on USB drive....

Log files from /var/log/installer on USB drive....

The grub menu appeared when the USB drive was connected to the laptop. Just in case someone else runs into this.... I was able to fix my the main boot record on my laptop (following suggestions on the IRC) as follows:

Insert the USB stick I made to get the grub menu,
boot Windows
Followed this procedure to allow Windows recovery console without admin password
http://support.microsoft.com/kb/312149
rebooted with XP install CD
enter recovery console
run "fixmbr"

I'm told there's an advanced option somewhere in the install to decide what drive to write the MBR for grub. I'm going to test this next, however...

By default, I think that grub should write it's MBR to the drive you've just installed on, rather than picking some other random drive that's not involved in the install. I can understand that someone might want the mbr on a different drive from the boot / root filesystem, but I would think that would be the exception case to bury in the advanced menu.

There is indeed an option in the Advanced menu available from the summary screen which allows you to specify the drive for the boot loader. Pointing this to the USB stick resolves the install problem.... the laptop hard drive was left alone and bootable, and the USB stick now boots with mythbuntu 9.10.

Strictly speaking I suppose that all is behaving as per design intent, and this isn't a bug.

However, because of the potential impact the default grub installation can be a non-booting system, I'd like to encourage the developers to consider making the install default for the grub boot loader to be the install disk.... and allow the user to choose a different disk in the advanced option.

Also, it might be worth pointing out that the hard drive grub modified wasn't the first boot device.... the CD-ROM, and the USB stick were configured in BIOS as booting prior to the hard drive. So, it's a little hard to understand the logic of writing boot loader to the hard drive by default.

Hello Steven Harms:

We are uncertain why this bug was closed on the grub2 project without comment. Was it because grub2 doesn't actually behave the way the reporter describes, or because that is the behavior that is intended (in which case, wouldn't WONTFIX be more accurate)?

Thank you!

Reopening - there was AFAICS no justification for closing this, and I'm not ready for it to be closed yet. I have some plans for this class of bugs.

(Triaging bugs is often an excellent contribution, but please be ultra-careful when *closing* bugs.)

This happened to me too. There are two problems:

1) it defaults to installing grub on hd0 even if you are installing ubuntu to a different drive.
2) it doesn't say anything about it in the summary list, so you don't know you need to click the advanced button to change it.

These are, properly speaking, not grub problems but installer problems and is not new to grub2 but has been happening
at least as far back as feisty when installing to external drives.

The grub part of the bug is that it writes the mbr onto one drive with the first part of the loader which then expects to load the
rest from another drive. If the former is the internal disk and the latter is an external (and therefore not necessarily available)
disk, this is a recipe for disaster.

I think grub should refuse to write the mbr on a drive which doesn't have the rest of it.

Something like this happened when I attempted an Alpha 4 install on a 4th hd, sdb which has an NTFS data partition sdb1, on a second primary partition sdb2. Two other drives (one sdc, one hda) have non-functioning XP partitions. I instructed the installer to write grub to the MBR of sdb. When it didn't boot, I tried chainloading from GrubLegacy on sda which has Mepis 6.5, Hardy, and Jaunty on it. If I use the uuid spec instead of root, it informs me that it is booting from (hd3,1) ext4 [correct uuid] and then immediately follows with: Error 13: Invalid or unsupported executable format, making it seem that GrubLegacy not only is confused about the disk designations, but also is not chainloading. All the other partitions are quite accessible from GrubLegacy, and there is no problem with any of the other OSes . Grub has no stanzas for the XP partitions. Using the 'root' spec in the chainloading stanza calls forth Grub error 22: No such partition. After trying nearly every permutation of commands that seems to hold any hope, I will next try removing the unused XP drives, and then, if that brings no help, rearranging the partitions on the sdb drive. I have already tried reinstalling Grub2 from the LiveCD, with no difference to be seen.

Thanks for your efforts,
Joe

"The grub part of the bug is that it writes the mbr onto one drive with the first part of the loader which then expects to load the
rest from another drive. If the former is the internal disk and the latter is an external (and therefore not necessarily available)
disk, this is a recipe for disaster."

Full ack. I had that desaster! :-(

Even with both drives internal it jeopardizes reliability, since both drives must be OK to boot.

"I think grub should refuse to write the mbr on a drive which doesn't have the rest of it."

Full ack again.
At least it should write the MBR and the rest of GRUB on both drives and backup to the own partition if the other one is not there. But this might be technically difficult with only that few bytes on the MBR, there is probably no room for two partition tables.

Laszlo_Lebrun: was that with the released version of Karmic / Grub2?

Yes it was with Vanilla Ubuntu Karmic using Grub 2.
So the bug is not only Mythbuntu.

Man, that ruined half of my Sunday!

I had a company administred Notebook, for which i have admin rights, but the M$ recovery console asked for the *overall* administrator pasword... just to fix that dam***d MBR and boot record??!.
I finally fixed, after many, many wrong attempts, the MBR and the partition boot record without any password using Linux+Testdisk from C. Grenier.

Laszlo

Hello grazanel, if you believe this information in this ticket to be incomplete, could you please explain why?

This got me too. Some how the initial installation (9.10 I think?) went OK, perhaps because it was using grub1 but an upgrade to grub 2 post installation was not successful in finding my Windows partition (which was working well with grub1), and now I am having trouble getting that drive to mount for inspection purposes. So, I too am attempting to access and locate my Windows partition. Are there any remedies? If so ls post int he follow up. I must access that data. It is critical.

Laszlo: Thanks for recommending tool TestDesk. I will try it.

It would be helpful to know the locations on the file system where the old grub data was saved. For example, seeing the previous grub.conf file would be helpful in unraveling this problem. I am hopeful the installer programs did not destroy that User data without saving it off somewhere.

After many successful 32 bit Karmic installs from a live usb stick to usb
sticks and usb hard disks, I installed a 64bit Karmic from a CDROM (to a usb
stick) and clicking on the Advanced button, noticed the difference in the use
of (hd0) for the boot location instead of an actual device (e.g. /dev/sdb).
I retyped the correct device (/dev/sdb) and avoided wiping out the Windows
mbr (which was on /dev/sda, and which the device.map was mapping to hd0).

Regardless of the install media (usb stick or CDROM), grub-install gets all
the devices wrong in device.map (in this situation).
As a result of the device.map file mapping the Windows sda to hd0, every
device mentioned in the grub.cfg (or menu.lst) is wrong too, even when the
mbr goes to the right location. The boots only work because of the use of
UUIDs. To fix the grub.cfg file, correct the device.map, and rerun update-grub.
e.g. Make hd0 the actual boot device (/dev/sdb), and put the windows /dev/sda on hd1,

if you want to allow the usb stick to boot windows when used on another computer,
edit the grub.cfg to remove the UUID lines for the windows menu items.

See bugs 45989, 46520, and 384633 for some history of using the wrong
device for the mbr.

I'm new to ubuntu 9.10. I have used windows XP for years. Recently, my wife purchased a new HP laptop. It has windows 7 installed. I hate windows 7, and got the bright Idea to download Ubuntu 9.10 64 bit version to CD and install on a 32GB USB flash drive. The install went okay. When I decided to reboot my wifes laptop, I was quickly surprised! I noticed that GRUB was trying to load. I was not expecting to see this as I tried to boot into windows. I was seeing the error "No such disk" Then the rescue grub prompt. Next, I rebooted the PC pressed the escape key, and changed the boot order from BIOS to use my USB flash drive. Well, at least I was able to load GRUB2 menu list now and boot into windows or ubuntu 9.10. Well, I have been reading about this problem for two days now. So what have I learned? First, I need to fix my Windows 7 MBR. Second, I can use the rescue grub prompt to mount my usb flash drive, and load the grub2 menu list. Third, I should have read the bug reports first. Lastly, for anyone who is having my same problem, I found these commands work to load the Grub2 menulist when the multi-boot loader is pointing to the first partition.

1. Boot PC. Grub will fail to load and the Grub rescue prompt will be displayed.
2. At the Grub rescue prompt type the following sequence:

grub rescue> set dev=/dev/sdb
grub rescue> set prefix=(hd1,1)/boot/grub
grub rescue>set root=(hd1)
grub rescue>insmod normal
grub:grub>normal

The Grub menu will now load the menu list. Please note that you will need to know which device is USB flash. In my case, I was able to use ubuntu 9.10 and write down the devices.

When installing ubuntu I had a second hfs+ mac formatted drive installed in my tower. Guess what? GRUB defaulted to this drive which I have not found a way to recover. Aka massive data loss. GRUB should default to the disk you are installing to or have a clear warning message directing users to the advanced install options.

A.J.

For the love of god, please fix this critical defect! There's been ample discussion in this thread on why this "feature" is very, very bad. Functionality that used to just "work" should not suddenly, arbitrarily, and *irrationally* change. I've been putting Ubuntu on flash drives for years. There's nothing more useful than keeping a full Lamp stack in your pocket. Besides, many new Ubuntu users will want to install to a USB to try it out or show their friends. It's a tremendously unwise business decision to make that process harder.

ph

Grub2 also ignores request to not install boot loader.

I installed lucid 10.04 beta 1 to external USB (/sdb). Selected 'Advanced' and deselected 'Install boot loader' (as I use grub2 with my karmic install to boot into lucid). It prompted me - are you sure etc...
It then installed a boot loader anyway on the internal HDD extended partition /sda4.

fdisk -l showed before:
/dev/sda4 123,829,020 146,834,099 23,005,080 5 Extended

and after:
/dev/sda4 123,829,082 146,834,099 23,005,018 5 Extended

Running boot info script shows: "Unknown BootLoader on sda4"

I just spent a long frustrating day messing with this problem. Windows Recovery Console finally rescued me, by re-writing my MBR. Ubuntu sure didn't do much to help. This needs to be fixed right away. This is not acceptable.

I can confirm that installing from CD to an external USB drive/stick still overwrites the MBR of the internal drive on Lucid Beta2.

Possibly related reports:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/45989
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/46520

Also affected: HP Proliant DL140, which has two Bays for SATA drives connected to a LSI Logic Raid Controller.

10.04 64bit Server Beta1, Beta2 and Release Candidate all behave the same when trying to install from USB stick.
Last binary I tried, downloaded a few hours ago: http://releases.ubuntu.com/releases/10.04/ubuntu-10.04-rc-server-amd64.iso

The installer environment detects the USB-Stick as /dev/sda and the only Hard Disk as /dev/sdb.
It displays the following for a second: Running "grub-install /dev/sda"

/dev/sda - the USB stick which contained ubuntu-10.04-rc-server-amd64.iso until now - now has the MBR needed to boot the proliant machine. The MBR on the hard disk drive /dev/sdb is not written.

On reboot with the USB stick disconnected, the screen justs blanks and displays a blinking underscore cursor.
(Without USB stick, the hard drive is detected as /dev/sda)

The USB stick can be used to boot the machine, log in and run "grub-install /dev/sdb", which fixes the problem.

Kind regards,
Flummy

I upgraded to Lucid from Karmic and now I can't boot into Windows 7. I get a blinking cursor.

I did a fresh install of Lucid, back to Karmic, and back to Lucid with no luck.

I tried reinstalling Grub2. Then, I used my Windows 7 disk to get to a command prompt to run:
BootRec.exe /FixBoot
BootRec.exe /ScanOs
BootRec.exe /RebuildBcd

Still can't boot into Windows.

From my post on ubuntuforums.org: http://ubuntuforums.org/showthread.php?t=1466038

Quote:
Originally Posted by Lazy-buntu
When I upgraded to 10.04 it said something like install grub on every partition if you're not sure where to install it. I did on every partition on sda, but most failed. That's when I did a fresh install of Karmic.

Does that help narrow down the problem?

Reply:
OK, that was a mistake. The advice is bad. I do recall seeing the same thing, but I already knew to ignore it. Maybe you should register a bug that the text is misleading. At the very least, the 'install to partition' option should be buried within an 'Advanced users only' button.

So, basically what happened is when you installed grub to your windows partition it pooched windows.

Anyway, first try oldfred's advice - I think he said you may have to do it repeatedly.

If it still doesn't work, this link will do the trick...
http://neosmart.net/wiki/display/EBC...r+from+the+DVD

I'm working on solving my problem still.

I was plagued by this bug as well while installing Lucid from a Live USB - after the install when I rebooted with the USB key removed, the machine gave me an error `error: symbol grub_puts_ not found' and dropped me into grub-rescue mode. Seeking to fix grub from the Live USB, I rebooted with the key inserted - however this time the machine booted up, and instead of going into the live environment, it presented me with my installed desktop environment! When I checked for where grub was installed, it reported as being installed in /dev/sda1, which referred to my USB drive; my hard drive was assigned to /dev/sdbY. Reinstalling grub from this environment to my boot partition (I had separate boot and root partitions) by mounting the boot partition as mentioned in the Community Documentation (https://help.ubuntu.com/community/Grub2) as the first method for fixing grub did nothing but transfer me to a grub> prompt from grub-rescue> prompt on the next reboot (without the USB key). Rebooting with the USB key inserted, and reinstalling grub by running sudo grub-install /dev/sda (the second method for fixing grub on the Community Documentation) installed grub on the root partition instead of the boot partition, which caused problems on the next reboot again. I was in no mood to sit there and debug this all day, so I rolled back to Karmic.

I see two potential issues here - one that on a fresh install, the wrong drive is selected, or at least the user is not asked for where he wants grub to reside. The second is that upon running grub-install to a /dev/sdX, the installer does not check for the presence of a separate boot partition, but installs grub to the root partition.

I believe this is a regression from Karmic, which also employs grub2 and there were no such issues in Karmic - as I verified after rolling back to it. I am hesitant to try installing Lucid, which otherwise seemed to be a solid release, until this issue is resolved.

Any ideas about this? I believe grub2 should exclude the installation media from the menu or its installation - because the user would normally not want that anyway. It should not be writing itself to the installation media (With it having become more feasible to boot from a USB key, I believe there has been a mass exodus of people moving away from burning Ubuntu to a CD).

okay... I think the issue might be more subtle. I tried installing lucid again via usb, hoping to be able to select the correct drive in the advanced options in the installation procedure... what I instead find is that when in livecd mode, gparted reveals my usb drive as /dev/sda, which I believe is selected as the default drive to install grub to, while my hard drive is /usb/sdb. I expect that after installation, this might be humongously problematic, since when the usb is removed, the hard disk would be reported as /dev/sda? Even though fstab would be set up using uuids as opposed to device location, many things, including grub, should expect to face issues upon update?

I also think this is closely related to the following bug:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/565189

Since this issue is not present in grub2 in karmic, this is certainly a regression.

I have so far installed karmic, along with grub2, on three computers, and reinstalled on two, and have not had this problem there - just with lucid. Maybe the nomination for karmic should be declined? Also, any workarounds for this during the installation itself? I feel extreme inertia in trying to fix this issue again post-install through a command line grub or even the other options I have tried before. Needless to say I am anxious to have lucid up and running on both my machines :D

Okay... just tried the alternate installer, and the problem persists. I believe it is easily reproduced - just create a USB installer using USB startup disk creator; boot up the machine with the USB drive, and the USB drive shows up as /dev/sda, with the main hard drive as /dev/sdb. I think it is a matter of writing new udev rules to define what should be what, but I guess as a general rule, the install medium should not be /dev/sda, since that is not what the user would normally want to install ubuntu on.

"Is there anybody out there?" (Pink Floyd, "The Wall")

Another update... I just tried checking the installer on my other laptop (Dell Vostro V13); the hard drive neatly comes up as sda. However, on my VAIO, the hard drive still shows up as sdb and the flash drive as sda. I guess the VAIO is interpreting the flash drive differently, and I don't really understand why. In short, I have been duped for the last two months. So usb drive it is to install lucid on the Dell and a CD for the VAIO. Still perplexed because the karmic installer gave me no such issues.

I can confirm that this still applies to Maverick Alpha 2.

Recap:
- I burned an Mavrick Alpha 2 CD.
- booted from the CD
- for the installation I choose an USB-Stick as the installation partition
- installation was successful
- rebooting without the USB Stick failed

Even worse: the /boot directory of the internal drive was wiped!
I booted from the Alternate CD and had to reinstall the latest kernel manually and then reinstall grub into the boot sector.

Some scripts really seem to be getting confused with the devices the should be dealing with.

I advise anyone to only test in VM's. I currently cannot test VM's due to bug #469419 so I'll resume my testing once something has been committed to fix this issue and this report is closed.

Opps sorry I was mislead! /boot was not wiped!

The boot partition wasn't mounted when I was recovering... so the situation is the same as before. (My bad.)

Grub2 merely gets installed on the wrong device.

>>Now I have two problems.....
>>1) how do I get Windows on my laptop to boot again.... I need my work data!
>>2) how do I make my mythbuntu USB front-end install bootable?

Oh yes, I did face that problem sometime back, and though I love Ubuntu, GRUB needs to improve. I follow the brute force approach only during fresh installations -- take a */+ screwdriver and remove the primary HDD and then install Ubuntu. Since I keep upgrading quite frequently, spending half a day recovering my Windows data is much worse compared to getting a screwdriver and removing the primary boot.

is this still an issue? I wonder the problem might actually be in ubiquity. bug 549756 might be related

Omer. Yes, 549756 is a duplicate of this bug, which as you can see from David's post is still an issue in Maverick.

I agree, this is more likely to be a ubiquity issue than grub2, as it has to do with the installation interface erroneously identifying the boot devices.

Linux is on USB drive, and hard drive is on windows, a pc on which I do not have right to write MBR (company policy) or install anything;

I have grub2 writing on a hard drive MBR automatically sometimes during upgrades of the Kernel;

I would like to exclude any kind of writing permits to grub2 on the hard drive MBR; is it possible?

xubuntu 18.04

best regards

Paolo