When my kernel is updated, my system will not boot.

[Jeremy LaCroix]

Binary package hint: grub

I'm using 64-bit Hardy.

Whenever I get Ubuntu updates in the update manager that involve updating the kernel, and thus updating the /boot/grub/menu.lst, my menu.lst file is changed to incorrect values.

I have three hard drives, the first one is a SATA drive for Windows XP, the second is a SATA drive for Ubuntu, and the third is an extra IDE drive for my music files.

When a new kernel is installed and it updates my menu.lst file, it changes the hard drive part of the kernel line to "hd2,0" instead of the correct "hd1,0". After the kernel is updated, I go in and correct this in the menu.lst manually and it works fine, but if I ever forget to correct it and I reboot, it won't find the partition to boot from. (In that case, I press "e" to edit the kernel line in the grub menu to make it boot).

Even worse, if I install a fresh copy of Ubuntu hardy on my machine, after the installation finishes, it won't boot because it created a menu.lst file with the incorrect values by default.

This is a pretty serious bug at least to me, so I'm nominating it for release.

[Evan (ev)]

Please read the full warning in the menu.lst about the automagic section. You want to modify the groot line, not the individual entries. At any rate, this appears to be a duplicate of bug 8497, so I'm marking it as such.

[Jeremy LaCroix (jlacroix82-deactivatedaccount)]

Asking the user to modify the groot line is not a good idea either, the
script that installs Ubuntu should be smart enough to do this without
requiring user input.

On Thu, Apr 3, 2008 at 3:31 PM, Evan Dandrea <email address hidden> wrote:

> *** This bug is a duplicate of bug 8497 ***
> https://bugs.launchpad.net/bugs/8497
>
> Please read the full warning in the menu.lst about the automagic
> section. You want to modify the groot line, not the individual entries.
> At any rate, this appears to be a duplicate of bug 8497, so I'm marking
> it as such.
>
> ** This bug has been marked a duplicate of bug 8497
> grub guessed BIOS disk order incorrectly
>
> --
> When my kernel is updated, my system will not boot.
> https://bugs.launchpad.net/bugs/211455
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jeremy LaCroix (jlacroix82-deactivatedaccount)]

Also, marking this as a duplicate of that bug is not a good idea, because
that particular bug was fixed, this one was not.

On Thu, Apr 3, 2008 at 3:31 PM, Evan Dandrea <email address hidden> wrote:

> *** This bug is a duplicate of bug 8497 ***
> https://bugs.launchpad.net/bugs/8497
>
> Please read the full warning in the menu.lst about the automagic
> section. You want to modify the groot line, not the individual entries.
> At any rate, this appears to be a duplicate of bug 8497, so I'm marking
> it as such.
>
> ** This bug has been marked a duplicate of bug 8497
> grub guessed BIOS disk order incorrectly
>
> --
> When my kernel is updated, my system will not boot.
> https://bugs.launchpad.net/bugs/211455
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Evan (ev)]

Please note that the fix was *just* released and was not on the CD you tested with, nor do I imagine you enabled it. From the comments on bug 8497:

"I now have a grub patch that I think shuffles the devices around appropriately provided that you boot with edd=on, provided that EDD works on your hardware, and provided that the MBR signatures exposed by EDD are distinct - pretty much the same conditions as in SuSE. We can't make this the default, I don't think, but we can make it fairly easy (i.e. accessible from the CD boot menu, documented in release notes, and such) for people to use it if grub's normal autodetection gets it wrong."

Regarding the groot line, you modified your menu.lst in a manner that gave results that were explained in the very same file would occur. I was merely trying to point you at this documentation so you had an understanding of why this seemingly random result was occurring.

[Jeremy LaCroix (jlacroix82-deactivatedaccount)]

I respect your input, however I have to disagree. This problem happened
today, just a few hours ago. The problem with the CD having this problem by
default was from a CD I burned a few weeks ago, and I had my current install
since. This problem happened today after this package was updated. I didn't
update my menu.lst until after this bug manifested itself again.

On Thu, Apr 3, 2008 at 4:12 PM, Evan Dandrea <email address hidden> wrote:

