upon installation the GRUB menu.lst file is generated wrong

hi,

maybe the solution to the numbering problem is to upgrade to Grub 2 instead of keeping to use the legacy grub...

it looks like the grub people put serious effort into making it better...

http://www.gnu.org/software/grub/grub-2.en.html

greets

I also had this problem. I don't have the log files from the install unfortunately,
but I can fire up the live cd and grab the output of any commands if required.

Thanks,

James

Hi,

I have had an idea of a possible cause for this issue.

I am installing with root on the second hard drive as the bios sees it (PATA).
This is also where I install the MBR. I have the bios set to boot from the
second disk first.

It is possible that the cause of this bug for me is a difference in how the
bios, bootloader and ubiquity see the hard drive layout.

Thanks,

James

I see this issue with Gusty, Hardy and other distros. Similar to the original poster, my configuration for testing is:

  Internal HDD: Not for Linux (yet)
  External USB HDD: Install to here

Boot from the LiveCD/DVD. The internal drive is considered hd0, the external drive is hd1. IMPORTANT CAVEAT: you must use the advanced button to tell the installer to put the boot loader on hd1. It silently defaults to wiping out the boot sector on hd0, even though you've not asked it to touch hd0. That will infuriate a lot of unsuspecting users, and really needs to be fixed.

In any event, after booting, you can use the grub option to edit the boot line, and fix it from the hd1 that the drive was during install, to the hd0 that the boot drive becomes. Yes, same drive, the hd<x> assignment changes. That's the behavior. So you then edit menu.lst to fix all hd1 references to hd0 (including the commented out one that is the default, else the next kernel update will put you right back in the same situation), and either remove or correct any previously existing hd0 references (to the internal drive, which would have been hd0 during installation).

I've been doing installs to USB every few weeks (the Ubuntu test build release cycle), and am quite used to it, but this really should be fixed (both the drive assignment *and* the blowing away of the internal drive's boot sector without warning).

Triaged to Confirmed. GRUB can get confused about drive and partition assignments.

I have this problem too. Every update or "grub-install" command can broke my menu.lst .

Can also confirm. Appears to be an issue with numbering when drives are of different types- in my case, the BIOS considers the SATA devices first, while grub apparently considers the PATA devices first. Actually, worse than that- with my SCSI devices also on, those apparently get considered before either SATA or PATA, even though they are considered last by the BIOS.

Occurs with 7.10 and 8.04 Beta that I've tried.

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.

GRUB in 8.10 now uses UUIDs to specify the location of the root, rather than the hd0-9 format. In addition to this, the installer has several fixes for installing from a removable disk or USB drive. I am therefor marking this as fixed and requesting that you open new bug reports for any further issues you may have.