For the past several months, our support forums have been plagued on and off with a number of weird and inexplicable failed attempts at installing Ubuntu by many users. We’ve finally pinned down the cause of the problem, and it isn’t pretty. Ubuntu (ever since version 5.04 Hoary Hedgehog) will not install properly on a filesystem other than ext2fs or ext3fs.
Unfortunately if you attempt to install Ubuntu with the “/” partition formatted as ReiserFS, JFS, XFS or any other non-standard filesystem, Ubuntu installation will begin like normal and tick merrily along its way until it attempts to install GRUB. At that point, you’ll get a fairly inexplicable and non-verbose “fatal error” message about “grub-install()” failing.
We finally managed to pin down the error thanks to a user at Ubuntu Forums who pointed out that our dual-boot instructions worked alright when using ext3fs instead of our recommended ReiserFS (for speed, size, and performance). In an attempt to reproduce and pin down the error, we dropped down to the console when the “fatal error” message was given, and found out that grub-install was not recognizing the non-ext3fs partition.
Basically, Ubuntu’s copy of grub-install is not configured to write to anything other than ext3fs during setup, and attempts to install GRUB when the /boot/ folder is on a ReiserFS partition and GRUB is to be written to the bootsector were failing. This issue manifests itself in all releases since (and including) Hoary Hedgehog (5.04); including the most recent Ubuntu Feisty Fawn (7.04) and Ubuntu Gutsy Gibbon (7.10) releases.
Unfortunately this has been a (little-) known issue ever since March of 2005, but no one has bothered to fix it since. Every once in a while someone “bumps” the bug and confirms that it’s still present, but it hasn’t yet been addressed or even assigned.
We’re not exactly sure what the Ubuntu dev team is waiting for, but this is a rather important issue that needs to be addressed as soon as possible, in our opinion. Other Linux distros like Fedora and SUSE Linux do not exhibit this problem.
Related Bug Reports on Launchpad.net
- grub-install fails for JFS root partition (Mar. 2005)
- grub-install failing in Ubuntu setup (Jan. 2008)
- GRUB Installation Fails if non-ext3 Root Partition (Jan. 2008)
Yep. Hit this yesterday following your how-to. I was pulling my hair out trying to use ReiserFS until I decided to give ext3 a go and it worked perfectly. Seems kinda weird that no devs have fixed this seemingly easy-to-fix bug.
As long as /boot is ext2 or ext3 then the root partition can be whatever your kernel can support.
Yes, but /boot/ should not have to be ext3fs in the first place.
I ran into this issue recently when attempting to use the alternate installer to install Ubuntu to an encrypted root partition on a RAID 1 array. The boot partition was a regular RAID 1 with ext3fs, but presumably because the partition is marked as “raid-auto”, it failed.
Installing grub manually from the live CD worked fine.
This is not just Ubuntu, it has always been the case that if you want to use another file system then you create a /boot partition in ext2 or ext3. I have five machines using XFS except for /boot and they all function flawlessly. It would be nice to be able just use xfs, but it is sensible to have /boot, / and /home as separate partitons – it makes upgrades safer.
I don’t know if this problem also applies only to Ubuntu, because I’ve got Kubuntu installed in two machines, using ReiserFS, and have had no problems. Any feedback on this?
I have my Gentoo running on only ReiserFS on one machine, and Ubuntu on another. For Ubuntu, I expreinced the problem here with grub installation failing, and had to manuallly install it to the HD.
This is a real problem.
Why do you need a journal file system for /boot anyway? Just use ext2, it’s better for this purpose and works on all grubs and all distros.
If you only have a single Linux installation on your disk, there is no reason to create a separate /boot/ partition *normally* and it shouldn’t be a requirement to get Ubuntu installed….
But, yes, it is a valid workaround for this issue.
As a ‘work-around’, I find that the target partition must be marked for formatting during the install (even to the same type, etx2, in my case and even if it has been freshly formatted with, say PQMagic).
Obviously, a re-installation, where any non-system files are hoped to be retained, will fail, so not really an acceptable work-around.