Executing 'grub-install (hd0)' failed (due to divergency of partition type and filesystem type)

[Henning Moll]

Binary package hint: ubiquity

There are several bug reports for this summary, but i was not able to find one, which is describing this problem. So here's a new one...

Here's how to reproduce it in a vmware:

1. crate a new vmware vm: typical, linux, ubuntu (8GB harddrive)
2. boot 704-desktop-386-cd within that vm
3. use gparted to set disklabel msdos and create a ext3 primary partition (whole device). (Note: by specifiying 'ext3', the partition gets formated and the partition type is set to 0x83
4. quit gparted.

Use fdisk for the following steps. The problem won't occour, if you use gparted for the following steps...

5. delete the partition from step 3.
6. create a new primary partition in "partition slot" 1. It is very important, that the new partition starts on excatly the same position as the deleted partition! Some space should be left behind for a smaller second primary partition (swap). For the first partition set the partiton type fat16 (0x06). Create the second primary partiton on the remaining free space and assign partition type 0x82
7. write partition table and quit fdisk (unmount, if the first primary partition is now automatically mounted...)
8. start the installer, and choose 'manual' in the 'prepare disk space' dialog.
9. Select first primary partition and click 'Edit partition'. Change the mountpoint to '/'. (Use 'go back' if you are asked for 'resizing'). Note, that 'format' is not automatically checked. So do it manually. Use seconde partition as swap. Now continue with installation.

At about 94 percent of the installation, the installer fails to install grub. Grub is not able to dump stage1 on first primary partiton, because it assumes the wrong filesystem type...

Can this happen in 'real life'? Yes ;-) I had a unused harddrive containing two ext3 formated primary partitions. I installed Windows XP on the first primary. After installation i used the partitioning tool which is part of windows (sorry, don't now the exact english name) to delete the second partition and create two _unformatted_ primarys in the free space. Windows set fat16 for these partitions...

So in my opinion the problem is, that ubiquity does not verify/correct the partiton type in the partition table. It detects a ext3 filesystem (which is a relict of an allready deleted partition) and is happy. Later on, grub fails because of the misleading partition type 'fat16'.

In addition, ubiquity should always format the partition which is assinged to '/' (the checkbox 'format' was not checked by default in the above case).

[sam tygier (samtygier)]

i think i am seeing the same problem.

grub install failed with the installer (minimal install) so i chose to install lilo instead. now i am trying to switch to grub.

grub-install gives to error
The file /boot/grub/stage1 not read correctly

my hda just has one ext3 partition. but now i have checked and fdisk -l thinks that it is FAT16

is there a safe way to change the partition type?

[sam tygier (samtygier)]

these look similar
Bug #136698
Bug #13390

[sam tygier (samtygier)]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292724 also seems to be the same problem.

i am not sure what this should be filed against?
the debian installer seems to make it possible to make a partition with the wong type label.
grub-install gives a rubbish error message

[sam tygier (samtygier)]

i used fdisk to fix the partition type (using the 't' command and set it to 83). then grub-install worked. on rebooting grub loaded :-)

[Fabien Crespel (fabien-crespel)]

This bug still occurs in Ubuntu 8.04 Hardy Heron.

In my case, I had a NTFS partition on my second hard drive (on /dev/sdb5) that I wanted to use for Ubuntu.
During the installation I chose manual partition configuration, where I selected the NTFS partition and formatted it with ext3 and / as the mount point.

The installation failed at 94% with "Execution of grub-install (hd0) failed" and grub wouldn't boot.
In fact, the partition type was still 0x7 (NTFS) instead of 0x83, so grub couldn't find the files. I reformatted the partition using openSUSE 10.3, reinstalled and now it works.

So I can confirm the installer still doesn't change the partition type, only the file system. This is quite a major bug, in my opinion.

[Hooya (tjbassoon)]

I have this issue with Xubuntu 8.04. I haven't tested it with the Ubuntu disk. Only I get no error messages, I just don't get prompted to restart the system, it simply exits the installer and leaves me at the Live CD desktop. Then when I reboot I get Grub Error 15. I built the Grub installation manually (copying the files or creating them) to boot into the system, but the system won't let me log in and has the wrong machine name and time zone.

This is pretty critical if you ask me. It makes the manual partitioning worthless.

[Henning Moll (drscott)]

> debbugs #292724 => Fix released

i can't see that there is really a fix released for that problem, it just says "Closing your installation report". In my opinion the problem was not solved by a fix, but by manually manipulation of the reporter's system.
Should that bug be reopened?
Actually, there is no fix for that problem.

[Carl Lehmann (herrlehmann)]

Hi folks,

the referred bug#292724 on the debian site was "fixed" in 2005 ... so obviously its not our bug they fixed:
to me the pb happened when trying to install UbuntuStudio 8.04.1 (uses the alternate installer) on my Acer Aspire 5930G.
My Steps: -resized the partition using the RescueCD/Gparted.
- booting installation from the named UbuntuCD
- choose to partition manually
- selecting SDA3 to be reformatted to Ext3 and mounted as root. (was a primary NTFS partition).
- when selected to write grub to boot block sda3 the reported error massage came.
After runnung mad for two days or so I realized that the installer didn't changed the partition type to 83. I could install LILO without being affected by the wrong partition type.
Seams to be a small bug with big consequences especially to newbies.
Should be easy to fix it?!

[Colin Watson (cjwatson)]

Thanks for all your reports. This is bug 149832, finally fixed in Intrepid.