From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040808 Firefox/0.9.3 Description of problem: My NFS server is an FC2 machine, exporting a loopback-mounted DVD image. The DVD image SHA1SUM is good. My install machine is a Dell Precision 370 (with a EM64T P4). I'm booting it with a boot.iso CD. Every time I try to install FC4t3 *or* FC3, the install appears to finish package installation, but crashes immediately afterwards. It appears that anaconda is getting bad data when it tries to read stage2.img *after* package installation is finished, but not earlier. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Loopback-mount DVD image & export it on NFS server. 2. Boot install machine with boot.iso CD, choose mostly defaults, and either Minimum or Everything install (didn't try in between). Actual Results: The installation crashed apparently immediately after all packages were installed. The child anaconda process got a segfault after trying to re-read stage2.img, and the parent anaconda process crashed with an illegal instruction. Expected Results: Installation succeeds. Additional info: This happens with both FC4t3 *and* FC3. Since this hasn't been reported for FC3, it seems most likely that I'm the only one seeing this, and I took extra steps to make sure I have good hardware and am doing things correctly. I've tried FC3 once or twice, and FC4t3 many times, always with the same crash pattern, so it's very reproducible. I ran a memtest86+ for 18 minutes on the install machine with no errors. If instead of the NFS-exported loopback-mounted DVD image I use an actual mediachecked DVD from the same DVD image, the installation succeeds. So the machine appears basically fine, and the problem seems most likely to be specific to the NFS installation.
I apologize for the run-on lines. Darn Firefox on FC2.
Created attachment 114375 [details] a dump of the install machine's /tmp/syslog from early in the installation I obtained this using nc (netcat). Is there an easier way?
Created attachment 114376 [details] syslog from later part of installation process, showing crash at end I again obtained this using netcat, redirectly input from /proc/kmsg to a listener on another machine. I turned on NFS debugging, which is useful to see what files were being requested, and how they relate to the errors toward the end. I transiently turned on RPC debugging as well, but that's voluminous & useless. See toward the end that the yum rpm is installed (the last package to be installed in this Minimal install?), then anaconda goes back to reading stage2.img. At this point, it starts getting other errors and eventually segfaults. Earlier it read stage2.img with no problem.
Interestingly, I did not get run-on lines in the attachment comments, depsite forgetting to add linefeeds. Are the bug-submission and attachment-submission forms processing test input differently? This comment has manual linefeeds.
*** Bug 142600 has been marked as a duplicate of this bug. ***
I just wrote a nice long reply, Chris, but it got clobbered by my browser mismanagement. :/ Let's try again... I don't believe that Bug 142600 is a duplicate of this bug. I never saw the error "Unable to find Fedora/base/stage2.img" like the other reporter did. In my case, anaconda accessed stage2.img just fine in the beginning. When it failed during reads of stage2.imag late in the install process, the 'Errpr -3..." errors that got thrown (before anaconda segfaulted) appear to be from cramfs, not anaconda itself. So much for the differences between the earlier bug and mine. My latest, best understanding of what might be going on in my case is that: 1) there is some problem with NFS access or cramfs decompression of stage2.img only *after* all the rpms have been installed 2) cramfs fails (the "Error -3..." messages), and doesn't give anaconda the data it was expecting 3) either cramfs doesn't return an error to anaconda, or (more likely?) anaconda doesn't check the error status, so anaconda happily processes the bad data from cramfs 4) anaconda segfaults as a result of the bad data If that scenario is correct, then there are two problems: a) anaconda (or possibly cramfs) isn't handling cramfs errors correctly b) mysteriously, NFS access of stage2.img fails late in the install process I'm complaining mostly about (b), but if (a) exists, it'd probably be easier to detect and correct. One final note: There are avc denied errors in the attached install logs. They include: <3>audit(1116011400.312:0): avc: denied { associate } for name=rpm scontext=system_u:object_r:root_t tcontext=system_u:object_r:root_t tclass=filesystem <3>audit(1116038808.707:0): avc: denied { transition } for path=/usr/sbin/libgcc_post_upgrade dev=dm-0 ino=7209241 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:unconfined_t tclass=process <3>audit(1116038808.802:0): avc: denied { relabelto } for name=.bash_logout dev=dm-0 ino=6094852 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_t tclass=file <3>audit(1116038808.802:0): avc: denied { relabelto } for name=.bash_logout dev=dm-0 ino=6094852 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_t tclass=file <3>audit(1116038808.950:0): avc: denied { relabelto } for name=root dev=dm-0 ino=6094849 scontext=system_u:system_r:kernel_t tcontext=root:object_r:user_home_dir_t tclass=dir <3>audit(1116038867.944:0): avc: denied { transition } for path=/sbin/ldconfig dev=dm-0 ino=32145414 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:unconfined_t tclass=process Peter Jones replied to my thread on fedora-test-list with the comment that the path=/usr/sbin/libgcc_post_upgrade avc denied should have been fixed in time for FC4t3. Apparently not -- I definitely installed t3, as evidenced in the second attachment here, which shows that I installed fedora-release-3.92-1.x86_64.rpm.
Can you provide the complete dump you receieve?
See the attachments for a dump of /tmp/syslog early in the install process, and /proc/kmsg output for the remainder of the boot, up to and including the crash. If you want something else, please describe how I can get the info you need -- I don't know what else is available to report.
I guess I should ask how it's crashing -- is it a traceback or does it just say "install exited abnormally"?
What you see in the "crash at end" attachment is all the information available. After both anaconda instances crash as shown there (without traceback), init or whatever immediately goes through the shutdown process, starting it with "install exited abnormally" then shutting down X etc.
Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks.