upgrades of the grub-pc package can overwrite wrong MBR

I can confirm this bug. The problem appears to be that Grub2 will include the line
set root=(hdX,Y)
when installing grub on the external hard drive. In my case I had 3 internal drives on the machine that I used to configure the external drive. So the line root=(hd3,1) was included which works fine if the machine plugged into identifies the external drive as (hd3,1) but not if the machine has, say, two internal drives so identifies the external drive as (hd2,1).

This is a major regression from Grub 0.97 where it was possible to specify by UUID to avoid such problems. Using the command set root=UUID=uuid_string_of_numbers dosn't appear to work in Grub2. This is my original menuentry in /boot/grub/grub.cfg:-

menuentry "Ubuntu, Linux 2.6.31-17-generic" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
 set quiet=1
 insmod ext2
 set root=(hd3,1)
 search --no-floppy --fs-uuid --set fd0c6442-dc3d-49ba-8e46-91657460fe52
 linux /boot/vmlinuz-2.6.31-17-generic root=UUID=fd0c6442-dc3d-49ba-8e46-91657460fe52 ro
 initrd /boot/initrd.img-2.6.31-17-generic

I have tried a custom entry by creating a file (07_UbuntuUSB) in etc/grub.d and running as follows:

menuentry "UbuntuUSB, Linux 2.6.31-17-generic" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
 set quiet=1
 insmod ext4
 set root=UUID=fd0c6442-dc3d-49ba-8e46-91657460fe52
 search --no-floppy --fs-uuid --set fd0c6442-dc3d-49ba-8e46-91657460fe52
 linux /boot/vmlinuz-2.6.31-17-generic root=UUID=fd0c6442-dc3d-49ba-8e46-91657460fe52 ro
 initrd /boot/initrd.img-2.6.31-17-generic
}

