Bug 121351 - chroot to FC1 root filesystem crashes
chroot to FC1 root filesystem crashes
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
: 122506 127146 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-20 13:31 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 12:36:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-04-20 13:31:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
I keep installs of FC1 and FC2test in separate root filesystems, and I
arrange for each one to mount the other in /l/root, such that I can
chroot to it and install updates, which I do pretty much every day.

As of 2-3 days ago (kernel-2.6.5-1.322?), chroot has stopped working:
I just get a segmentation fault.  Tried with selinux in permissive
mode, as well as disabled with selinux=0.

Running /l/root/bin/bash works, but after setting
LD_LIBRARY_PATH=/l/root/lib, it crashes just the same.

Heck, running /l/root/lib/ld-linux.so.2 works, but passing it
/l/root/bin/bash crashes, with or without --list; --verify appears to
work.  LD_ASSUME_KERNEL had no effect.

Since nothing relevant changed in the FC1 tree, I can only guess it is
something in the running kernel.

Version-Release number of selected component (if applicable):
kernel-2.6.5-1.332

How reproducible:
Always

Steps to Reproduce:
1.strace -f chroot FC1's root

Actual Results:  [...]
chroot("/l/root")                       = 0
chdir("/")                              = 0
execve("/bin/bash", ["/bin/bash", "-i"], [/* 28 vars */]) = 0
uname({sys="Linux", node="libero", ...}) = 0
brk(0)                                  = 0x81fc000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xf70ef000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---


Expected Results:  root#

Additional info:

The crash happens before the old_mmap call in the 2.6.5-1.327.
Comment 1 Alexandre Oliva 2004-04-20 13:37:50 EDT
arjan says this is a bug in FC1's glibc.  Booting the devel kernel
with vdso=0 should work around the bug.

This seems to imply the FC devel kernel needs vsdo=0 to work when
installed on an FC1 system.
Comment 2 Jakub Jelinek 2004-05-12 06:01:32 EDT
*** Bug 122506 has been marked as a duplicate of this bug. ***
Comment 3 Tim Waugh 2004-07-02 16:42:56 EDT
*** Bug 127146 has been marked as a duplicate of this bug. ***
Comment 4 Tim Waugh 2004-07-03 05:39:16 EDT
*** Bug 127146 has been marked as a duplicate of this bug. ***
Comment 5 Ulrich Drepper 2004-09-30 06:55:05 EDT
I assume the code from rawhide works?
Comment 6 Alexandre Oliva 2004-09-30 12:36:53 EDT
Yup, vdso works in rawhide and FC2.  You still can't chroot to a FC1
tree because FC1's glibc is broken, but since FC1 is EOLed, I guess we
can close/wontfix this one.
Comment 7 Paul Howarth 2005-08-15 08:50:08 EDT
Is there any chance that you might at least indicate how FC1's glibc might be
fixed? It would be nice to be able to build legacy packages using mock
(http://fedoraproject.org/wiki/Legacy/Mock) but currently it's not possible to
do this without vdso=0. mock seems to work fine for other releases as far back
as at least RH7.3.

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