wrong UUID in menu.lst after upgrade to hardy

[dorpm]

Binary package hint: grub

After upgrading to Hardy I found in /boot/grub/menu.lst new and wrong UUIDs so that the computer was not able to start. After changing them to the former ones booting suceeded as expected.

Please let me know ff any more information is needed.

Florian

[Marcel Schaap (mschaap)]

I can confirm that this happens. Dell D610 Latitude Laptop with Seagate 256 GB drive

In my case
* the new "root hd(0,7)" entry should have been "root hd(0,0)"
* The UUID entry in the new menu.lst is wrong. It is actually not one of the UUIDs of any of my three partitions (root,swap,home).

Of note is that hd(0,7) does not even exist on my system!
It is interesting to note that ALL "root" and UUID in menu.lst are changed, even the previously working ones. Thus there is no fallback to an older kernel.
This problem occurred with the most recent Kernel upgrade (2.6.24-16 -> 2.6.24-17), but I also had this problem occur when upgrading from 7.10 to 8.04 in the end of April.

The upgrade does detect that there is something "funny" about my menu.lst. In this case, I chose the "package maintainers version".

POSSIBLE CAUSE (I am not sure): A few months ago I moved an existing 7.10 install from a 80 GB Fujitsu drive to my current 256 GB drive. The transfer was a little hairy, but everything worked as before, including upgrading packages.
So, does the old disk layout ("root" and "UUID" entries) still live somewhere on my system? If so, why and where?
If the above is true, then similar problems should occur is somebody would 1) install "ghosted" images on multiple systems, 2) install a system backup after a failed drive.

Expected behavior:
* upgrade should not touch existing entries in menu.lst
* upgrade should use correct drive UUID and check whether such partitions actually exist.

[Marcel Schaap (mschaap)]

Adding to my previous comment: after executing

"grep -r UUID /etc"

it appears that the old UUIDs still live in /etc/blkid.tab

Does grub rely on these entries? They seem to be unreliable, or at least should be rechecked when adding entries.

Marcel

[Tvrtko Ursulin (tvrtko)]

I had the same problem with an additional twist.

My /etc/blkid.tab also contained the old UUID's so I either a) deleted it and it got regenerated, or b) edited it to contain correct ones (don't actually remember). But it is not important, important is that I now just updated to 2.6.24-18 and installed package maintainers menu.lst and there are still wrong UUID's there. I don't know from where does it get those.. they are nowhere to be found in /etc any more so it is a mystery to me.

Hm.. and I also migrated 7.10 to a new disk without reinstalling and then upgraded to 8.04 before all this happened.

[Marcel Schaap (mschaap)]

I had the problem re-occur with todays upgrade to 2.4.16.18. despite the fact /etc/blkid.tab had the correct entries. This led me to investigate the matter in more detail. I think I SOLVED it as a non-bug.

Here is what I found

I noticed that the "kopt" and "groot" options in my /boot/grub/menu.lst still had the invalid "hd" and "UUID" options. (The fact that a "#" appears at the beginning does not mean that these are commented out. Apparently you need a "##" for comments)

relevant diff:

< # kopt=root=UUID=11364fdf-db87-4d3c-a385-0d710cba8a8f ro //correct
---
> # kopt=root=UUID=824f1f6c-3d18-4cac-84b3-12d3a5867e4c ro // incorrect
74c74
< # groot=(hd0,0) //correct
---
> # groot=(hd0,7) // incorrect

Simply deleting menu.lst and running update-grub will generate a new menu.lst with the correct "kopt" and "groot" options.
Please note that you probably will want to edit the new menu.lst.

An pre-existing menu.lst with the INCORRECT kopt and kgroot options will trigger the reported problems.
and a menu.lst with CORRECT options behaves as expected.

In my case, I should have modified/deleted menu.lst after transferring the system from one HD to the other.

I therefore think this is NOT A BUG and suggest closing this bug report.

[Steve Langasek (vorlon)]

Hi Marcel,

Yes, you are correct; if after a kernel upgrade in hardy you have the wrong UUID in your boot config, then two things must be true here:
- the wrong UUID is present in the kopt line in menu.lst
- the user must have overidden the default choice when prompted during the upgrade, and chosen to use the config autogenerated by the system instead of the one preserving the local changes to the boot options

As you noted, both of these applied in your case, and I believe this also applies in the case of the original submitter.

Ideally, it would be great if we could magically detect when the wrong UUID is used and automatically fix everything up, but that's simply not feasible here; so I'm closing this bug as 'wontfix'.