It shows in the grub boot menu ok then fails because it it cannot find a file (but doesn't report which file it cannot find - another enhancement request please). The UUID refers to the boot partition on the external drive which contains the grub files and the os.

I would welcome some advice on how to post with a more pleasing layout too.

Am Mittwoch, den 06.01.2010, 21:15 +0000 schrieb bwallum:
> set root=UUID=fd0c6442-dc3d-49ba-8e46-91657460fe52
> search --no-floppy --fs-uuid --set
> fd0c6442-dc3d-49ba-8e46-91657460fe52

The search --fs-uuid --set line will set $root the device with that
UUID.
There's no need to change the set root and set root=UUID= like used with
the Linux kernel is just wrong and doestn't work.

>
> It shows in the grub boot menu ok then fails because it it cannot find
> a
> file (but doesn't report which file it cannot find - another
> enhancement
> request please). The UUID refers to the boot partition on the external
> drive which contains the grub files and the os.

For now you have to type the commands of grub.cfg into GRUB's
commandline yourself to see it.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

This bug is exactly what's covered by the foundations-lucid-reliable-device-id-in-grub specification, so I've linked them.

Pretty sure this bug toasted my Pointsec encrypted primary drive. Karmic was installed entirely on secondary HD with primary not present (to make sure I didn't overwrite the mbr and break Pointsec). I then used the bios menu to switch between drives to boot.

Booting the primary started showing GRUB recently. Tried to fixmbr from the Windows Rescue Disk to no avail.

This should fix the core of this problem. I expect that it will need a few more tweaks, but that's why I'm landing it a couple of months before release. :-) If you have problems with this, please file them *separately* rather than following up to this bug, otherwise I'm going to get very confused very quickly!

I do plan to apply this to Debian as well, but unfortunately it requires some lockstep changes in grub-installer which is currently frozen for a d-i release. I'll deal with that as soon as possible.

grub2 (1.98~20100128-1ubuntu1) lucid; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Adjust for default Ubuntu boot options ("quiet splash").
    - Default to hiding the menu; holding down Shift at boot will show it.
    - Set a monochromatic theme for Ubuntu.
    - Apply Ubuntu GRUB Legacy changes to legacy update-grub script: title,
      recovery mode, quiet option, tweak how memtest86+ is displayed, and
      use UUIDs where appropriate.
    - Conflict with grub (<< 0.97-54) as well as grub-legacy.
    - Fix backslash-escaping in merge_debconf_into_conf.
    - Remove "GNU/Linux" from default distributor string.
    - Add crashkernel= options if kdump and makedumpfile are available.
    - If other operating systems are installed, then automatically unhide
      the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus
      if available to check whether Shift is pressed. If it is, show the
      menu, otherwise boot immediately. If keystatus is not available, then
      fall back to a short delay interruptible with Escape.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Don't display introductory message about line editing unless we're
      actually offering a shell prompt. Don't clear the screen just before
      booting if we never drew the menu in the first place.
    - Remove some verbose messages printed before reading the configuration
      file.
    - Suppress progress messages as the kernel and initrd load for
      non-recovery kernel menu entries.
    - Keep the loopback file open so that subsequent changes to the "root"
      environment variable don't affect it.
    - Change prepare_grub_to_access_device to handle filesystems
      loop-mounted on file images.
    - Ignore devices loop-mounted from files in 10_linux.
    - Show the boot menu if the previous boot failed, that is if it failed
      to get to the end of one of the normal runlevels.
    - Handle RAID devices containing virtio components.
    - Improve DM-RAID probing support.
  * Don't generate /boot/grub/device.map during grub-install by default.
  * Store grub-pc/install_devices as persistent device names under
    /dev/disk/by-id/. Migrate previous device names to that, with explicit
    confirmation in non-trivial cases to make sure we got the right ones. If
    the devices we were told to install to ever go away, ask again.
  * If the user opts to install GRUB nowhere, make sure they really mean it.
  * Backport disk read fixes from upstream.

 -- Colin Watson <email address hidden> Wed, 03 Feb 2010 16:53:33 -0800

symbol 'grub_puts' not found
grub-recover >

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/509797

^ bug report told me to post here.

I'm having this prob on 10.04 beta every time grub gets updated. The only fix I found was to boot into 9.10 (only live cd I have) and restore grub. Is there any permanent fix for this?

http://ubuntuguide.net/how-to-restore-grub-2-after-reinstalling-windows-xpvistawin7

Upgraded from Karmic to Lucid today and am also having the "symbol 'grub_puts' not found" error described by illbashu; I have the Ubuntu install on a different drive from sda, so I had to reinstall grub2 for Karmic also. I haven't rebooted yet after reinstalling grub2, but I assume I'll run into the same need-to-keep-fixing-it problem as illbashu... would definitely be nice to have a permanent fix!

the permanent fix is to remove the Dell Backup Utility.

Rob.

On Sat, Apr 17, 2010 at 9:31 PM, M Pietila <email address hidden>wrote:

> Upgraded from Karmic to Lucid today and am also having the "symbol
> 'grub_puts' not found" error described by illbashu; I have the Ubuntu
> install on a different drive from sda, so I had to reinstall grub2 for
> Karmic also. I haven't rebooted yet after reinstalling grub2, but I
> assume I'll run into the same need-to-keep-fixing-it problem as
> illbashu... would definitely be nice to have a permanent fix!
>
> --
> upgrades of the grub-pc package can overwrite wrong MBR
> https://bugs.launchpad.net/bugs/496435
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Religion easily has the best bullshit story of all time. Think about it.
Religion has convinced people that there’s an invisible man…living in the
sky. Who watches everything you do every minute of every day. And the
invisible man has a list of ten specific things he doesn’t want you to do.
And if you do any of these things, he will send you to a special place, of
burning and fire and smoke and torture and anguish for you to live forever,
and suffer, and burn, and scream, until the end of time. But he loves you.
He loves you. He loves you and he needs money.

This bug might interact with the Dell Backup Utility, but I hit this
bug every time I install Ubuntu with Grub2 on my no-name, custom PC.
My computer uses a SATA DVD, and has lots of hard disks. The BIOS disk
enumeration may change for Grub when the system is running the
installation DVD, then disk ejects, reboots from the hard disk.

In any case, I am certain that removing any Dell utility will not
resolve the situation for me, as there are no such on this machine.

On Apr 18, 2010, at 3:47 AM, bigdoby <email address hidden> wrote:

> the permanent fix is to remove the Dell Backup Utility.
>
> Rob.
>
> On Sat, Apr 17, 2010 at 9:31 PM, M Pietila
> <email address hidden>wrote:
>
>> Upgraded from Karmic to Lucid today and am also having the "symbol
>> 'grub_puts' not found" error described by illbashu; I have the Ubuntu
>> install on a different drive from sda, so I had to reinstall grub2
>> for
>> Karmic also. I haven't rebooted yet after reinstalling grub2, but I
>> assume I'll run into the same need-to-keep-fixing-it problem as
>> illbashu... would definitely be nice to have a permanent fix!
>>
>> --
>> upgrades of the grub-pc package can overwrite wrong MBR
>> https://bugs.launchpad.net/bugs/496435
>> You received this bug notification because you are a direct
>> subscriber
>> of a duplicate bug.
>>
>
>
> --
> Religion easily has the best bullshit story of all time. Think about
> it.
> Religion has convinced people that there’s an invisible man…
> living in the
> sky. Who watches everything you do every minute of every day. And the
> invisible man has a list of ten specific things he doesn’t want you
> to do.
> And if you do any of these things, he will send you to a special
> place, of
> burning and fire and smoke and torture and anguish for you to live
> forever,
> and suffer, and burn, and scream, until the end of time. But he
> loves you.
> He loves you. He loves you and he needs money.
>
> --
> upgrades of the grub-pc package can overwrite wrong MBR
> https://bugs.launchpad.net/bugs/496435
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “grub2” package in Ubuntu: Fix Released
> Status in “grub2” package in Debian: New
>
> Bug description:
> Binary package hint: grub2
>
> The grub-pc package calls grub-install on upgrades. The drive to
> install to is stored in debconf as a string like "/dev/sdb". The
> problem is that /dev/sdb won't always be the same device if drives
> are moved around or, where the situation is particularly bad, when
> Ubuntu is installed to an external drive and used on multiple
> computers as a "live" system. For this reason everywhere else in
> Ubuntu I can think of file systems are specified with UUIDs rather
> than device names. For specifying drives, /dev/disk/by-id/ seems to
> give a unique way to identify a disk. grub-pc should store something
> like "/dev/disk/by-id/usb-OEI-
> USB2_Ultra_Disk_Drive_090706000466-0:0" instead of "/dev/sdb" so
> there is no chance of installing to the wrong disk on grub-pc
> upgrades.
>
> As an example: If you install Ubuntu to an external USB drive on
> computer that has only one internal drive then grub-pc/
> in...

This bug impacts all who have multiple SATA drives. While DELL may be
corrupting things for _some_ users, my workstation doesn't have a single
Windows partition on it.

Grub DOES NOT HONOR the BIOS drive enumeration.

If you have more than one disk drive, YOU CANNOT INSTALL this or any later
version of Grub because it will choose its own order. In my case, I put a
FreeDOS partition and a FAT-32 extended partition on the first bootable drive
per the BIOS. After installing Ubuntu, there was no method of booting DOS
from Grub because Grub changed the device numbering in a non-BIOS compatible
way.

Until Grub honors the BIOS device order, this bug will be a constant PITA

On Sunday 18 April 2010 05:06:06 pm Boyd Waters wrote:
> This bug might interact with the Dell Backup Utility, but I hit this
> bug every time I install Ubuntu with Grub2 on my no-name, custom PC.
> My computer uses a SATA DVD, and has lots of hard disks. The BIOS disk
> enumeration may change for Grub when the system is running the
> installation DVD, then disk ejects, reboots from the hard disk.
>
> In any case, I am certain that removing any Dell utility will not
> resolve the situation for me, as there are no such on this machine.
>
> On Apr 18, 2010, at 3:47 AM, bigdoby <email address hidden> wrote:
> > the permanent fix is to remove the Dell Backup Utility.
> >
> > Rob.
> >
> > On Sat, Apr 17, 2010 at 9:31 PM, M Pietila
> >
> > <email address hidden>wrote:
> >> Upgraded from Karmic to Lucid today and am also having the "symbol
> >> 'grub_puts' not found" error described by illbashu; I have the Ubuntu
> >> install on a different drive from sda, so I had to reinstall grub2
> >> for
> >> Karmic also. I haven't rebooted yet after reinstalling grub2, but I
> >> assume I'll run into the same need-to-keep-fixing-it problem as
> >> illbashu... would definitely be nice to have a permanent fix!
> >>
> >> --
> >> upgrades of the grub-pc package can overwrite wrong MBR
> >> https://bugs.launchpad.net/bugs/496435
> >> You received this bug notification because you are a direct
> >> subscriber
> >> of a duplicate bug.
> >
> > --
> > Religion easily has the best bullshit story of all time. Think about
> > it.
> > Religion has convinced people that there’s an invisible man…
> > living in the
> > sky. Who watches everything you do every minute of every day. And the
> > invisible man has a list of ten specific things he doesn’t want you
> > to do.
> > And if you do any of these things, he will send you to a special
> > place, of
> > burning and fire and smoke and torture and anguish for you to live
> > forever,
> > and suffer, and burn, and scream, until the end of time. But he
> > loves you.
> > He loves you. He loves you and he needs money.
> >
> > --
> > upgrades of the grub-pc package can overwrite wrong MBR
> > https://bugs.launchpad.net/bugs/496435
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
> > Status in “grub2” package in Ubuntu: Fix Released
> > Status in “grub2” package in Debian: New
> >
> > Bug description:
> > Binary package hint: grub2
> >
> > The grub-pc package calls grub-install on upgrades. The dri...

Heads up... the http://ubuntuguide url mentioned in comment#7 links to a Windows virus downloader. Can someone please remove that url from this report/issue?

I upgraded my Karmic to stable Lucid yesterday, today when i rebootet i got this error to. So to claim it is fixed in Lucid is wrong.
I have two SATA drives. The "first" with windows (with two NTFS partition) and Kubuntu Karmic (with / /home /var ext4 partitions) and the "second" with only one ext4 partition.
Downloading the Live CD now to see if I can reinstall Grub2

Hey all after an hour on Google I found a fix that worked for me for the Grub_puts_ error.

http://ubuntuforums.org/showthread.php?t=1014708

I am currently dual-booting Windows 7 with Ubuntu 9.10. After upgrading to 10.04 though I got the grub_puts_ error. I just used my Ubuntu 9.10 disk and followed those 3 commands, restarted and computer booted no problems. That was a worrisome hour but the Ubuntu community always has a good fix out there!

Bump. I can attest that this symptom is present in release Lucid. I performed an over-the-wire upgrade from 9.10 to 10.04. On reboot, got the "symbol `grub_puts_' not found" error. Interestingly, although there are two SATA HDs in this machine (one spinning media, one solid-state), the BIOS enumerates the SSD first, the BIOS boots off the SSD, the grub rescue mode enumerates the SDD as (hd0), and the 2.6.32-22 boot files are at (hd0,1)/boot. When the upgrade was running, /dev/sda was the SDD. I don't find any way that the grub install/setup during the upgrade could have become confused about which drive was supposed to get grub installed on it, nor any evidence that the drive enumeration would have changed. (The spinning disk, sdb, a.k.a. (hd1), has my 5.somtething - 9.04 repeatedly over-the-wire upgraded image and files, which is still attached since I'm not convinced I have all my settings transferred over...)
(time passes)
Huh. Booting from the spinning disk gets a grub2 style menu that can boot into 10.04 on sda. Now how do I fix it so grub's in the right MBR?
(time passes)
Trying "sudo grub-install --root-directory=/ /dev/sda" as per http://ubuntuforums.org/showthread.php?t=1014708 , linked by Jack Fariss (#14). Reboot. Change BIOS boot order to boot the SDD (sda, hd0) first again. Reboot. Success!