> *** This bug is a duplicate of bug 8497 ***
> https://bugs.launchpad.net/bugs/8497
>
> Please note that the fix was *just* released and was not on the CD you
> tested with, nor do I imagine you enabled it. From the comments on bug
> 8497:
>
> "I now have a grub patch that I think shuffles the devices around
> appropriately provided that you boot with edd=on, provided that EDD
> works on your hardware, and provided that the MBR signatures exposed by
> EDD are distinct - pretty much the same conditions as in SuSE. We can't
> make this the default, I don't think, but we can make it fairly easy
> (i.e. accessible from the CD boot menu, documented in release notes, and
> such) for people to use it if grub's normal autodetection gets it
> wrong."
>
> Regarding the groot line, you modified your menu.lst in a manner that
> gave results that were explained in the very same file would occur. I
> was merely trying to point you at this documentation so you had an
> understanding of why this seemingly random result was occurring.
>
> --
> When my kernel is updated, my system will not boot.
> https://bugs.launchpad.net/bugs/211455
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[John Gelm (jgelm)]

This bug is NOT a duplicate.

I would like to concur with Jeremy LaCroix in that kernel updates should not be changing (hdx,y) values when adding a new kernel. I am inserting my log of setting up a system with mixed pata/sata.

My question is "Will the kernel update honor the contents of my device.map file or will it ERRONEOUSLY do a BIOS probe and screw up my Windows disk?".

==============================================
 I am setting up a mixed IDE/SATA system. There will be three disks, IDE0 is 100% Windows, SATA0 is 100% U8.04, SATA1 is 100% U7.04. I am setting this up with SATA0 as the BIOS boot drive with a menu.list to choose from. The menu.list specifies (hd0) as boot.

First I set up the SATA drives.
Here is the status after setting up with just the two sata disks and booted into SATA0:

root@voyager:# cd /boot/grub
root@voyager:/boot/grub# cat device.map
(hd0) /dev/sda
(hd1) /dev/sdb
...and all is good to go.

After adding the IDE0 disk, the SATA drives are changed to:

root@voyager:/boot/grub# fdisk -l|grep Disk
Disk /dev/sda: 120.0 GB, 120034123776 bytes <---------IDE0 100% Windows
Disk identifier: 0xc8e067c5
Disk /dev/sdb: 500.1 GB, 500107862016 bytes <---------SATA0 U8.04 BIOS boot drive, was sda
Disk identifier: 0x94759475
Disk /dev/sdc: 500.1 GB, 500107862016 bytes <---------SATA1 U7.04 , was sdb
Disk identifier: 0x00027610
root@voyager:/boot/grub#

...I modified U8.04 device.map

root@voyager:/boot/grub# cat device.map
#@# per fdisk -l and hardware: ide0=sda Windows, sata0=sdb U8.04, sata1=sdc U7.04
#@# the boot/root drive in menu.list is hd0=sata0=sdb U8.04
(hd2) /dev/sda
(hd0) /dev/sdb
(hd1) /dev/sdc
root@voyager:/boot/grub#

The hope is that when there is a kernel upgrade, that the device.map file will control which disk's MBR gets updated. I would like for the update to be applied to (hd0)=sata0=sdb, not IDE0.

Let's see what happens if I go:
root@voyager:/boot/grub# grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> root (hd0,0)
root (hd0,0)
grub> setup (hd0)
setup (hd0)

Error 17: Cannot mount selected partition
grub> find /boot/grub/stage1
find /boot/grub/stage1
 (hd1,0)
 (hd2,0)
grub>

BULLBUTTER!!!!!!!!!!!!!!!!!

Why is grub IGNORING my device.map? Clearly I have mapped (hd0) /dev/sdb. It is obvious to me that grub is looking at (hd0) as /dev/sda. grrrrr!

To continue, I quit grub and rename device.map, and then run grub again:
root@voyager:/boot/grub# grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub>

....and then it hits me like a brick. Grub is probing BIOS! grrrrr! There is no complaint about the non-existing device.map.

Why doesn't grub report the results of the BIOS probe?
Why is ther...

[John Gelm (jgelm)]

BTW, the randomizing continues as of 2008-09-20.

https://bugs.launchpad.net/ubuntu/+source/grub/+bug/8497/comments/88

HTH;
John