grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-probe detects ext4 wronly as ext2


From: Javier Martín
Subject: Re: grub-probe detects ext4 wronly as ext2
Date: Wed, 02 Jul 2008 01:28:47 +0200

El mar, 01-07-2008 a las 22:48 +0200, Robert Millan escribió:
> On Tue, Jul 01, 2008 at 08:42:39PM +0200, Javier Martín wrote:
> > partition as "unrecognized" and then I had to specifically request it to
> > be mounted as ext2 with a possible --ignore-incompatible flag,
> 
> A --ignore-incompatible flag doesn't sound like a nice thing to do;  it means
> we're passing our own problem to the user instead of solving it.
We don't have any "problem" to pass to users: ext4 is not supported and
thus we do the Right Thing (tm) in patching our ext2 driver so that it
won't try to read a filesystem it cannot. However, given Pavel's and
others' objections, I suggested the addition of an user override to it.
Thus, the user will have to knowingly force the system to interpret the
filesystem with its current code, and accept any failures he might get,
instead of the current behaviour of having the FS mounted automatically
without checking incompatibilities (and then getting the errors anyway).

Furthermore, the possibility of accidentally adding an incompatible
feature is not exactly high: for an ext3 FS to get one of the ext4
flags, one has to explicitly mount it as "ext4dev" (usually installing
or hand-compiling the module before, because most distros don't include
it by default) _and_ create new files on it. Then and only then will the
FS gain the extents flag.
> 
> Though, if non-essential stuff needs to be implemented, please take into
> account that we're really pressed for space in ext2.mod (and try to use a
> separate module for that).
> 
The proposal (a patch which is essentially under ten lines of code long)
could _avoid_ the implementation of format compatibility checks in all
the inode-handling functions, since after passing the compatibility
check we know the format we'll encounter is at least ro-compatible with
our capabilities, or the user is braced for the possible errors. With
the current implementation, an unawares user could be flooded by inode
format errors becase, for example, an ext4 FS got mounted by our ext2
driver.

The override proposal is not implemented in the current patch, but it
could be as simple as an environment variable. Consider this case, with
(hd0,1) an ext3 /boot partition that was accidentally converted to ext4
and then got a file copied to it (the 2.6.26-rc2 kernel), then gaining
the extents flag:
        grub> ls (hd0,1)/
        error: unrecognized filesystem
        grub> set ext2_options=ignore_incompatible
        grub> ls (hd0,1)/
        kernel-2.6.24-r1 kernel-2.6.26-rc2
        grub> kernel (hd0,1)/kernel-2.6.26-rc2 root=/dev/sda5
        error: file not found # (I dunno what error "bad inode" is)
        grub> kernel (hd0,1)/kernel-2.6.24 root=/dev/sda5
        [Linux-bzimage, 0x100000]
        grub> boot

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

[Prev in Thread] Current Thread [Next in Thread]