So, for no apparent reason the 10.04 upgrade seems to have pushed grub onto the MBR of 10.04 or possibly the lingering 9.04 grub on sdb's MBR was able to find the 10.04 images and boot them. Either way...

The problem is that Grub does not respect the BIOS ordering, which
means it doesn't play with Windows, FreeDOS, DR DOS, or any other OS
that does respect BIOS ordering for multi-drive systems.

On Thursday, May 06, 2010 10:45:28 pm you wrote:
> Bump. I can attest that this symptom is present in release Lucid. I
> performed an over-the-wire upgrade from 9.10 to 10.04. On reboot,
got the
> "symbol `grub_puts_' not found" error. Interestingly, although there
are
> two SATA HDs in this machine (one spinning media, one solid-state),
the
> BIOS enumerates the SSD first, the BIOS boots off the SSD, the grub
rescue
> mode enumerates the SDD as (hd0), and the 2.6.32-22 boot files are
at
> (hd0,1)/boot. When the upgrade was running, /dev/sda was the SDD.
I
> don't find any way that the grub install/setup during the upgrade
could
> have become confused about which drive was supposed to get grub
installed
> on it, nor any evidence that the drive enumeration would have
changed.
> (The spinning disk, sdb, a.k.a. (hd1), has my 5.somtething - 9.04
> repeatedly over-the-wire upgraded image and files, which is still
attached
> since I'm not convinced I have all my settings transferred over...)
(time
> passes)
> Huh. Booting from the spinning disk gets a grub2 style menu that
can boot
> into 10.04 on sda. Now how do I fix it so grub's in the right MBR?
(time
> passes)
> Trying "sudo grub-install --root-directory=/ /dev/sda" as per
> http://ubuntuforums.org/showthread.php?t=1014708 , linked by Jack
Fariss
> (#14). Reboot. Change BIOS boot order to boot the SDD (sda, hd0)
first
> again. Reboot. Success!
>
> So, for no apparent reason the 10.04 upgrade seems to have pushed
grub
> onto the MBR of 10.04 or possibly the lingering 9.04 grub on sdb's
MBR
> was able to find the 10.04 images and boot them. Either way...

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.logikalsolutions.com
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

I installed GRUB 2 already in Karmic. There where several kernel updates, which implied a GRUB menu update. there was never a problem.

But the update from 9.10 to 10.4 and a reboot produced the error "symbol `grub_puts_' not found".

There are an IDE and a SATA harddisk

neither sudo grub-install /dev/sdb nor sudo grub-install /dev/sda

helped but changing the boot order in the BIOS helped

Got the same issue using ubuntu-10.04.1-alternate-amd64.iso. I run a MD RAID for the root but have a small ext2 partition at the start of the first drive for /boot.

Was the fix in 10.04? If it was then it did not work for me.

I recovered by live booting a CD, installing mdadm, assembling the RAID, mounting all the partitions, chroot'ing into the fresh install and then running grub install (see: https://wiki.ubuntu.com/Grub2#Recover Grub 2 via LiveCD)

Same here, it hit me when upgrading from Kubuntu 10.04 to 10.10beta, on an amd64 system with multiple sata drives. I had to boot from the live image and chroot.

 Shouldn't that part of a grub/system upgrade ask for user input, since this is SO critical? This is a killer for non-experts!

The problem is that Grub doesn't identify SATA drives in the same order as the
BIOS. It is really easy to see if you have 3 SATA drives and each have
different sizes.

I have argued and argued and argued and argued, but I keep hitting a stone
wall. FreeDOS and Windows both manage to identify hardware in the same order
as the BIOS, they even honor BIOS overrides which change drive ordering, but
Grub....not so much.

On Sunday, September 12, 2010 09:57:49 am you wrote:
> Same here, it hit me when upgrading from Kubuntu 10.04 to 10.10beta, on
> an amd64 system with multiple sata drives. I had to boot from the live
> image and chroot.
>
> Shouldn't that part of a grub/system upgrade ask for user input, since
> this is SO critical? This is a killer for non-experts!

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.logikalsolutions.com
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. soldiers have been deployed to defend our ethanol reserves.

I hit the bug upgrading from 10.10 from 10.04 running AMD 64. I have multiple SATAs and RAID, but only the one operating system. Very frustrating as I've left my USB key with xubuntu for such moments at work! So, in short, the bug still exists.

Tim

I hit the bug also, in Kubuntu AMD 64. However, I have only one hard drive. No RAID.

Was able to use the LiveCD to chroot in and fix GRUB, but this bug, lasting this long......very disappointing. Blogged about it: http://linuxgrandma.blogspot.com/2010/10/grub2-and-chroots-dammit.html

I encountered this bug today upgrading Kubuntu from a clean 10.04 install to 10.10 using the update-manager tool. The machine is 32-bit. It has no SATA controller at all. It's not a Dell (it's an older Asus-based dual athlon MP system). There is only one hard drive in the system. There is no other operating system on the machine; just one bootable partition which has Ubuntu installed. There were no errors during the install, except that a reboot left me hanging at "error: the symbol 'grub_xputs' not found" with a grub rescue prompt.

The only odd thing about the drives in this system is that there are two DVD burners on the on-board ATA controller, there is one ATA-133 drive attached to a 3Ware 8-port IDE RAID controller (Escalade 7500-8), and I have /boot set up as a separate partition, with an LVM root. I came here due to bug #609280 being marked a dup of this one.

I can run "ls /" at the prompt, and it shows that there is a grub/normal.mod file visible. However, when I try to insmod grub/normal.mod, I get the undefined symbol message from above.

Did Canonical hire the former Gentoo quality assurance team? :) I upgraded two (single drive) laptops today as well, and they both had kernel problems post-reboot. And now this bug which has been open for a year? Really? Sigh, off to find the rescue disks. Lemme know if there's any further information I can contribute which helps fix this. Or any further poking upstream Debian with a stick I can do.

