On Mon, Jun 30, 2008 at 8:12 PM, Javier Martín <[EMAIL PROTECTED]> wrote: > El lun, 30-06-2008 a las 07:14 -0400, Isaac Dupree escribió: >> > +#define EXT3_FEATURE_INCOMPAT_RECOVER 0x0004 /* Needs >> > recovery */ >> >> > +#define EXT2_DRIVER_SUPPORTED_INCOMPAT ( EXT2_FEATURE_INCOMPAT_FILETYPE ) >> >> I suspect this will mean that journalled ext3 when the system crashed >> (so the filesystem "needs recovery" from the journal) won't load. (Of >> course, properly speaking that would load grub's code to replay the >> journal...) But I think that (without other changes) that would make >> the system unbootable every time there was a power outage? (Of course >> it was not guaranteed to load correctly when ignoring the journal when >> it needed recovery, but it was likely to work, IIUC.) >> >> -Isaac > > As I said, I didn't add it because I didn't know whether recovery was > supported or not. _Theoretically_ we should focus on correctness and > refuse to read such a filesystem, but here goes a workaround for > incompatible features that we do not support but still willingly want to > ignore for the sake of "compatibility". This new version of the patch > adds another macro, EXT2_DRIVER_IGNORED_INCOMPAT where we can put > features that we don't fully support, but still want a filesystem with > them to be mounted, like the needs_recover flag. > > Of course, this is risky: INCOMPAT_* features are so for a reason, but > it will allow dirty ext3 filesystems to be mounted until we have a > working journal implementation. I had thought of adding some kind of > warning, but since GRUB mounts and umounts filesystems constantly, it > just cluttered the screen and I removed it.
Hi, We must not quit if the journal flag is set, even if we don't handle it. grub-setup runs in a active system, the journal wouldn't be empty. If we just quit, we can't even install. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
