Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: Chroot crashes with a segfault when trying to chroot to a FC1 partition from a FC2test3 system running from another partition. Version-Release number of selected component (if applicable): coreutils-5.2.1-6 How reproducible: Always Steps to Reproduce: 1. Mount a working Fedora Core 1 root partition on e.g. /root/system 2. chroot /root/system Actual Results: Chroot segfaults and the shell keeps using the initial root directory. Expected Results: Successful switch to the target chroot directory. Additional info: I have several root partitions on the hard drive. One contains a working FC1 installation and another a fully updated FC2 test installation that has been updated with yum from test2 release to test3 to the latest updates. I have chrooted from FC2 test to the FC1 root to e.g. run rpm queries and such on FC1. This worked with the initial FC2 test2, but chroot from coreutils-5.2.1-6 segfaults. Removing the policycoreutils RPM did not help and SELinux is disabled on the FC2 test system, so this does not seem to be a SELinux problem.
Can you get a stack trace? Install the coreutils-debuginfo package and run 'gdb --args chroot /root/system', then 'run' at the (gdb) prompt, and then 'bt'.
Here is the gdb session. Not very helpful; it looks like a dependency problem. I tried downgrading to coreutils-5.2.1-3 from test2, and I still got the segfault. I believe chroot did work after installation of test2, before additional upgrades. "chroot --help" does work in the updated test3 system with the latest coreutils, so at least the binary does something. ----------------------------- (gdb) run Starting program: /usr/sbin/chroot /root/system Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Program received signal SIGSEGV, Segmentation fault. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x00ba5600 in ?? () (gdb) bt #0 0x00ba5600 in ?? () #1 0x00000000 in ?? ()
Please make sure you have the corresponding version of coreutils-debuginfo installed -- if it is a different version than coreutils it won't work.
I have ~ > rpm -q coreutils coreutils-debuginfo coreutils-5.2.1-6 coreutils-debuginfo-5.2.1-6 These versions produce the gdb session posted above. I checked again.
Strange; perhaps it's stack corruption (yikes!). Can you try this?: strace chroot /root/system
Created attachment 99987 [details] strace dump
I attached the strace output. The problem seems to be a missing /etc/ld.so.preload. There is no such file on either partition (the running host or the chroot target). I need to confess my ignorance: I have no idea of what ld.so.preload is for.
chroot("/root/system") = 0 chdir("/") = 0 execve("/bin/bash", ["/bin/bash", "-i"], [/* 46 vars */]) = 0 uname({sys="Linux", node="urquell.abo.fi", ...}) = 0 brk(0) = 0x85bd000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ The point to note here is that the segfault happens *after* the execve -- this is bash segfaulting, not chroot. (Phew!) Perhaps try a different shell? Or try: chroot /root/system gdb --args /bin/bash
Tried first running /root/system/bin/bash, i.e. the FC1 bash binary on FC2. This seems to work just fine. (But the shell running in chroot is the host system (FC2) binary, right?) Then changed the login shell of root in the host system to tcsh and ran strace again. It still segfaults. . . . mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0xb56) = 0x2a642000 close(3) = 0 chroot("/root/system") = 0 chdir("/") = 0 execve("/bin/tcsh", ["/bin/tcsh", "-i"], [/* 53 vars */]) = 0 uname({sys="Linux", node="urquell.abo.fi", ...}) = 0 brk(0) = 0x8b83000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ It is the same for ksh, too. Can this be reproduced on another box? I'm starting to think that something has gone wrong on mine in the upgrade to test3 (and newer). Not that I think I have done anything strange, but in case the whole thing is just me, it might be a good to check on another system before spending more time.
I have an old Red Hat 9 root partition on the hard drive, too (in addition to FC1 and FC2). Had almost forgot about it. Surprise surprise, chrooting from FC2 to RH9 works (RH9 coreutils-4.5.3-19.0.2). The root shell was bash when I tested this. So the problem occurs only at chrooting from FC2 to FC1.
I remembered I have an FC1 installation on another disk, and I can reproduce the segfault here.
Does booting with 'vdso=0' on the kernel command line make the problem go away for you?
Yes. Chroot seems to work correctly with 'vdso=0'.
Changing component.
Well, this is not FC2 bug, but FC1 bug. There is nothing that can be done about that without upgrading FC1 glibc or passing vdso=0. I'll eventually build FC1 errata with glibc which among other things stops using vDSO altogether.
*** This bug has been marked as a duplicate of 121351 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.