@Danny Sauer

This bug has been fixed. And as you have only one hard drive it could not, by definition, have ever affected you.

Unless, in its infinite wisdom of not identifying devices in BIOS order, Grub
also decided to identify devices as whatever type it chooses rather than what
they are. It could have "identified" the RAID controller connected CD/DVD as a
hard drive even though it wasn't and choose to try updating that MBR.

For the record, FreeDOS still will not boot once KUbuntu is installed. I even
cannibalized my machine down to one physical SATA drive and Grub STILL luggies
up C: as far as FreeDOS is concerned....

siiiiiiiiiiiiiiiiiiiiiiiiiiggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhh

On Friday, October 15, 2010 06:32:00 pm you wrote:
> @Danny Sauer
>
> This bug has been fixed. And as you have only one hard drive it could
> not, by definition, have ever affected you.

--
Roland Hughes, President
Logikal Solutions

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

@Seasoned_geek

Please re-read the bug description, this has nothing to do with how the BIOS orders devices. Additionally, it is impossible to reliably determine the BIOS's order from within linux which, among other reasons, is why grub2 instead identifies filesystems by UUID.

This bug has EVERYTHING to do with how the BIOS orders devices and how Grub
just outright ignores that ordering despite the fact every other PC based OS
can get that information from the BIOS and respect it. They can even honor
the device order selected by the user from the boot menu.

