Description of problem: As ext4 is now the default filesystem, it would be the nicest solution if /boot was also capable of using this. A patch can be found below taken from the Ubuntu grub package to add this capability: http://launchpadlibrarian.net/20944879/grub_ext4.diff
Just converted my /boot to ext4, and rebooted fine.
*** Bug 446276 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Just converted my /boot to ext4, and rebooted fine. How did you accomplish this? If it was by a simple remounting as ext4, then the file on-disk is still using the ext3-format bitmap, and not the ext4-style extents. It is this on-disk extent support which GRUB cannot handle at this time, and what the proposed patch accomplishes. When remounting an ext3 filesystem as ext4, only newly-created files use this extent support.
For reference, I have succesfully installed a Ubuntu Jaunty Alpha 5 on full ext4 setup. This is the very patch they use to provide this functionality.
Steps taken: tune2fs -O extents,uninit_bg,dir_index /dev/DEV fsck -pf /dev/DEV edited fstab.
(In reply to comment #5) > Steps taken: > > tune2fs -O extents,uninit_bg,dir_index /dev/DEV > > fsck -pf /dev/DEV > > edited fstab. According to the e2fsck manual page, this only forcibly repairs the filesystem; but does not change it if it is already intact. In order to verify that ext4 (extents) support is functional, you would need to recreate the necessary files in /boot with extents enabled. For example, copy - not move - the files and rename them to replace the old ones. If you do this you will likely not be able to boot without this patch in Grub. (I for one, have had quite difficulty with this in my rawhide VM.)
Created attachment 337317 [details] proposed patch Here's the patch from the Google SoC project, also an srpm at http://sandeen.fedorapeople.org/grub-0.97-43.fc11.ext4.src.rpm for anyone who would like to test it. Thanks, -Eric
It work, but I have to patch anaconda to enable boot from ext4.
Is there any hope that is merged in rawhide? What will happen when all the new users install f11 with ext4 as default and grub not supporting it? Maybe this is not the most important issue but will be a problem.
It may hit rawhide but unlikely to hit F11. It should not be a problem; it does require a separate non-ext4 /boot, but you get separate /boot by default anyway with a default lvm install... It would have been great to get this in around alpha, but there were other more pressing matters and it didn't happen. The only minor annoyance is the requirement for separate /boot even when you aren't using lvm for /. It's not great, but we can live with it I think. Thanks, -Eric
And what you think about this. Anaconda by default does not allow to boot from ext4. So maybe it is possible to include this patch to grub? Manually people could install grub onto ext4 but they could not do it during installation.
It's too late for this for F11, but we can put it into rawhide now (or soon) for testing.
I feel this should be on the short list of things that need to be fixed before F11 release. The following problem arises: * F11 cannot boot ext4 filesystems. * The F11 Live media will only install with / formatted ext4. * There is no way to install the Fedora 11 live media without using LVM or having a separate boot. The only way to install Fedora 11 without LVM or a separate /boot is to use the DVD and select ext3. I've got nothing against ext3, but I was hoping to not have to download the full DVD to do a basic install. I'm sure there are many people who do not use LVM, and do not have a separate /boot. Doesn't seem like a very well thought out approach to ext4 adoption to me.
See comment #12; it's too late for F11; it's somewhat unfortunate I agree, but other things took priority. An ext4-capable grub should be in rawhide reasonably soon I hope; if you feel very strongly about not having a separate /boot, put it at the end of your disk for now, upgrade grub when ext4 capability is done, move /boot onto the root, and lose the separate partition... it's not pretty, but you can get there.
How is it too late? There are still a few days left for late tagging for critical issues like this.
If the concern is stability, the patch I attached when I reported this months ago is the same that ships in Ubuntus latest release. They have not had any bugs in that time using this and there are thousands of people using it every day. That is months of testing and one very large scale deployment.
David, I have no idea how many people are actually installing Jaunty on ext4, and based on the approximately 0 patches contributed from Ubuntu devs to either ext4 kernelspace or userspace, you'll have to forgive my not accepting "But it's in Jaunty!" as sufficient reason to merge it now. Guys I am really sorry this didn't make it, but - it didn't make it. I expect we'll have a grub update at some point in F11 if people just can't stand their ext3 /boot and absolutely must migrate off it. David, I do appreciate your tracking down the Debian patch Ubuntu is using. I regret that I didn't get it vetted in time to feel confident about merging it, but fixing things like corruptions and oopses and fsck failures came before a native ext4 /boot. -Eric
I do appreciate your efforts in fixing corruptions and oopses and fsck failure etc. But why I need LVM with just 1 HDD? Can you please add the patch at least in koji (or somewhere else)? For those who "don't like" f11 with separete /boot as ext3: 1. rebuild grub from http://sandeen.fedorapeople.org/grub-0.97-43.fc11.ext4.src.rpm 2. you can also aply the patch to more recent grub build from koji. 3. respin the install dvd and put the new grub.rpm in it. 4. install It's not perfect but it's a lot better than waisting 1 partition (from 4) just because of this. I hope we can see a better solution about this.
F12 has been open for a while, can we pleased get this patch applied so that the feature can get the desired testing?
I reviewed both the version of the grub patch Eric proposed (attached to this bug report) and the most recent Debian version. Eric's preferred version is cleaner and more correct and looks good to me, modulo one spelling error he will fix shortly. :) Ship it!
This patch is applied in grub-0.97-52 .
(In reply to comment #21) :-) anaconda need to be changed to support ext4 /boot in F12.
There should also be a grouped grub,anaconda update for F11 for respins to pick up.
(In reply to comment #23) > There should also be a grouped grub,anaconda update for F11 for respins to pick > up. Let's test it in rawhide just a bit first ;)
We're coming up on F12 alpha release, it'd be very nice to have this in there. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #25) > We're coming up on F12 alpha release, it'd be very nice to have this in there. And indeed, you might notice that the bug is in MODIFIED state; it's in there. ;)
I assumed it had been set to MODIFIED when the grub patch went in, given the discussion above. Happy to be wrong. =) So we just need someone to confirm they can do an install of Rawhide with /boot on an ext4 partition in order to close this... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Well, this was just the grub bug. Anaconda needed a change too, I dunno if it had a bug open. But this bug went to MODIFIED when grub got the ext4 patch committed. -Eric
And the anaconda patch went in right after (just via IRC, not via an explicit bug)
Setting this as blocking f12alpha (we want to confirm it's working for the alpha release). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
grub and anaconda are both changed. we may, at some point, want to change /policy/ on when we use what by default in anaconda, but support for using it is all there. ext4 by default on everything but /boot is what's currently there. ext4 can be used but is not default. If someone wants to confirm they can do an install of Rawhide with /boot on an ext4 partition we can close this out.
update: looks like the default was changed a short time ago as well.
As of 20090806 the default is still ext3 for /boot. However I forced my /boot to be ext4 and the system booted fine. Closing this bug.
For what it's worth, there is a *very* longstanding bug in grub (not grub2) that means that reading files with a few (ext4) extents is incredibly slow. On the bare-metal system I tested, a boot with an initramfs with just one extent took less than two seconds to load the kernel and initramfs. On the same system, and initramfs with seven extents (as reported by filefrag) took 24s to load. On other systems -- and especially virtual machines -- the difference is between a few seconds and several *minutes*. grub2 doesn't have the same problem so this (and its fix) are mainly of historic interest although it does still apply to RHEL6/CentOS6/OL6, of course.
Hi John, has that bug been filed or triaged anywhere? More details?
Not yet ...