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@xxxxxxxxxxxxx] Sent: Monday, February 21, 2005 8:01 PM To: Howdy Pierce Cc: ext3-users@xxxxxxxxxx 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 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
