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

Re: root fs type in fstab

Brian writes:
> There is a bug with the new options.  If you supply a "-j" but no
> "-J..." it will complain.  I believe this is because of:
>         if (!open_flag && !l_flag)
>                 usage();

I'll have a look at that.

> The manual page also does not state that "size" is in terms of MBs.

Already fixed.

> Actually, it used a reserved inode even though the filesystem was
> mounted.  I can tell you why.  I am creating the system with the ext3
> root filesystem via kickstart.  Kickstart gives you a hook after every-
> thing is loaded to run some customization shell script.  At that point,
> the filesystem is mounted but /etc/mtab is not populated.  I guess my
> scripts could mock up an /etc/mtab so that tune2fs understands it
> really is mounted.

Eeek.  Maybe we should check for the existence of /proc/mounts and
/proc/swaps and check those before trying /etc/mtab.  If you are
doing a full install, simply use "mke2fs -j" in the first place(*).

> > However, it is still worthwhile to figure out where e2fsck is
> > segfaulting (before you upgrade ext3 or e2fsck),
> I guess what puzzles me is why is the journal being replayed on that
> first boot?  It does seem as though it is corrupting the superblock
> and it is the corrupt superblock that is causing the remaining failures
> including the SIGSEGV.
> Is the reason for the journal replay not really the issue to track down?

Yes, if that issue is still in 0.0.5e (it may have been fixed by the
proper initialization of the journal superblock).

> I am guessing if the journal replay is not done (why should it be --
> it's a brand new ext3 filesystem afterall) then the superblock wouldn't
> get corrupted and the rest of the problems would go away, no?

However, if there is a possibility of segfaulting in e2fsck, it should
also be tracked down, because it will happen again sooner or later with
some other corrupt journal, so it still needs to be fixed.  Having a
100% reproducable problem makes it easier to find.

> Oh... the tune2fs option for creating the journal is sweet!!  In
> my short trawl through the code it looked like mk2efs was capable of
> creating filesystems with journals on them much like a "mk2efs +
> tunefs -j" would produce.

Yes, this should already be documented in the mke2fs man pages as well.
The tune2fs options are really only for changing existing ext2 filesystems
to ext3.

> Would it not be correct to hack together an mkfs.ext3 by doing some
> argv[0] checking in mk2efs then?

(*) I have already done so, and they will likely be in the Turbolinux
    package, but Ted didn't like the idea.  I can send you the mke3fs
    patch if you want.

Cheers, Andreas
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

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