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.
It's not a huge deal -- and if you have your root on ext4dev before
2.6.28, you get an extra helping of "use at your own risk", anyway --
but it's an extra caveat that it might pay to be aware of.
I didn't mention this when I ran into this before because that first
2.6.28-rc kernel I booted didn't crash after fsck cleared that flag,
and I've just been working around it. I finally managed to get make
one of my computers unbootable this morning because of this, though.
It was user error, but now I have to take the box apart and put a CD
drive in it, just so I can boot a live CD and set that &^*# flag again.
Since (I'm guessing that) the bit that does the clearing seems to be
in e2fsck, and not in the kernel, it doesn't seem like there's much
that could be done about it. In hindsight though, a deprecation
period might have been called for.
Ehn, it could be worse; I could have lost data.
Thanks.
--
Joseph Fannin
[email protected]
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.
- Ted
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
[email protected]