When Grub chooses the wrong *&)(&)(*&^ing drive as the boot drive, it updates
the wrong MBR.

We have had this discussion many many many times. The DOS emulator people can
get it right. The wine people can get it right. FreeDOS can get it right and
so can most other OSs. Grub chooses not to.

On Friday, October 15, 2010 07:24:21 pm you wrote:
> @Seasoned_geek
>
> Please re-read the bug description, this has nothing to do with how the
> BIOS orders devices. Additionally, it is impossible to reliably
> determine the BIOS's order from within linux which, among other reasons,
> is why grub2 instead identifies filesystems by UUID.

--
Roland Hughes, President
Logikal Solutions

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

@Jordan - I technically have 2 drive controllers. One RAID controller exposing a single drive, and one PCI ATA-133 controller holding two optical drives. I'm not sure how this bug could be considered "fixed" if grub is still failing to identify the correct drive upon which it actually needs to install. That behavior would seem to inherently be required for this bug to be closed - and observation indicates that the behavior desired is not complete. However, I agree that the description doesn't match well (I just followed the dup). I'll continue follow-up in the newly unrelated bug report - #609280. :)

I used update-manager to update from 10.04 to 10.10, and I got the infamous "grub-xputs".
I have two SATA disks and memory card reader.
With 10.04, SATA disks were enumerated before memory card readers (sda, sdb then sdc, sde, sdd, sdf).
With 10.10, memory card readers are enumerated before SATA disks (sda, sdb, sdc, sdd then sde, sdf).
If I boot on a USB key, it's inserted between memory card reader and SATA disks (which become sdf, sdg).
Previously, it was easier to guess enumeration order of mass memory (and to help other users).
As I did many things, I'm not sure of what solves issue, but it seems it was when I booted on CD-ROM instead of USB key.
I also set MBR on both disks!

Grub MUST MUST MUST MUST MUST support the BIOS device order.

Why must Grub boot with Unix code? Why cannot Grub boot with whatever
bootstrap IBM used with the boot manager they shipped with OS/2? That boot
manager always respected device order AND it could boot any OS, including
various Linux of the day...of course...if I remember correctly, that one used
its own thin boot partition to work its magic.

If the Unix bootstrap cannot directly communicate with the BIOS to determine
device order and type, then, there is no reason to use the Unix bootstrap
code, use code that actually works.

On Tuesday, October 19, 2010 02:15:47 pm you wrote:
> I used update-manager to update from 10.04 to 10.10, and I got the infamous
> "grub-xputs". I have two SATA disks and memory card reader.
> With 10.04, SATA disks were enumerated before memory card readers (sda, sdb
> then sdc, sde, sdd, sdf). With 10.10, memory card readers are enumerated
> before SATA disks (sda, sdb, sdc, sdd then sde, sdf). If I boot on a USB
> key, it's inserted between memory card reader and SATA disks (which become
> sdf, sdg). Previously, it was easier to guess enumeration order of mass
> memory (and to help other users). As I did many things, I'm not sure of
> what solves issue, but it seems it was when I booted on CD-ROM instead of
> USB key. I also set MBR on both disks!

