Red Hat Bugzilla – Bug 145225
[PATCH] cpio does not pack symlinks properly
Last modified: 2007-11-30 17:10:58 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: cpio automatically dereferences symlinks while packing (as if the option -L was passed, although it is not: [sun@nausicaa ~/initrd :) 50]$ gunzip -c /boot/initrd-2.6.10-1.1087_FC4.img | cpio -id cpio: dev/systty: Operation not permitted cpio: dev/console: Operation not permitted cpio: dev/ram: Operation not permitted cpio: dev/tty4: Operation not permitted cpio: dev/null: Operation not permitted cpio: dev/tty2: Operation not permitted cpio: dev/tty3: Operation not permitted cpio: dev/tty1: Operation not permitted 3798 blocks [sun@nausicaa ~/initrd :) 51]$ find -type l ./bin/hotplug ./bin/modprobe ./bin/udevstart ./sbin [sun@nausicaa ~/initrd :) 52]$ find . | cpio -c -o > ../initrd.img 6456 blocks [sun@nausicaa ~/initrd :) 53]$ rm -rf * [sun@nausicaa ~/initrd :) 54]$ cpio -id < ../initrd.img 6456 blocks [sun@nausicaa ~/initrd :) 55]$ find -type l [sun@nausicaa ~/initrd :) 56]$ As can be seen, the symlinks are being dereferenced while packing. Version-Release number of selected component (if applicable): cpio-2.6-2 How reproducible: Always Steps to Reproduce: 1. Pack a file structure with symlinks (without -L) 2. Unpack it 3. Actual Results: Symlinks are being dereferenced Expected Results: No dereferencing unless requested Additional info:
Backing up to cpio-2.5-9 works around this problem...sigh
The effect is even bigger when you pack/unpack (mkinitd) the kernel. Since the symlinks are not created you end with a empty /sbin for the initrd image and bunch of error messages during boot. Going back to 2.5-9 solves the problem too.
Dang, what a pain this was to track down. I'm no expert with autotools, but if you're using HAVE_* #define's, don't those have to be generated by your configure script and set in config.h or something like that? Take a look at lib/system.h and you'll see a '#define lstat stat' line that's wrapped with a '#if !HAVE_LSTAT ...' block, but I can't see anywhere in the entire source tree where lstat is actually being checked for and HAVE_LSTAT subsequently being set. This code didn't exist in cpio-2.5. Frankly, this looks like half finished code. Not sure what the best fix is other than just deleting that '#if' block altogether (I tried it and it does work, at least for i386).
Please look at: http://lists.gnu.org/archive/html/bug-cpio/2005-01/msg00003.html The bug has been fixed upstream.
Created attachment 109859 [details] My patch. Could not find that one from upstream