support installation on and boot from ext4

I use ext4 since the 2.6.22 kernel on 3 PCs (one desktop, one laptop and a server).
never had a single issue with it other than to install Debian's Grub2 (grub-pc package) to boot it without having to create a separate /boot

e2fsprogs contains all of the ext4 support

Grub would need to support reading from ext4 filesystems

We already ship the ext4 module with our kernel, nothing from Linux needs this

Ubuntu probably also needs installer support...

In my opinion it's a good choice, but we need 3 things:

1) grub2 as default bootloader
2) an updated grub-pc package
3) installer support
4) some testing and users feedback, it never hurts

I don't want to scare people but i've lost my ext4 partition:

root@ubuntu:~# mount -t ext4dev /dev/sda1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

root@ubuntu:~# dmesg | tail -1
[ 4874.514703] VFS: Can't find ext4 filesystem on dev sda1.
root@ubuntu:~# e2fsck /dev/sda1
e2fsck 1.41.3 (12-Oct-2008)
e2fsck: Superblock invalid, trying backup blocks...
/dev/sda1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error1: Corrupt extent header on inode 107192
Aborted (core dumped)
root@ubuntu:~# gdb -q --args e2fsck /dev/sda1
(gdb) run
Starting program: /sbin/e2fsck /dev/sda1
[Thread debugging using libthread_db enabled]
e2fsck 1.41.3 (12-Oct-2008)
/sbin/e2fsck: Superblock invalid, trying backup blocks...
/dev/sda1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error1: Corrupt extent header on inode 107192
[New Thread 0xb7e46700 (LWP 12878)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e46700 (LWP 12878)]
0xb8031430 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xb8031430 in __kernel_vsyscall ()
#1 0xb7e8c880 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7e8e248 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0805397b in scan_extent_node (ctx=0x9193038, pctx=0xbf830d7c, pb=0xbf830c5c, start_block=0, ehandle=0x91b8170) at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1700
#4 0x08054c02 in check_blocks (ctx=0x9193038, pctx=0xbf830d7c, block_buf=0x91acff0 "\225\"\005") at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1773
#5 0x080565ca in e2fsck_pass1 (ctx=0x9193038) at /build/buildd/e2fsprogs-1.41.3/e2fsck/pass1.c:1030
#6 0x08050063 in e2fsck_run (ctx=0x9193038) at /build/buildd/e2fsprogs-1.41.3/e2fsck/e2fsck.c:215
#7 0x0804e4b8 in main (argc=Cannot access memory at address 0x324e
) at /build/buildd/e2fsprogs-1.41.3/e2fsck/unix.c:1278
(gdb)

On Sat, Dec 20, 2008 at 06:00:49PM -0000, Matteo Croce wrote:
> I don't want to scare people but i've lost my ext4 partition:
>
> root@ubuntu:~# mount -t ext4dev /dev/sda1 /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/sda1,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
>
> root@ubuntu:~# dmesg | tail -1
> [ 4874.514703] VFS: Can't find ext4 filesystem on dev sda1.
> root@ubuntu:~# e2fsck /dev/sda1
> e2fsck 1.41.3 (12-Oct-2008)
> e2fsck: Superblock invalid, trying backup blocks...

That's not good.... What version of the kernel were you using, and
did you have any patches applied? Do you know what the system was
doing when the corruption happened?

> /dev/sda1 was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Error1: Corrupt extent header on inode 107192
> Aborted (core dumped)

OK, that's an embarassing hole that I had left for later to fill in,
and forgot to complete in e2fsck. It's caused by a corrupted extent
index node in the file. The easiest way to recover from the problem
is to simply wipe out the inode, since it's likely most of the data in
that inode has already been lost:

debugfs -s 32768 -b 4096 -w /dev/sda1
debugfs: clri <107192>
debugfs: quit

I'll get a better fix into e2fsprogs; thanks for pointing this out.

                                 - Ted

vanilla 2.6.27

debugfs complains about bad superblock.
I did: mke2fs -S /dev/sda1 but now my disk is empty