--
Roland Hughes, President
Logikal Solutions

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

To work around this (annoying) bug see [1], specifically Section 13 Reinstalling GRUB 2 from LiveCD

[1] http://ubuntuforums.org/showthread.php?t=1195275

 I got this problem on upgrade to 10.10 and then again on 11.04. I was also concerned that when I booted from a usb stick then the stick was sda and my hard drive(I only have one...windows vista boot as well) was sdb so I didnt feel confident to do a grub install, so ended up creating a live dvd and did the install from that. Note that a grub install from 10.10 didnt work, had to do it from 11.04

Same here. My desktop system with 2 sata hard drives just rendered itself unbootable after upgrading Kubuntu 10.10 -> 11.04

As far as I can tell, "Fix Released" is not a proper characterization for this bug's status, and this is a CRITICAL bug. I really don't mean to flame, but we can't afford having people click on the "A new distribution version is available" button, only to get a black screen after booting, not to mention losing access to poprietary operating systems already installed

Cheers!
Leo

I had to abandon Ubuntu for OpenSuSE 11.4 which doesn't have this issue.

The root of the problem is that Ubuntu DOES NOT RESPECT BIOS ORDERING but just about everything else does. What Ubuntu "appears" to do is quite stupid, it "appears" to ASS-U-ME that your largest drive is your boot drive, rather than a data drive. When it encounters two or more "largest" drives of the same size, it appears to toss three coins and count the number of heads which came up, choosing that number as the current "boot" disk.

