ext3 compatibility between 2.4 and 2.6 kernels
Howdy Pierce
howdy at cardinalpeak.com
Tue Feb 22 16:47:35 UTC 2005
Andreas--
Thanks for your prompt help. The problem (as you hinted) turned out
to be SELinux. On my FC3/kernel 2.6.9 system, I did the following:
1. mkfs -t ext3 -L "/boot" /dev/sda1
2. dumpe2fs -h /dev/sda1
Output:
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name: /boot
Last mounted on: <not available>
Filesystem UUID: a6fb6a06-be6d-4716-8c39-861f97e77954
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode filetype
sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 26208
Block count: 104420
Reserved block count: 5221
Free blocks: 95441
Free inodes: 26197
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2016
Inode blocks per group: 252
Filesystem created: Tue Feb 22 09:00:18 2005
Last mount time: n/a
Last write time: Tue Feb 22 09:00:20 2005
Mount count: 0
Maximum mount count: 30
Last checked: Tue Feb 22 09:00:18 2005
Check interval: 15552000 (6 months)
Next check after: Sun Aug 21 10:00:18 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 612d72f8-bf3c-4056-a0de-d4162a3a6c5e
Journal backup: inode blocks
3. mount /dev/sda1 /mnt
4. tar xf (source file) -C /mnt
5. umount /dev/sda1
6. dumpe2fs -h /dev/sda1
Output:
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name: /boot
Last mounted on: <not available>
Filesystem UUID: a6fb6a06-be6d-4716-8c39-861f97e77954
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode filetype
sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 26208
Block count: 104420
Reserved block count: 5221
Free blocks: 88714
Free inodes: 26161
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2016
Inode blocks per group: 252
Filesystem created: Tue Feb 22 09:00:18 2005
Last mount time: Tue Feb 22 09:00:50 2005
Last write time: Tue Feb 22 09:01:09 2005
Mount count: 1
Maximum mount count: 30
Last checked: Tue Feb 22 09:00:18 2005
Check interval: 15552000 (6 months)
Next check after: Sun Aug 21 10:00:18 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 612d72f8-bf3c-4056-a0de-d4162a3a6c5e
Journal backup: inode blocks
So -- the extended attributes get turned on using SE Linux, and this
happens regardless of whether you use the -Onouser_xattr flag to
mount.
When I disabled SE Linux and repeated the test, the dumpe2fs from
before and after the mount/tar/umount was more similar. Also,
symbolic links were now readable from a 2.4 kernel, and my embedded
system boots correctly (and finds init).
I can't say I really understand enough about SE Linux to have an
opinion as to whether this is a bug or not. It seems like there
should be some option, even on an SE Linux system, to write ext2/3
filesystems in a backward-compatible manner.
In any event -- thanks once again for all the helpful responses...
--Howdy
-----Original Message-----
From: Andreas Dilger [mailto:adilger at clusterfs.com]
Sent: Monday, February 21, 2005 8:01 PM
To: Howdy Pierce
Cc: ext3-users at redhat.com
Subject: Re: ext3 compatibility between 2.4 and 2.6 kernels
On Feb 21, 2005 17:01 -0700, Howdy Pierce wrote:
> The problem we've encountered after upgrading to FC3 / kernel 2.6 on
> the central server is that the 2.4 kernel in the embedded system
> cannot read the root filesystem, and panics with a message about not
> being able to find init.
Having the specific messages from ext3 would help here.
> The scenario is -- running FC3:
>
> 1. "mkfs -t ext3 -O none <device>" on removable disk
> 2. "mount -Onoacl,oldalloc,nouser_xattr <device> <mountpoint>"
> 3. "tar xf" onto mountpoint
> 4. "umount <mountpoint>"
What does "dumpe2fs -h" say for the filesystem after umount? The
"oldalloc" mount option shouldn't leave any permanent change to the
filesystem (it is just the inode allocation policy). Also, using
"-O none" also disables sparse superblocks, which can consume a lot
of space for large filesystems.
> Furthermore, I've tried performing the mkfs on a RH9/kernel 2.4.20
> system, and then performing the mount/tar/unmount on a FC3/kernel
> 2.6.9 system. Even this combination fails -- it seems the untarring
> on FC3 somehow creates an ext3 filesystem that the embedded 2.4
kernel
> cannot read.
Does your FC3 kernel have selinux enabled?
> Finally -- this may be a clue -- I've noticed that regardless of
where
> the ext3 filesystem was created, symbolic links created on the
FC3/2.6
> kernel cannot be read on my 2.4 kernel.
This sounds like there are EAs being placed on the symlinks, which can
cause problems for older kernels (it was an oversight during ext3
development that this was allowed).
> Can you recommend anything to fix the problem (aside from upgrading
> the embedded kernel to 2.6?)
I think there is a one-line fix to "ext3_inode_is_fast_symlink",
adding
a check for "i_file_acl" to determine if it is a fast (internal to
inode)
or slow (external block) symlink. This should already be done in
newer
2.4 kernels also.
Cheers, Andreas
More information about the Ext3-users
mailing list