This was first posted on the Linux Mint forums, and I have not received any helpful suggestions. I also submitted this problem in a bug report to the Ubuntu bug guys, and I haven't heard back from them either. I've copied the entire post and subsequent posts, so I apologize if this post seems quite lengthy. I just wanted to include all the things I've tried to resolve this issue. As yet, it remains unresolved except for the trick of doing "grub-install" from a Debian 6.3 rescue disk I had lying around.

by oldwierdal on Sat Dec 12, 2015 12:50 pm
I prefer to use grub-legacy to grub2 or grub-pc as I find it to be much easier to edit and control than grub-pc. For years, whenever I changed hard-drives or changed the preferred boot-order of the hard drives, I used the following command'
# grub-install --recheck /dev/sda which would produce an output similar to this;
# grub-install --recheck /dev/sda
Probing devices to guess BIOS drives. This may take a long time.
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/sde
grub successfully installed on /dev/sda. If this differs from your device.map....... and so on.

I have not had occasion to use grub-install since installing Linux Mint 17.1, however, I recently decided to change the boot order of my 3 hard drives. Now, when ever I use this command, I get the following output;

# grub-install --recheck /dev/sda
Probing devices to guess BIOS drives. This may take a long time.
/dev/disk/by-uuid/../../sdb1 does not have any corresponding BIOS drive.

I get the same error whether I use /dev/sda, sdb, sdc, or sde, or even if I use hd0, 1, 2, or 3.
In the first place, I never install the boot loader to a partition such as /dev/sdb1. In the second place, it always says /dev/sdb1 regardless of which /dev/sd* I choose.

by oldwierdal on Sun Dec 13, 2015 10:11 am
(There had been a reply to this on the Linux Mint forum which didn't address the problem, so I excluded it from copying.)
I fell back to basic troubleshooting:
1. Unplugged 2 of the 3 hard drives.
2. Unplugged the usb flash drive.
3. Booted to an old Debian 6.03 amd 64 live installer DVD, scrolled down to 'Text Rescue.'
4. Executed # /usr/sbin/grub-install --recheck /dev/sda. It completed successfully. No problems reported.
5. Repeated steps 1 - 4 with each of the 3 hard drives. Each one completed the command successfully.
6. Added, one at a time, the other 2 hard drives, and finally the usb flash drive.
7. Repeated steps 1 - 4 as I added hard drives, and finally the usb flash drive. All completed the command successfully.
8. Changed the boot order in BIOS setup so that each hard drive and the usb flash drive was designated as the 'first boot' following the CD/DVD in boot order. Each booted successfully.
9. Booted back to Linux Mint 17.1 and tried again the command; and got the original repeated problem.
# /usr/sbin/grub-install --recheck /dev/sda
Probing devices to guess BIOS drives. This may take a long time.
/dev/disk/by-label/../../sda1 does not have any corresponding BIOS drive.
10. Conclusion; There is a bug in the 'grub-install' script.

by oldwierdal on Sun Dec 13, 2015 2:26 pm
I am convinced that this is a bug which was introduced sometime between the launch of LM 17.1 and the release of LM 17.3. This covers a relatively small time span, just one year. But it covers a myriad of patches, upgrades, changes, etc.
I give it this time/release span because the last time I used the command, "# grub-install --recheck /dev/sd*" was after I finished installing LM 17.1 as a 'fresh' install, and then replacing 'grub-pc' with 'grub' (legacy). It worked just dandy then, and, as I pointed out, it works from the Debian rescue disk.

by oldwierdal on Sun Dec 13, 2015 8:47 pm
I found the time to study how to file a bug report, and it has been filed as of 8:35 p.m. Arizona time.
Actually, filing the bug report was easy, once I found out where to do it.

Now, we'll wait and see what happens.


by oldwierdal on Mon Dec 14, 2015 12:48 pm
As a test to prove/disprove my theory that updates to LM 17.1 introduces this anomoly, I re-installed a 'fresh' installation from the live DVD on my "test" drive this morning. After installation, I used the backup tool to re-install all of my optional or extra packages, but I did not allow the update manager to install any updates.
After everything had installed, without any updates, I tried the command, "# grub-install --recheck /dev/sda." It completed without errors. I rebooted to the test drive again, and, once again tried that command. Again, it completed successfully.
Then, I allowed the update manager to do all of the updates. After that finished, I tried the command again..... And it failed again, just as before. Conclusion; Something in the updates introduces this problem with grub (legacy) grub-install!

I hope this information is helpful in finding the cause of this.

by oldwierdal on Tue Dec 15, 2015 10:11 am
This morning I installed Ubuntu 14.04.1 "Trusty" on my /test drive. After all the updates, I installed grub (legacy). Then I ran the same command; # grub-install --recheck /dev/sdb .
And this is the output;
# grub-install --recheck /dev/sdb
Probing devices to guess BIOS drives. This may take a long time.
/dev/disk/by-label/../../sdb1 does not have any corresponding BIOS drive.

I am not surprised at this. My intent was to further isolate the source of the problem by installing the 'basis' of Linux Mint 17.x, and attempting the same command. The obvious conclusion, no surprise here, the problem with "grub-install" is in the "grub" (legacy) scripts which comes from Ubuntu.

As I am really reluctant to use grub-pc, I really hope that this bug is addressed and fixed soon.

Perhaps, while I'm wasting some time fiddling with this problem, I'll try to install and set up grub-pc to my liking so that, just in case the developers do not intend to spend the time required to fix this problem, if and when I have the need to re-install the grub boot loader on other drives, I won't be left without a boot loader.
Ahh, the struggles of the aging population, trying to bend the new technology and all the other "new and better" stuff to fit our 50, 60, 70+ aged habits and life styles.

But, I ramble....
Thanks,
owa

luddite ...

More relevant, look here. Nobody is going to fix grub legacy - not upstream, and not the Ubuntu devs as they had such a large hand in grub2 development.
I think you're tilting at windmills. We all had angst initially, but we've all had to move on. You too I reckon.

Boot into Mint and open the Update Manager. See if Grub 2.02 is listed in the list of available upgrades. If it is NOT listed - then that means that when the Grub 2.02 upgrade was made available recently, you accidentally installed it when updating. That could transform your Grub 1 system to Grub 2 without your being aware of the change.

OR - you can enter the command:

Thanks TxLonghorn, the output from your suggestion is;
$ apt-cache policy grub2
grub2:
Installed: (none)
Candidate: 2.02~beta2-9ubuntu1.6
Version table:
2.02~beta2-9ubuntu1.6 0
500 http://ubuntu.securedservers.com/ trusty-updates/universe amd64 Packages
500 http://security.ubuntu.com/ubuntu/ trusty-security/universe amd64 Packages
2.02~beta2-9 0
500 http://ubuntu.securedservers.com/ trusty/universe amd64 Packages
which suggests to me that, in fact, grub2 is NOT installed. From the beginning, I have listed all things grub to be ignored by update manager.

And, syg00, I am afraid that I must agree; any glitch introduced into grub-legacy will probably be considered 'collateral damage,' and will not be given any significant time, if any time at all, to fix it.

Thanks, both of you for your replies.

owa