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.
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...
We pass ramdisk_size=40000 in generic.prm. /me shrugs
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
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.
There wasn't /lib at all in the s390x initrd for rhel4. This feels like something changing in the kernel. Needs some more digging
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]
/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. See: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02438.html http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02446.html 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 -> /lib64/ld64.so.1 lrwxrwxrwx 1 root root 12 Jun 1 04:15 /lib64/ld64.so.1 -> ld-2.4.90.so
*sigh* Okay. Added to scripts/mk-images