ext4: Unable to boot linux-image-2.6.28-7 or newer

IIRC corectly, migration path was:

Booting LiveCD with support for ext4 (jaunty alpha4, iirc) I did:

tune2fs -O extents,uninit_bg,dir_index /dev/sda2
(changed ext3 to ext4 in fstab)

Then I rebooted which resulted in errors group descriptors on FS. Going back to LiveCD and doing fsck:

fsck -pf /dev/sda2

solved that problem. I've used system normally until new kernels got introduced.

These are the patches that have been applied from git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for-stable. I believe the Ubuntu Jaunty tree is consistent with regard to stable patches for ext4.

a061dca583b37c7146b0a7bfff4a9d261cfe6569 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Initialize the new group descriptor when resizing the filesystem
ad8f7fc46d665f5ec310e0e85b942e52c21b796e UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] jbd2: On a __journal_expect() assertion failure printk "JBD2", not "EXT3-fs"
1906a5fddfb971e542afca5331317fd024a60f4e UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Add sanity check to make_indexed_dir
02fdb472dd20958ce8312236c7f8dbad56f69a2f UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: only use i_size_high for regular files
ae36a1c34d2152bf12872e266d1ceb1767cb4f19 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Add sanity checks for the superblock before mounting the filesystem
5ba014073b5bc1e694d384ddc83dd631b494a4bf UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc
7dd17cb59913bc840f4f9afb939c80d278567ff3 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Init the complete page while building buddy cache
2f4e5185503a4fe45e1095fa97a91b168a6e9dea UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Don't allow new groups to be added during block allocation
f362329e7ba213965cbd64bd6cc2f7b9f3d29513 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: mark the blocks/inode bitmap beyond end of group as used
24e067f6e163f098643cffac39bf89c63945ab0a UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Use new buffer_head flag to check uninit group bitmaps initialization
455efd1c02074f9c79e4726de9a47e8fef9def33 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] jbd2: Add BH_JBDPrivateStart
1e6202778728ec29b7eb7fb0df5d45732eafefd7 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Fix the race between read_inode_bitmap() and ext4_new_inode()
0bfe75ee038b6774197e03990c1e6132c26cc4dc UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Fix race between read_block_bitmap() and mark_diskspace_used()
f5de197efcd44096152aacc0e8d3c02637959185 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: don't use blocks freed but not yet committed in buddy cache init
bfe25765f9d655bcdb0ed883786ef1ad8509b027 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: cleanup mballoc header files
dbf8b1c4e8122e705447b69aea9ee6ef3a9caa30 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize
455220fb409ce06ac3c902417c5a85d17b0308c0 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Add blocks added during resize to bitmap
ee83e1624f60d902277b1071e58365b3fedaf6e0 UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] ext4: Don't overwrite allocation_context ac_status
dad87da3db508b0e7befb67c2d7e70219b2bcafc UBUNTU: SAUCE: (revert before 2.6.28.y update) [PATCH] jbd2: Add barrier not supported test to journal_wait_on_commit_record
7a2025d90a50a1bfa145bbc9b...

@Ante

One needs to run grub-install to install the new grub stage_2 into /boot/grub. Please can you do this and re-try and let me know what happens.

Colin

Colin, yes, that solved the issue.

I have to wonder how you got through the upgrade without having to also upgrade grub. Any thoughts on how that might have occured?

On Thu, 19 Feb 2009 21:17:34 -0000
Tim Gardner <email address hidden> wrote:

> I have to wonder how you got through the upgrade without having to
> also upgrade grub. Any thoughts on how that might have occured?

Well, that's beyond me. I've mentioned I've reinstalled grub couple of
times after, but I just noticed that removing grub doesn't
remove /boot/grub/stage*, so reinstalling grub doesn't solve anything.

I'm not into kernel that much to be able to tell why -6 worked and -7
didn't :/

If I can provide you with any other data, I'd be happy to give you all
the information I have.

I'm gonna mark this bug Fix Released since grub was shown to correct the issue.

This bug is related to bug 316872, specifically note: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/316872/comments/16

A new upgraded version of grub does not automatically install the new grub stage 2 that contains the ext4 support. Apparently grub-install is not generally something that's safe to run automatically on upgrades. I believe the upgrade from ext3 to ext4 and the re-running of grub-install will be put into the Jaunty release notes.

Colin (or anyone else for that matter) could you give me a (little more) detailed description on how to (re-)run this grub-install. I just converted a jaunty machine to ext4 using:
sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda5
sudo fsck -pf /dev/sda5
also changed it to ext4 in fstab

I am currently getting the "Error 13: Invalid or unsupported executable format" problem. If I understand it correctly running grub-install can solve this problem.

After some experimentation I ran the following code from a live-cd:
sudo bash
mount /dev/sda5 /mnt
grub-install /dev/sda --root-directory=/mnt --recheck

Seems to work, did I do it well?