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:
[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
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?
[root@sizzler /]# gcc --version gcc (GCC) 3.4.3 20050104 (Red Hat 3.4.3-13)
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.
Created attachment 109712 [details] patch to disk_buffered_write
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.
Created attachment 109776 [details] new lfs patch
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