I've narrowed it down quite a bit.  It's a problem with ramdisk 
corruption on some 2.4 kernels, not specifically initrd, and 
definitely not a problem with booting initrd.  
executive summary:
  dd'ing from /dev/ram0 usually produces a corrupted ramdisk
  image.
This is reproducible on:
 2.4.12 
 2.4.16 
 2.4.17-pre2 + low-latency patch + custom tweaks 
However, I cannot reproduce the problem on:
 2.4.8-26mdk  (default Mandrake 8.1 kernel)
 2.4.9 
On 2.4.10, I can't do the test, seems like ramdisk was *really*
broken on that kernel.  (no room on ramdisk after mke2fs???)
I now have a simple script that checks for the problem and was 
tried on each of the kernels listed above:
---------------------------------------------------
#!/bin/bash
umount /dev/ram0
./rootfs/bin/busybox freeramdisk /dev/ram0
mke2fs -m0 /dev/ram0 4000
mount -t ext2 /dev/ram0 /mnt/ramdisk
cp -a rootfs/* /mnt/ramdisk
umount /dev/ram0
dd if=/dev/ram0 of=initrd bs=1k count=4000 
dd if=initrd of=/dev/ram0 bs=1k count=4000 
mount -t ext2 /dev/ram0 /mnt/ramdisk
diff -q -r /mnt/ramdisk/bin ./rootfs/bin
diff -q -r /mnt/ramdisk/lib ./rootfs/lib
---------------------------------------------------
On kernels with the problem, the scripted diff reports that most 
(or all?) the binaries and libraries are corrupt.  This contradicts 
my earlier problem report, sorry about that. 
I'm eager to help track this down, I can test patches, supply 
more information, give you a tar.gz of the contents of my rootfs,
or do whatever it takes.   In the meantime I've gone back to 
the default Mandrake 2.4.8 kernel.  It's noticably slower. :-(
A few loose ends...
Erik Andersen wrote:
> Any particular reason you are using a version of busybox that is 
> quite old?  You really should get a newer release -- I've fixed a 
> lot of bugs since then.
Yes, that is one of the reasons I'm working on this again - I'm 
updating my old initrd with the new kernel and the latest versions 
of all the tools I'm using, including busybox.  BTW, thanks 
for your work on busybox, it's great.
[...]
> Can you sucessfully chroot into your rootfs dir?
Good suggestion, that helped set me on the right track to finding
the problem.  I can chroot into my rootfs "source" directory, but 
(unsurprisingly) attempting to chroot to a corrupted image segfaults,
that's how I discovered the corruption, not sure how I missed it 
before.  I'll blame it on Friday afternoon confusion.
Torrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/