The kernel-2.2.14-6.1.1.i686.rpm (and associated RPMs) apparently has >2GB support as I was able to create a 2.5GB tarball (from files over an NFS link). Unfortunately, when I upgraded to kernel-2.2.14-12.i686.rpm (and associated RPMs), any tarballs created crash at the "magical" 2147xxxxxx byte limit (2GB). From the information below, I can only surmise one of two reasons for this: A. The i686.rpm for 2.2.14-12 was compiled without it? (I am booting the stock i686.rpm kernel) B. The addition of the "2.2.14-lfs-fix.patch" in the newer 2.2.14-12 kernel breaks the >2GB file capability for Ext2 filesystems. Regarding "B", this is an RPM query on the .src.rpms of the two releases of 2.2.14 (6.1.1 and 12): $ rpm -qpl kernel-2.2.14-6.1.1.src.rpm | grep lfs linux-2.2.13-bigmem-no-lfs.patch linux-2.2.14-lfs-headers.patch linux-2.2.14-lfs.patch linux-2.2.14-sparc-fixes-lfs.patch $ rpm -qpl kernel-2.2.14-12.src.rpm | grep lfs linux-2.2.13-bigmem-no-lfs.patch NEW --> linux-2.2.14-lfs-fix.patch <-- NEW linux-2.2.14-lfs-headers.patch linux-2.2.14-lfs.patch linux-2.2.14-sparc-fixes-lfs.patch Again, note the "fix" applied in the newer kernel, which no longer seems to work for me. FYI, I assume the LFS patches applied are from the URL: http://linux-patches.rock-projects.com/v2.2-f/lfs-32bit.html Thanx in advance ... -- Bryan "TheBS" Smith Theseus Logic, Inc. P.S. I will do more testing and verify the results with a custom compiled kernel. I haven't done so since I just discovered this on a production server. Frankly, I was surprised that even 2.2.14-6.1.1 had this in the first place. I guess it was a nice surprise, but not one I should have gotten used to?>> ;->>>
2.2.14-6.1.1 was an enterprise upgrade kernel. The LFS patches to the 2.2.x kernel series are not as well tested in all situations as in the 2.4.x kernel series, so we do not turn them on by default.