grub currently only works on a single disk machine.

If you need a stable machine you will have to switch to OpenSuSE 11.4, or some other distro.

Frank and Leo, could you post the output of 'sudo debconf-show grub-pc',
plus /var/log/installer/syslog and /var/log/installer/partman? I
suspect that at some point something (perhaps the installer) recorded
the wrong disk as the installation target, and that got preserved.

seasoned_geek: please give it a rest. There are many ways to
constructively get our attention on a problem; harping on and on about
the same misunderstanding is not one of them. BIOS ordering is a red
herring. Please stop abusing us about it on this bug.

Colin:

BIOS ordering is NOT a Red Herring. I'm not abusing you, I'm attempting to educate you since there appears to be a shocking amount of ignorance on the issue.

FeeDOS, Windows, OpenDOS, PC DOS 2000, and OS/2 all do BIOS ordering and do it correctly.

When your user base has a second OS installed, what are the odds it is on this list?

Better question. Why does the grup in OpenSUSE 11.4 respect BIOS ordering and the one with Ubuntu does not?

The thing that's needed is consistency, not agreement with BIOS
ordering. The necessary property can be expressed quite simply: once
you choose to install GRUB to a given disk on installing the OS,
upgraded versions should be installed to that disk again on upgrades.

BIOS ordering does nothing to help with this since it can be changed in
BIOS Setup menus. We achieve consistency nowadays by recording the
by-id links for disks rather than any other one of the possible names:
the by-id links encode properties such as the serial number of the disk.

In cases where this goes wrong on upgrade, it is typically because the
disk device name was mis-recorded somehow; sometimes it's user error,
but I certainly wouldn't rule out the possibility of further bugs in
GRUB's debconf integration, or installer bugs whose effects hang around
even after they'd been fixed. If you could stop going on about BIOS
ordering any time somebody brings up a problem, I might be able to have
a coherent conversation with bug reporters to find out why!

The thing which is needed is agreement with the BIOS because ONLY THAT CAN PROVIDE CONSISTENCY WITH THE OTHER OPERATING SYSTEMS. They ALL respect the BIOS, even the boot order changes done in PROM or at boot time via a hot key.

Claiming BIOS ordering is irrelevant is simply demonstrating a complete lack of knowledge regarding the booting of every other PC based OS. If you could actually learn about BIOS ordering you wouldn't need further conversation on this issue because you would actually FIX the problem.

By ignoring the BIOS drive ordering, if you magically happen to cobble together something which gets the boot drive and partition correct (so far, not a big worry), you reek havoc on the other operating systems. Most people who run multiple operating systems keep spare FAT-16 and/or FAT-32 partitions around lying around for data transfer. These partitions typically appear before their removable devices and appear in a BIOS predictable order. When you try to magic-magic behind the scenes, this changes the drive mapping order and their boot scripts, which worked perfect prior to the installation of Ubuntu-grub, no longer work.

It is obviously not impossible to honor the BIOS mapping at boot time since it appears the boys and girls working on OpenSuSE 11.4 managed to do it. FreeDOS boots and works like it should. The FAT-32 transfer partitions all are mapped correctly, and yes, my BIOS selects the drive it boots from.

