GRUB won't install on / partition

What filesystem is on partition 3?

(In reply to comment #1)
> What filesystem is on partition 3?

ReiserFS

(In reply to comment #2)
> (In reply to comment #1)
> > What filesystem is on partition 3?
>
> ReiserFS

This might be the same bug I stumbled upon in Hoary Array CD 4, which was a
regression from Array CD 3. In Array CD 3 I could change all of the partitions
to ReiserFS and install GRUB from the installer, but in Array CD 4 I had to
revert to ext3 on the / partition to get past the GRUB instalation stage. LILO
couldn't install on ReiserFS as well, though.o

Below is my clarification from the ubuntu-devel mailing list, as it seems
inaccessible at the archives
(http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004121.html):

With Array CD 3, I booted with server-expert and in the partition stage
I chose multiuser workstation. This resulted in a couple partitions,
all of them (except swap) set to ext3. I changed them to ReiserFS and
installed the system without a problem.

With Array CD 4, the same course resulted in a "GRUB cannot be
installed, continue?"-kind of error in the bootloader installation
stage (even before trying to put GRUB in the MBR). The same happened
when I tried installing LILO.

When I went back to the partitioning stage and changed the partition
with the / mount point to ext3 (and left all of the rest at ReiserFS)
GRUB installed without a problem and made its way to MBR flawlessly.

Currently, the /etc/fstab looks like this:

shot@albert:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
/dev/hda9 /home reiserfs defaults 0 2
/dev/hda8 /tmp reiserfs defaults 0 2
/dev/hda5 /usr reiserfs defaults 0 2
/dev/hda6 /var reiserfs defaults 0 2
/dev/hda7 none swap sw 0 0
/dev/hdb /media/cdrom0 udf,iso9660 ro,user,noauto 0 0

Does this problem still occur in Breezy or Dapper?

No response closing

I believe this was actually a duplicate of bug 185878, which I recently (finally!) fixed. I'll mark this as such for the sake of exactness.