e2fsprogs-1.38 <-> e2fsprogs-1.34

  • Tagore

    Tagore - 2007-02-14

    A dualboot- Machine "Fedora Core 1" / "Fedora Core 4"
    stops booting "FC1" with
    "fsck.ext3: File system has unsupported feature(s). Get a newer version of e2fsck!"

    The problem arises when FC1-root has been once mounted under FC4.
    FC1 has native rpm-support for e2fsprogs-1.34 _only_, FC4 uses e2fsprogs-1.38

    Does someone know by chance:
    - what causes this probable ext3-version-conflict ?
    - is there a backward-compatibility-mode I could use under FC4 ?
    - does it make sense to compile and use my own e2fsprogs-1.38_FC1.rpm at all ?

    Thanks !

    • John Sutton

      John Sutton - 2007-02-14

      You have encountered the selinux nightmare (tm) ;-(

      To avoid this, when you install FC4 add selinux=0 to the kernel command line when you boot the cdrom AND make sure you add it to the grub options for the new system during the install process.  Bottom line is this: if an selinux enabled kernel ever, even just once, gets its hands on your ext2/3 partition, then that partition is not usable thereafter with earlier non-selinux kernels.  This is as far as my understanding of it goes.  Here are some notes I wrote at the time, after some days of agony...  Good luck!

      If you are using the FC3 rescue disk to fiddle with ext2/3 filesystems which you want to
      be usable with earlier linux kernels, be careful!

      The problem is 2 new filesystem features: ext_attr resize_inode

      To see the features of a filesystem, use

      tune2fs -l /dev/xxx | grep features

      The resize_inode feature can be removed from the default set of features used
      by mke2fs at filesystem creation time, thus:

      mke2fs -O ^resize_inode /dev/xxx

      Note that this feature *cannot* be removed from a filesystem that has been created (as can, for
      example, the filetype feature, using tune2fs -O ^filetype /dev/xxx) and although it doesn't seem to
      prevent the mounting and use of the filesystem by earlier kernels, the stock e2fsck supplied with earlier kernels will refuse to touch the disk ;-(

      The ext_attr feature (used by SElinux) is a different animal altogether. This cannot be specified or unspecified at filesystem creation time. Rather, if the FC3 kernel (amd maybe all 2.6 kernels?) is running with SElinux enabled, then the first time the kernel writes a file to the filesystem, this attribute is set in the filesystem superblock and thereafter there is no way to remove it. Such a filesystem is virtually unusable by earlier kernels because:

      1) soft links are not readable
      2) although the fs is mountable as root, when the kernel attempts to exec /sbin/init it will fail

      So, if you want to use the FC3 kernel, you need to boot it with kernel param selinux=0 to switch off the selinux stuff in the kernel. It is *not* enough to umount /selinux at runtime.

      A third feature - large_file - is added to the superblock whenever a file >2GB (or maybe that is 4GB?) is created on a filesystem, and like the ext_attr feature this is not controllable at creation time and cannot be removed with tune2fs. Not sure if it causes any problems (surely will for old *enough* kernels) but apparently it can be removed thus:

      # debugfs -w <device> <<EOF
      > feature -large_file
      > dirty
      > close
      > quit
      > EOF

      followed by

      # fsck.ext2 <device>

      to make sure that you really don’t have large files sitting around; if some are still there, fsck will set the ‘large_file’ flag back again!

    • Tagore

      Tagore - 2007-02-15

      thanks to your usefull hints, johnesutton.

      I was careful enough however never having used selinux.

      Nor does tune2fs -l mention "ext_attr" or "resize_inode", probably because I created the filesystems under FC1: (Filesystem features:      has_journal filetype [needs_recovery] sparse_super)

      After boot-error
        "fsck.ext3: File system has unsupported feature(s). Get a newer version of e2fsck!"
      one was dropped to singleuser-shell could issue "init 5" to complete booting.

      I compiled a e2fsck-1.38-fc1-static after that and voila: FC1 boots without singleuser-stop...

      What is this? Is there a version-conflict in e2fsprogs that interferes whith a Multiboot-Scenario ?


Log in to post a comment.