"mke2fs -S" is __very__ dangerous unless you give it exactly the same arguments that was used to make the filesystem in the first place (which probably in this case was something like "mke2fs -t ext4 /dev/sda1", so you have to use "mke2fs -t ext4 -S /dev/sda1" if you want to have any hope of mke2fs -S _not_ trashing your filesystem.

In this case it wouldn't have helped you much, given that e2fsck was able to use the fallback superblocks just fine. The failure was due to a bug in e2fsck -- specifically, an unhandled case where an interior node has a corrupted extent header. The cases where this will even show up is quite rare; I have one inode out of the 760,486 inodes in use that would even potentially be vulnerable to this failure (where the extent tree depth is >=2). In any case, I'll get this fixed in the next version of e2fsck's maintenance release.

On Tue, Dec 23, 2008 at 5:17 AM, Theodore Ts'o <email address hidden> wrote:
> "mke2fs -S" is __very__ dangerous unless you give it exactly the same
> arguments that was used to make the filesystem in the first place (which
> probably in this case was something like "mke2fs -t ext4 /dev/sda1", so
> you have to use "mke2fs -t ext4 -S /dev/sda1" if you want to have any
> hope of mke2fs -S _not_ trashing your filesystem.
>
> In this case it wouldn't have helped you much, given that e2fsck was
> able to use the fallback superblocks just fine. The failure was due to
> a bug in e2fsck -- specifically, an unhandled case where an interior
> node has a corrupted extent header. The cases where this will even
> show up is quite rare; I have one inode out of the 760,486 inodes in use
> that would even potentially be vulnerable to this failure (where the
> extent tree depth is >=2). In any case, I'll get this fixed in the
> next version of e2fsck's maintenance release.
>
> --
> make ext4 as the primary filesystem for GNU/Linux
> https://bugs.launchpad.net/bugs/293465
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I did mkfs.ext4 -S

An update

With grub giving us an update

https://lists.ubuntu.com/archives/jaunty-changes/2009-January/002558.html

grub (0.97-29ubuntu47) jaunty; urgency=low

  [ Colin King ]

  * New patch, ext4_support now allows grub to boot from ext4 partitions.
    This patch orginated from Quentin Godfroy <godfroy at clipper.ens.fr>

util-linux

util-linux (2.14-1ubuntu3) jaunty; urgency=low

https://lists.ubuntu.com/archives/jaunty-changes/2009-January/002608.html

  * debian/rules: Install rules into /lib/udev/rules.d instead
  * debian/util-linux.dirs: Create new location, don't create old.
  * debian/util-linux.preinst: Remove the old rules if unmodified.

and kernel 2.6.28 which is there since last week of december

The only things remaining are e2fsprogs and ubiquity I guess.

I believe we have e2fsprogs v1.41.xx in Jaunty already which should be fine for Jaunty.

Grub2 is also working well for me at the moment.

So i guess we just need it in Ext4 in the installer now.

I'm working on installer support.

I'm changing the title as I think we're putting the cart before the horse slightly. Let's get ext4 supported at all, and then later it will be simple to flip the default if it's working well.

This bug was fixed in the package partman-auto - 83ubuntu2

---------------
partman-auto (83ubuntu2) jaunty; urgency=low

  * Add ext4 support (LP: #293465).

 -- Colin Watson <email address hidden> Thu, 08 Jan 2009 16:53:23 +0000

This bug was fixed in the package partman-partitioning - 64ubuntu2

---------------
partman-partitioning (64ubuntu2) jaunty; urgency=low

  * Add ext4 support (LP: #293465).

 -- Colin Watson <email address hidden> Thu, 08 Jan 2009 16:55:00 +0000

This bug was fixed in the package partman-ext3 - 55ubuntu2

---------------
partman-ext3 (55ubuntu2) jaunty; urgency=low

  * Add ext4 support (LP: #293465). Some translatable strings are still
    incorrect, but that will be fixed once this gets into Debian.

 -- Colin Watson <email address hidden> Thu, 08 Jan 2009 16:51:06 +0000

As Shirish already noted, the necessary grub support was added by Colin King earlier this week.

This bug was fixed in the package ubiquity - 1.11.2

---------------
ubiquity (1.11.2) jaunty; urgency=low

  * Adjust for changes in tzsetup 1:0.24ubuntu1.
  * Correct Bazaar link in debian/copyright (pointed out by shirish).
  * Make sure that only one of grub and lilo is installed (LP: #314004).
  * Add ext4 support (LP: #293465).
  * Automatic update of included source packages: apt-setup 1:0.37ubuntu7,
    hw-detect 1.71ubuntu3, partconf 1.30build1, partman-auto 83ubuntu2,
    partman-base 128ubuntu4, partman-ext3 55ubuntu2, partman-partitioning
    64ubuntu2, partman-target 58ubuntu2, tzsetup 1:0.24ubuntu1, user-setup
    1.23ubuntu6.

 -- Colin Watson <email address hidden> Thu, 08 Jan 2009 18:40:19 +0000