Unexplainable GRUB behavior after switching HDD

Pater · 07-26-2009, 12:06 AM

Hi.

I encountered today an issue with GRUB that I found no way to explain.

First of all, I'm talking about my laptop (Acer Aspire 5633WLMi). I say this because I'm suspecting about a BIOS issue and this machine has a crippled BIOS setup program (as any other laptop I guess), so I can't play much with it.

Well. Here is the story. It is long, so I warn you before you start reading:

The laptop had a 320Gb HDD. Yesterday I bought a 500Gb HDD and installed it today on my laptop. The partition layout of the old 320Gb HDD was like this:

/dev/sda1 (20 GB) - Windows XP <primary partition>
/dev/sda2 (20 GB) - Debian (Lenny then Squeeze) <primary partition>
/dev/sda3 (15 GB) - FreeBSD <primary partition>
<extended partition>
/dev/sda5 (2 GB) - Linux swap
/dev/rest-of-the-disk - <whatever>

I usually avoid installing GRUB in the MBR of the disk and install it instead in the Linux partition just in case I have to reinstall Windows, so GRUB was installed in /dev/sda2 and everything was working nicely. This way I just have to activate /dev/sda2 if I reinstall Windows and I don't have to reinstall GRUB again.

I just wanted the same layout on the new HDD, so I partitioned it like this:

/dev/sda1 (30 GB) - Windows XP <primary partition>
/dev/sda2 (20 GB) - Debian <primary partition>
<extended partition>
/dev/sda5 (2 GB) - Linux swap
/dev/rest-of-the-disk - <whatever>

As you can see, the only changes I did were:

a) Bigger Windows partition.
b) No FreeBSD partition (I planned to add it after I had Debian running).

I use disk imaging tools, so I restored my Windows partition from my Acronis image and my Debian partition from my partimage image. Partimage saves and restores the boot sector of the partition, so it was a matter of restoring from it and activating /dev/sda2 as I did zillions of times in the past with no issues.

I did so and rebooted. Then, instead of the GRUB menu, I just got a blinking cursor in the top left corner of the screen that stays there forever (I waited 5 minutes because I thought it was a delay).

No errors, no text, no nothing. GRUB was simply not loading.

I proceeded then to install GRUB again. Partimage could have messed it, so I installed GRUB to /dev/sda2 and... blinking cursor.

I then went desperate. Activated /dev/sda1 and Windows booted correctly. Took Super GRUB disk and told it to boot /dev/sda2 from it and Debian was booting fine.

I thought I was hitting a disk cylinder issue and that GRUB was not able to boot partitions beyond a certain disk cylinder.

I resized Windows partition to 20 GB (as I had in the old HDD) and moved the Linux partition next to it. Activated /dev/sda2 and... blinking cursor. I was not hitting any cylinder limit then...

I simply don't understand what is happening. Same HDD layout, same computer, and GRUB doesn't load in the new disk. WTF?

I finally surrendered and installed GRUB in the MBR of the disk. Now GRUB shows and works nicely, but I must now what was happening.

Why doesn't GRUB load in the new HDD?

jay73 · 07-26-2009, 12:17 AM

I don't think it's the old cylinder limitation; if it were, even 20GB would be too much (I believe the limits was something like 8GB).

Don't know what is happening there. I have noticed, though, that GRUB is frequently a stumbling block when restoring/copying partitions. I imagine that could be because GRUB stores information about the location of the files it needs; if you change your physical layout, that kind of information would become inaccurate. A re-install should take care of it but, well, maybe GRUB is only partly reinstalled if bits left over from a previous install are found.

Pater · 07-26-2009, 12:30 AM

Quote:

Originally Posted by jay73

I don't think it's the old cylinder limitation; if it were, even 20GB would be too much (I believe the limits was something like 8GB).

Don't know what is happening there. I have noticed, though, that GRUB is frequently a stumbling block when restoring/copying partitions. I imagine that could be because GRUB stores information about the location of the files it needs; if you change your physical layout, that kind of information would become inaccurate. A re-install should take care of it but, well, maybe GRUB is only partly reinstalled if bits left over from a previous install are found.

Damn, this is interesting. I forgot to mention in the first post that I did also a completely clean Debian installation (formatting both /dev/sda2 and /dev/sda5).

¿Is there a chance of leftover bits in the boot sector of /dev/sda2 after formatting? In such case you might be right. ¿How can I get rid of them then?

jay73 · 07-26-2009, 12:44 AM

That would be unlikely. I was assuming you had simply restored an existing install. Then again, I remember having a drive acting weird after BIOS was corrupted; the only way to make it behave again was zeroing the MBR before doing anything else (although I had already formatted the drive many times over in an attempt to restore it back to working order).

Pater · 07-27-2009, 04:48 AM

Quote:

Originally Posted by jay73

Then again, I remember having a drive acting weird after BIOS was corrupted; the only way to make it behave again was zeroing the MBR before doing anything else (although I had already formatted the drive many times over in an attempt to restore it back to working order).

I suspect about a BIOS issue. Not exactly corruption but a sort of limitation.

The laptop had originally a 120 Gb HDD, although there was a 160 Gb variant available. When I replaced the HDD with the 320 Gb one, all was working as expected, but maybe the BIOS has issues with drives as big as 500 Gb.

Is there a chance of such a limitation?

On the other hand, the whole drive capacity is recognised and useable. That makes me think about a GRUB issue.

This is mysterious to me.

dxangel · 07-27-2009, 07:11 AM

im guessing that the grub wasnt resored correctly.

If you can boot to your original configuration with the new drive plugged in you can copy grub across to the new drive or perhaps boot to rescue mode off a CD and run the following:

Code:

run 'grub' from the command line

device (hd0) /dev/sdb
root (hd0)
setup (hd0)

obviously changing sda1 and sdb1 as required.

ETA: after thinking more about your problem, i am pretty sure a boot to rescue disk and running grub on the cmdline with the options above should fix your problem.

Pater · 07-27-2009, 09:09 AM

Quote:

Originally Posted by dxangel

im guessing that the grub wasnt resored correctly.

If you can boot to your original configuration with the new drive plugged in you can copy grub across to the new drive or perhaps boot to rescue mode off a CD and run the following:

Code:

run 'grub' from the command line

device (hd0) /dev/sdb
root (hd0)
setup (hd0)

obviously changing sda1 and sdb1 as required.

ETA: after thinking more about your problem, i am pretty sure a boot to rescue disk and running grub on the cmdline with the options above should fix your problem.

I did so. I did it first by chrooting in this drive (from Sysrescuecd). This didn't work, and I booted that partition (with Super GRUB Disk) and installed grub again in that Debian installation.

I even did a fresh Debian installation (latest Squeeze iso) and the damn GRUB menu doesn't show if it is installed in /dev/sda2, even after a clean install.

The command line you wrote would install GRUB to the MBR in hd0. That's what I did and this is working nicely, but I can't still figure out why GRUB refuses to load in that disk if not installed in the MBR.