Hello-- We have a system where a central server formats removable hard disks, which are then booted in an embedded system running a highly modified RH9. The removable disks themselves contain boot, root, and data filesystems. 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. 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>" (repeat for each of /boot and / filesystems) I've tried various combinations of mkfs options and mount options, with no luck. 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. 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. Are these known issues? Is this expected behavior? Can you recommend anything to fix the problem (aside from upgrading the embedded kernel to 2.6?) Thanks for your help, --Howdy =================== Howdy Pierce Managing Partner Cardinal Peak, LLC www.cardinalpeak.com ====================
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 -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20050221/b39ff3fc/attachment.sig>
On Feb 22, 2005 09:47 -0700, Howdy Pierce wrote:> Thanks for your prompt help. The problem (as you hinted) turned out > to be SELinux. > > So -- the extended attributes get turned on using SE Linux, and this > happens regardless of whether you use the -Onouser_xattr flag to > mount.The user_xattr flag only allows/prevents regular users from storing EAs to the filesystem.> 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 would guess that /sbin/init is a symlink then?> 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.Note that EAs (generally, this EA-on-symlink problem being an unfortunate exception) are compatible with older kernels. This functionality was added after EAs were developed and added to the kernel already. I agree it might be useful to have an option to prevent any EAs from being stored on a filesystem, since this also consumes space in the filesystem that has no value to your embedded device. I don't think that mounting the filesystem as ext2 will help as it also has EA support. As I mentioned previously, it is possible with a tiny patch to the 2.4 kernel to fix ext3_inode_is_fast_symlink() to understand symlinks with EAs. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20050222/fdcd6f86/attachment.sig>