Description of problem: When using interactive installation (GUI or text) with ext4 support, anaconda ends in traceback. All filesystems are properly formatted by anaconda, next step, installation of packages, doesn't start, it's interrupted by traceback Version-Release number of selected component (if applicable): RHEL5.3-Server-20081006.0-i386 Steps to Reproduce: 1. Start interactive installation 2. Select ext4dev format for root partition 3. Proceed to start of copying
Created attachment 319860 [details] Anaconda log
Are there any read errors from the CD drive? Did you run media check before starting? I don't think we've seen this yet in any nightly testing.
Installation media (CD image) passed media check. Also sha1sum of iso file is correct. I didn't find any issue related to CD drive like read errors etc. I'm using qemu/kvm virtual machine for testing.
Created attachment 319869 [details] dmesg log
a guess: can't the problem be that the underlying ioctl(fd1, LOOP_CHANGE_FD, fd2) call, where fd1 points to /mnt/source/images/stage2.img and fd2 points to /mnt/sysimage/rhinstall-stage2.img which is on ext4dev fails with EINVAL (22) because ext4dev doesn't support splice_read operation?) (see loop_change_fd in linux/drivers/block/loop.c)
(In reply to comment #5) > a guess: can't the problem be that the underlying > > ioctl(fd1, LOOP_CHANGE_FD, fd2) > > call, where fd1 points to /mnt/source/images/stage2.img > and fd2 points to /mnt/sysimage/rhinstall-stage2.img which > is on ext4dev fails with EINVAL (22) because ext4dev doesn't blah, wrong guess, 22 is ENODEV > support splice_read operation?) > (see loop_change_fd in linux/drivers/block/loop.c)
(In reply to comment #6) > > is on ext4dev fails with EINVAL (22) because ext4dev doesn't > > blah, wrong guess, 22 is ENODEV oops, 22 is really EINVAL
Same result with installation over http, doesn't matter on structure of installation tree. I fails with disk{1,2,3,...} directories as well as with whole installation tree in one directory.
This is probably due to an embarassing thinko; I left out the ->sendfile aops on the backport; it doesn't exist upstream and no testsuite caught this. See also Bug 465584 I'll make a fixed ext4dev.ko for rvykydal to test, hopefully this is all it is. -Eric
The fixed module works, tested on cdrom install with RHEL5.3-Server-20081009.nightly-i386-DVD.iso.
*** Bug 466758 has been marked as a duplicate of this bug. ***
Ok, so this is an ext4 kernel bug. The fix is a 3-line addition to ext4, no impact outside of this filesystem.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 465584 has been marked as a duplicate of this bug. ***
in kernel-2.6.18-121.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
Verified with RHEL5.3-Server-20081102.nightly-i386 (source on cdrom). Issue didn't occur.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html