There are a number of inaccuracies in this comment, but there's no point
discussing this further with somebody who clearly isn't interested in
hearing what we have to say. I'm not prepared to spend any more time
explaining how GRUB works in this bug report. Please allow us to debug
user problems in our own way; you have already said you're using another
OS now.

My statements were and are completely accurate.

I'm using a different OS because this problem has existed for YEARS in the Ubuntu distribution and I could no longer function with a single disk computer.

Ubuntu is the ONLY Linux distro having this problem.

Hi Colin,

I am attaching the required info. Apparently I can only add one at a time.

Thank you so much for looking into this. Cheers!
Leo

Ok, I added all the info, I hope it helps. I took the liberty to add a couple more useful outputs.

My computer boots from /dev/sdb , but I always keep a grub in /dev/sda just in case. Both of them failed to load grub after the upgrade (I only run grub-install > /dev/sda every once in a while, I only do it since I started hitting this bug).

I have been running Kubuntu for ... 2 years now on this computer? So there are several layers of upgrades, and there is certainly the possibility that an old setting is bothering things, as Colin stated.

@ Frank: I showed the commands I ran on the command line to generate teh attachments, in case it helps.

@seasoned_geek: please note that this is not a forum where users exchange _opinions_, but rather a bug tracker. Even when you are trying to help, you are introducing noise, which actually hurts the chances of getting things fixed.

I noticed a reference to a third partition in the grub-pc output:

grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1001FALS-00J7B1_WD-WMATV1484210-part3

Does this mean that the upgrade is trying to install grub on a partition instead of the MBR? But, assuming that's the case, why does the old grub in the MBR stop working? (I have an older version of Kubuntu in another partition, and grub doesn't even show me that)

Oh well, I hope I gave enough info to shed some light. Thanks!

Leo:

I'm not introducing opinions. I have introduced facts which have been completely ignored by "support" because it doesn't fit their opinion of how things should work.

Ubuntu is the _only_ distro with this problem. Every other distro acknowledged the facts. Here we have erroneous opinions claiming to provide support.

Colin: do my logs shed any light? Let me point out that updates to grub during the life of the distro did not ruin the MBR. It has only (and consistently) happened when upgrading to a newer distro version.

With that in mind. Why don't we ask the user for confirmation before writing to the MBR? Would that be feasible? It seems to me like such a critical step would merit an extra click

Thanks
Leo

Leo:

Exactly how many "user" level people will understand a disk ordering other than what they see in their BIOS boot display, assuming they actually watch that display?

If a "user" has only one disk, or had no two disks the same size, they might be able to figure out that BIOS disk 0 is /dev/sdc to grub, but, if they have two or more disks of the same size (common with machines having 250G and 1TB disks for some reason) they cannot identify which one _should_ really boot because grub tosses 3 coins and counts the number of heads at each boot when it chooses which like sized device goes first.

   This spring we announce a wonderful competition! Become our customer and win it easily!

        Dear 496406,

Even if your sex life is already rich and fulfilling... Imagine you had a little more energy... if your erections stayed harder... or you could go just a little longer...
Or maybe you worry, when you climb under the covers, that you’re starting something you can’t finish?
Well, now advancements in natural medicine are making it easier than ever to promote a strong libido, firm, natural erections and enhanced desire.

Now thanks to this exciting natural breakthrough, you could get an erection “on demand” and when you do, sustain it long enough – and keep firm enough — to fully satisfy your wife in bed. Even if you’re in your 50s, 60s, 70s, 80s or older!

As a doctor, I’ve learned something over the years that may surprise you — age has very little to do with sex. There are men out there having the best sex of their lives well into their 80th year and beyond.

And those men have three key things in common that their sex starved friends don’t:
Hard, recurring erections...
Heightened desire and stamina...
And a reproductive system that could be functioning at the top of its game...

   Lucky? You bet.

But you too could give your body the nutrients it needs to support your entire sexual health.

   Antibiotics play an important role in modern medicine fighting infections caused by bacteria.

************

>>> www.pharmacyprescriptionweb.com.ua <<<

************

This is still an issue in Oneiric. Here is my case:

* a computer with two hard-drives. One of the MBR of these is used to bottup normally
* I introduced a USB stick with Kubuntu 11.04, booted from USB, and upgraded to Oneiric (11.10)

After the upgrade, the MBR in the HD of the desktop computer was now damaged, it would no longer boot from HD

The fix was, as usual, to boot the HD partition from the USB's Grub, and then run grub-install /dev/sdX , where X was the appropriate value (either a or b).