Bug 144688 - cpio fails to unpack initrd on ppc
cpio fails to unpack initrd on ppc
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cpio (Show other bugs)
rawhide
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-10 12:53 EST by Ralf Ertzinger
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-14 09:00:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to disk_buffered_write (1.17 KB, patch)
2005-01-13 08:04 EST, Ralf Ertzinger
no flags Details | Diff
new lfs patch (5.17 KB, text/plain)
2005-01-14 08:58 EST, Peter Vrabec
no flags Details

  None (edit)
Description Ralf Ertzinger 2005-01-10 12:53:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
Unpacking the initrd file on my ppc machine fails to unpack files,
directories are created ok, files are created, but have all zero size:

[sun@lain ~/temp (0) 5]$ gunzip -c /boot/initrd-2.6.9-1.1047_FC4.img |
cpio -id
cpio: dev/null: Operation not permitted
cpio: dev/tty4: Operation not permitted
cpio: dev/tty2: Operation not permitted
cpio: dev/tty1: Operation not permitted
cpio: dev/ram: Operation not permitted
cpio: dev/systty: Operation not permitted
cpio: dev/tty3: Operation not permitted
cpio: dev/console: Operation not permitted
3617 blocks
[sun@lain ~/temp (1) 6]$ find -type f -exec ls -l {} \;
-rwxr-xr-x  1 sun users 0 Jan 10 18:50 ./bin/udev
-rwxr-xr-x  1 sun users 0 Jan 10 18:50 ./bin/insmod
-rwxr-xr-x  1 sun users 0 Jan 10 18:50 ./bin/nash
-rw-r--r--  1 sun users 0 Jan 10 18:50 ./etc/udev/udev.conf
-rw-r--r--  1 sun users 0 Jan 10 18:50 ./lib/jbd.ko
-rw-r--r--  1 sun users 0 Jan 10 18:50 ./lib/ext3.ko
-rwxr-xr-x  1 sun users 0 Jan 10 18:50 ./init


The initrd files themselves are OK, the machine boots just fine with
them. The same command works as expected on i386 machines.

Version-Release number of selected component (if applicable):
cpio-2.5-10

How reproducible:
Always

Steps to Reproduce:
1. Try to extract an initrd file on ppc
2.
3.
    

Actual Results:  All extracted files have zero size

Expected Results:  Normal file extraction

Additional info:
Comment 1 Peter Vrabec 2005-01-12 09:05:41 EST
[root@sizzler temp]# gunzip -c initrd-2.6.9-1.906_EL.img | ./cpio -id
5657 blocks
[root@sizzler temp]# find -type f -exec ls -l {} \;
-rwxr-xr-x  1 root root 1251 Jan 12 08:49 ./init
-rw-r--r--  1 root root 1202580 Jan 12 08:35 ./initrd-2.6.9-1.906_EL.img
-rw-r--r--  1 root root 302992 Jan 12 08:49 ./lib/lpfc.ko
-rw-r--r--  1 root root 268240 Jan 12 08:49 ./lib/scsi_mod.ko
-rw-r--r--  1 root root 264456 Jan 12 08:49 ./lib/ext3.ko
-rw-r--r--  1 root root 148112 Jan 12 08:49 ./lib/jbd.ko
-rw-r--r--  1 root root 160056 Jan 12 08:49 ./lib/sym53c8xx.ko
-rw-r--r--  1 root root 41600 Jan 12 08:49 ./lib/sd_mod.ko
-rw-r--r--  1 root root 41680 Jan 12 08:49 ./lib/scsi_transport_spi.ko
-rw-r--r--  1 root root 24984 Jan 12 08:49 ./lib/xor.ko
-rw-r--r--  1 root root 50912 Jan 12 08:49 ./lib/raid5.ko
-rw-r--r--  1 root root 28512 Jan 12 08:49 ./lib/scsi_transport_fc.ko
-rw-r--r--  1 root root 1129 Jan 12 08:49 ./etc/udev/udev.conf
-rwxr-xr-x  1 root root 426016 Jan 12 08:49 ./bin/insmod
-rwxr-xr-x  1 root root 483380 Jan 12 08:49 ./bin/nash
-rwxr-xr-x  1 root root 648120 Jan 12 08:49 ./bin/udev
-rwxr-xr-x  1 root root 139013 Jan 12 08:43 ./cpio
[root@sizzler temp]# uname -a
Linux sizzler.build.redhat.com 2.6.9-1.906_EL #1 SMP Sun Dec 12
22:54:40 EST 2004 ppc ppc ppc GNU/Linux
                           
