My new script makes use of genext2fs instead, which does make consistent ramdisk images, so I am grateful for that. The previous script was a result of reading another guide to ramdisk generation, when the DULG was really the best bet from the beginning.
I believed before that the inconsistent ramdisk were causing my underlying problem, but even now with consistent sized images, my problem is when using a stripped down version of our development environment, I have a ramdisk image that works. However, whenever I add any kind of file to the ramdisk image, it breaks userspace. An example would be one test I ran, where all I did was add a small text file to the root directory, and suddenly busybox would go into an infinite loop of restarting the shell. This happens with pretty much any addition of data to the ramdisk (another executable being added in, etc..) Also, a program that is set in the inittab to automatically restart, either goes into an infinite loop of starting and restarting, or when it starts, it starts with a "zombie" status, which I believe means that init is no longer communicating with it. So these errors seem to indicate a problem with init, but I have not been able to pinpoint the exact cause. And while not a big deal, whenever a command is input through the serial console, it is echoed again before it is executed. I have CONFIG_BLK_DEV_RAM_SIZE = 32768, and the uncompressed image definitely fits within this size. If this is not a common error, or something that has been seen before, I could at least use a good suggestion on how I could go about debugging this. I'm not sure a kernel debugger would be appropriate if these problems are occuring because of init, or something else in userspace. Thanks CT -----Original Message----- From: Andrew May [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 11:25 AM To: Clint Thomas Subject: Re: Inconsistent ramdisk generation Clint Thomas wrote: > this behaviour. Just to be sure it was not my script, I added time > delays between the commands, just to be sure all the IO was finished > before any of the compression began, but that did not change anything > either. Any suggestions? I don't think time delays are enough. Try a full umount before doing the compress. But you should really try this instead. http://genext2fs.sourceforge.net/ _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
