Bug 192862 - fail to exec /init ?
fail to exec /init ?
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
s390x Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-05-23 13:38 EDT by David Cantrell
Modified: 2007-11-30 17:11 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-05 12:18:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Cantrell 2006-05-23 13:38:01 EDT
Kernel panic booting initrd.img and kernel.img from rawhide on s390x.  Here is
the panic I see on today's rawhide:

Failed to execute /init
translation exception: 0012  #1!
CPU:    0    Not tainted
Process swapper (pid: 1, task: 000000000155f6e8, ksp: 00000000015638e0)
Krnl PSW : 0704b00180000000 000000000014f604 (__strncpy_from_user_asm+0x14/0x60)

Krnl GPRS: 0000000000000000 00000000000104b1 00000000000114b1 000000000157e000
           00000000000104b1 0000000000224000 0000000000000000 000000000000002c
           000000000001d5d2 0000000001560000 000000000157e000 00000000000104b1
           0000000000001000 000000000022a5c8 00000000000a711a 0000000001563c98
Krnl Code: a7 14 ff fe b2 79 00 00 b9 04 00 12 a7 24 00 04 a7 1b 00 01
Call Trace:
( <00000000000a7108>! getname+0x104/0x184)
  <00000000000173c6>! sys_execve+0x32/0xbc
  <000000000001d5e0>! sys_execve_glue+0xe/0x1a
  <0000000000012190>! run_init_process+0x20/0x38
( <00000000000124dc>! init+0x334/0x3a0)
  <00000000000171e2>! kernel_thread_starter+0x6/0xc
  <00000000000171dc>! kernel_thread_starter+0x0/0xc

 <0>Kernel panic - not syncing: Attempted to kill init
0000000000000000 00000000015638f0 0000000000000002 0000000000000000
       0000000001563990 0000000001563908 0000000001563908 0000000000034d3a
       00000000002380e8 0000000000000000 000000000000002c 000000000000000b
       0000000000000008 0000000000000000 00000000015638f0 0000000001563968
       0000000000225e88 000000000001588a 00000000015638f0 0000000001563938
Call Trace:
( <0000000000000000>! _stext+0xfffffffffffedf3a/0xaa)

The initrd.img for s390x has /init (symlink to /sbin/init) and it has
/sbin/init.  /sbin/init is a shell script on s390x and we have /bin/sh linked to
/bin/bash and all of those components are there.

Rebooting with init=/bin/bash fails as well.  Not convinced this is a kernel
problem, but I'll start here.
Comment 1 Jeremy Katz 2006-05-23 14:53:34 EDT
The weird thing is that rebooting with init=/bin/bash still fails with unable to
execute /init.  So there's something going wonky there.  I wonder if it's
related to the significantly larger initrd we have now...
Comment 2 David Cantrell 2006-05-23 16:19:59 EDT
We pass ramdisk_size=40000 in generic.prm.

/me shrugs
Comment 3 Jeremy Katz 2006-05-23 16:32:09 EDT
Yeah, but ramdisk_size only applies for ramdisks and with an initramfs, we're
not really using a ramdisk.  I've tried not passing it at all as well as a
significantly larger value.

By the larger initrd being a problem, I mean that I wonder if z/vm is unable to
handle an initrd as large as the one we're using
Comment 4 Karsten Hopp 2006-05-24 06:22:24 EDT
problem: ld64.so.1 needs to be in /lib, not in /lib64. I'm not sure if we had a
directory /lib in previous versions or a symlink to /lib64 but that should be easy
to find out. 
A fixed initrd.img for /mnt/redhat/rel-eng/RHEL5-re20060502.3/s390x-global is
available on porkchop:/tmp until tmpwatch or someone else deletes it.

I'll reassign this to the anaconda team as this isn't a kernel bug.
Comment 5 Jeremy Katz 2006-05-25 14:00:50 EDT
There wasn't /lib at all in the s390x initrd for rhel4.  This feels like
something changing in the kernel.  Needs some more digging
Comment 6 Jeremy Katz 2006-06-04 18:43:19 EDT
In fact, looks like something has changed in the toolchain.  From readelf -a of
a RHEL4 /bin/bash --
  INTERP         0x0000000000000200 0x0000000080000200 0x0000000080000200
                 0x0000000000000011 0x0000000000000011  R      1
      [Requesting program interpreter: /lib64/ld64.so.1]

Doing the same on current /bin/bash
  INTERP         0x0000000000000200 0x0000000080000200 0x0000000080000200
                 0x000000000000000f 0x000000000000000f  R      1
      [Requesting program interpreter: /lib/ld64.so.1]

Comment 7 Jakub Jelinek 2006-06-05 04:14:05 EDT
/lib/ld64.so.1 is unfortunately still the official s390x ld.so location.
I have been patching that out for years, but as upstream never liked that change,
I think it is better to follow what upstream does and have /lib/ld64.so.1 ->
/lib64/ld64.so.1 symlink.
The symlink is included in glibc package:
rpm -qplv
/mnt/redhat/beehive/comps/dist/fc6/glibc/2.4.90-11/s390x/glibc-2.4.90-11.s390x.rpm | grep ld64.so.1
lrwxrwxrwx    1 root    root               16 Jun  1 04:19 /lib/ld64.so.1 ->
lrwxrwxrwx    1 root    root               12 Jun  1 04:15 /lib64/ld64.so.1 ->
Comment 8 Jeremy Katz 2006-06-05 12:18:25 EDT
*sigh*  Okay.  Added to scripts/mk-images

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