Version-Release number of cpio
cpio-2.5-10

Same result with ppc64
Comment 2 Ralf Ertzinger 2005-01-12 10:17:07 EST
I played around with gdb a little, and I think I found the reason for
the misbehaviour I am seeing, although it totally puzzles me:

(gdb) run -id < initrd
Starting program: /bin/cpio -id < initrd

Breakpoint 5, copy_files_tape_to_disk (in_des=0, out_des=8,
num_bytes=warning: Unhandled dwarf expresion opcode DW_OP_piece
639964) at util.c:459
459           disk_buffered_write (in_buff, out_des, size);
(gdb) print size
warning: Unhandled dwarf expresion opcode DW_OP_piece
warning: Unhandled dwarf expresion opcode DW_OP_piece
$5 = 164
(gdb) c
Continuing.

Breakpoint 6, disk_buffered_write (in_buf=0x9c338 <Address 0x9c338 out
of bounds>, out_des=8, num_bytes=0) at util.c:276
276     {
(gdb) where
#0  disk_buffered_write (in_buf=0x9c338 <Address 0x9c338 out of
bounds>, out_des=8, num_bytes=0) at util.c:276
#1  0x10009920 in copy_files_tape_to_disk (in_des=0, out_des=8,
num_bytes=warning: Unhandled dwarf expresion opcode DW_OP_piece
639800) at util.c:459
#2  0x100022d4 in copyin_regular_file (file_hdr=0x7ffff650,
in_file_des=0) at copyin.c:961
#3  0x10003208 in process_copy_in () at copyin.c:768
#4  0x10006dd8 in main (argc=2, argv=0x7ffffa74) at main.c:533
#5  0x0fe9b840 in generic_start_main () from /lib/tls/libc.so.6
#6  0x0fe9b988 in __libc_start_main () from /lib/tls/libc.so.6
#7  0x00000000 in ?? ()



As you can see, disk_buffered_write() is called from
copyin_regular_file() to write out "size" bytes to disk (breakpoint 5)
"size" in the context of copyin_regular_file is 164. But in the actual
function call (breakpoint 6), "num_bytes" suddenly is 0, so nothing is
being written to disk.

I am quite out of my waters here. Is this a compiler bug?
Comment 3 Peter Vrabec 2005-01-13 04:39:39 EST
[root@sizzler /]# gcc --version
gcc (GCC) 3.4.3 20050104 (Red Hat 3.4.3-13)
Comment 4 Ralf Ertzinger 2005-01-13 08:02:28 EST
OK, I think I've got it.

copy_files_tape_to_disk [util.c] calls disk_buffered_write(in_buff,
out_des, size) [util.c:459]. In this context, size is an off_t, which
resolves to a long long int.

disk_buffered_write (in_buf, out_des, num_bytes) [util.c:272] defines
num_bytes as a long. Depending on whether the compiler chooses to pass
arguments via the stack or via registers, the endianess of the machine
and the phase of the moon, this breaks. I think it works on ix86,
because parameters are passed on the stack, and the memory layout is
right, and it works on your machines because they have 64-bit
registers (unless I am seroiusly mistaken). My machine is a G3,
without large registers.

I've built a small patch, replacing long by off_t in
disk_buffered_write for at the appropriate places, and suddenly
unpacking works.

I think there are more places where this happens, the code is a mess.

I'll attach the patch, it also adds some printf()s I added for debugging.
Comment 5 Ralf Ertzinger 2005-01-13 08:04:45 EST
Created attachment 109712 [details]
patch to disk_buffered_write
Comment 6 Peter Vrabec 2005-01-14 08:55:51 EST
Thx. for your patch. 

I integrate your patch and cpio-2.5-lfs.patch into new
cpio-2.6-lfs.patch, also I fixed other places where this happens. Hope
it will work fine.
Comment 7 Peter Vrabec 2005-01-14 08:58:35 EST
Created attachment 109776 [details]
new lfs patch
Comment 8 Josh Bressers 2005-02-18 10:28:37 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-080.html

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