I have an old server with five hard drives, some of which are SATA other Ultra 
IDE.  The machine has two controllers.  One is the primary controller where a 
SATA drive is clearly flagged as the primary boot device.  The other four 
drives (two SATA, two Ultra IDE) are on the other controller, connected in a 
RAID5 (/dev/md0).

I had some problems installing Hardy Beta on this machine when my manual
partitioning efforts wrote GRUB to a partition which the machine would
not boot from (I have not yet determined whether I consider this a bug
or operator error), but it is unrelated to the bug I am commenting on
here.  Suffice it to say that as part of fixing this problem I
discovered that menu.lst contained a reference to a root partition on
(hd4,1).   The correct reference would be (hd0,1).   Note that I do not
know whether this faulty menu.lst was created as part of the
installation process or the subsequent dist-upgrade.

So let me get to the point.  This morning I was notified that there were
several updates to Hardy Beta.  As part of installing these updates I
was alerted that debconf wanted to replace my menu.lst and asked me
whether I wanted to keep the installed version or replace it with the
package maintainers version.  I opted for the latter but decided to
investigate.

It turned out that the root reference had been changed back to (hd4,1).
As I am not a very experienced grub admin I decided to check what grub
considered the right partition.  So I entered the grub shell and gave
the command "find /boot/grub/stage1" and got the response (hd0,1).  So I
changed menu.lst, leaving both choices:

title           Ubuntu hardy (development branch), kernel 2.6.24-16-generic
root            (hd0,1)
kernel          /boot/vmlinuz-2.6.24-16-generic 
root=UUID=46a05d8c-6d30-4176-88c6-2c4a829de775 ro quiet splash
initrd          /boot/initrd.img-2.6.24-16-generic
quiet

and

title           Ubuntu hardy (development branch), kernel 2.6.24-16-generic
root            (hd4,1)
kernel          /boot/vmlinuz-2.6.24-16-generic 
root=UUID=46a05d8c-6d30-4176-88c6-2c4a829de775 ro quiet splash
initrd          /boot/initrd.img-2.6.24-16-generic
quiet

When I booted the machine, I found that it would only boot from the
(hd0,1) option, as expected.  In other words, the update would have left
my machine in an unbootable state.  I believe this is the topic of this
bug and I offer my assistance in tracking this down with experiments
like these.

I should add an observation, in case it matters.  I have noticed strange
SCSI id assignments on this machine.  Sometimes the disk which I
consider the primary disk is labeled /dev/sda and sometimes it is
labeled /dev/sde.   This seems to be totally random and can change on
two subsequent boots.  This does not seem to bother anything (I worried
that mdadm might be thrown for a loop) but the UUID system seems to take
care of this (I wish I understood how).  I mention this because this
/dev/sda vs. /dev/sde confusion smells a lot like a (hd0) vs. (hd4)
confusion.

Hope this helps.

  Gisli

PS: I have taken the liberty of adding "(and dist-upgrade)" to the
Subject:, which I hope is not a launchpad faux pas.

-- 
upon installation the GRUB menu.lst file is generated wrong
https://bugs.launchpad.net/bugs/127946
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to