linux-ext4 - Re: Re: Autoremoval of test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 12 Feb 2009 11:43:49 -0500
From:	Joseph Fannin <jfannin@...il.com>
To:	Theodore Tso <tytso@....EDU>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Re: Autoremoval of test_fs flag kinda sucks

On Sun, Dec 21, 2008 at 09:28:15PM -0500, Theodore Tso wrote:
> On Sun, Dec 21, 2008 at 08:43:27AM -0500, Joseph Fannin wrote:
> > This is mostly me blowing off a little steam here, so yeah.  But maybe
> > it won't hurt to send out a heads up and get this in the archives:
> >
> > Booting a 2.6.28-pre kernel will cause e2fsck to remove the test_fs
> > flag from any filesystem it checks, presumably because "ext4dev" has
> > become "ext4" in 2.6.28.  If your root fs is on ext4, this makes it
> > impossible to reboot back into a older kernel (i.e. < 2.6.28) since it
> > will refuse to mount an ext4dev fs without the "test_fs" flag set --
> > unless you chase after e2fsck and set the flag back.
>
> Yeah, Sorry I guess I didn't think it was going to be *that* common
> for people to be going back and forth between the boundary.  It is
> possible to disable this, BTW, via /etc/e2fsck.conf:
>
> [options]
> 	clear_test_fs_flag = false
>
> The assumption I made was that the number of pre-2.6.28 ext4 users
> would be small, and so it would be safe to default the option to true.

I wanted to thank you for the reply to this (old) mail; due to the
vagaries of Gmail I didn't see this until yesterday when I went
searching the linux-ext4 archives.  I need to bone up on my
procmail-foo, but I keep putting it off.

It sounds like I should have mentioned this issue when it first came
up; I might not only have saved myself some trouble, but had something
more productive "for the archives".

Of course, I only went looking at the linux-ext4 archives because I
have another problem:  I have a damaged ext4 filesystem that fsck
can't fix.  I've been making preparations to zap it with a new mkfs,
but before I take the plunge it might be best to ask for a bit of
help.

I don't suppose there's a .deb of e2fsprogs v1.41.4 around somewhere,
is there?  I'm guessing the Debian freeze is the reason why it's not
in unstable yet.  I can build it myself if not, no worries.

Also, would there be any value in an image of this broken fs before I
blow it away?  I'm not comfortable sharing the whole thing, but I
understand it's possible to create an image with no data and scrambled
filenames.

I'm currently running the FS without a journal, because it won't mount
with the "has_journal" flag set; the kernel complains "no journal
found" IIRC.  I tried recreating the journal (removing the
"has_journal" flag, then doing a `tune2fs -j`) but it still doesn't
work.

I'm taking my time with this, copying data to wherever I can find
space, because I don't have a backup.  Both pieces, yes.  I'm batshit,
yes.  Once I get over half the data copied off, I intend to try to
shrink the FS, create a new LVM volume with the freed disks, copy the
data over, then grow the FS to encompass the new (old) disks.  It took
me longer than it probably should to realize that resize2fs might
choke on the filesystem, broken as it is.  Oh well.

If any of this info could be useful, or if there's something obvious
I'm missing, please let me know.  Thanks.

--
Joseph Fannin
jfannin@...il.com

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html