Bug 122506 - bad: chroot segfault
Summary: bad: chroot segfault
Status: CLOSED DUPLICATE of bug 121351
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-05 10:34 UTC by Mikko Huhtala
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 121351
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 19:03:00 UTC
Type: ---

Attachments (Terms of Use)
strace dump (2.35 KB, text/plain)
2004-05-05 11:52 UTC, Mikko Huhtala
no flags Details

Description Mikko Huhtala 2004-05-05 10:34:59 UTC
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):

How reproducible:

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.

Comment 1 Tim Waugh 2004-05-05 10:37:18 UTC
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'.

Comment 2 Mikko Huhtala 2004-05-05 11:00:06 UTC
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 ?? ()

Comment 3 Tim Waugh 2004-05-05 11:01:34 UTC
Please make sure you have the corresponding version of
coreutils-debuginfo installed -- if it is a different version than
coreutils it won't work.

Comment 4 Mikko Huhtala 2004-05-05 11:09:56 UTC
I have 

~ > rpm -q coreutils coreutils-debuginfo

These versions produce the gdb session posted above. I checked again.

Comment 5 Tim Waugh 2004-05-05 11:37:32 UTC
Strange; perhaps it's stack corruption (yikes!).

Can you try this?: strace chroot /root/system

Comment 6 Mikko Huhtala 2004-05-05 11:52:44 UTC
Created attachment 99987 [details]
strace dump

Comment 7 Mikko Huhtala 2004-05-05 11:55:50 UTC
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.

Comment 8 Tim Waugh 2004-05-05 12:14:13 UTC
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
--- 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

Comment 9 Mikko Huhtala 2004-05-05 12:41:54 UTC
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
--- 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.

Comment 10 Mikko Huhtala 2004-05-05 13:01:59 UTC
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.

Comment 11 Tim Waugh 2004-05-05 13:07:43 UTC
I remembered I have an FC1 installation on another disk, and I can
reproduce the segfault here.

Comment 12 Tim Waugh 2004-05-05 13:35:33 UTC
Does booting with 'vdso=0' on the kernel command line make the problem
go away for you?

Comment 13 Mikko Huhtala 2004-05-06 08:53:49 UTC
Yes. Chroot seems to work correctly with 'vdso=0'.

Comment 14 Tim Waugh 2004-05-06 09:02:27 UTC
Changing component.

Comment 15 Jakub Jelinek 2004-05-06 11:42:46 UTC
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.

Comment 16 Jakub Jelinek 2004-05-12 10:01:29 UTC

*** This bug has been marked as a duplicate of 121351 ***

Comment 17 Red Hat Bugzilla 2006-02-21 19:03:00 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.