Strangely, I ripped out the PCMCIA section of the build, and it seems to
have successfully built the images I need. Fingers crossed now to see
if it really made a bootable installation image...
Joe Cooper wrote:
Hi folks,
I've been attempting to create a new bootnet.img with the latest
kernel-BOOT RPM to fix the problem of some recent Promise FastTrack
controllers not working with the install, but unfortunately, the
buildinstall script isn't quite finishing its job, and I'm not sure why
or how to fix it.
All of the images are successfully written (including bootnet.img), but
it errors out before generating the other stage img files for the base
directory. I get the following:
mke2fs 1.27 (8-Mar-2002)
Wrote /tmp/makebootdisk.tree.20568 (2016k compressed, 1444k free)
cp: writing `/tmp/makebootdisk.tree.20568/vmlinuz': No space left on device
sed: Couldn't close {standard output}
sed: couldn't write 71 items to {standard output}: No space left on device
sed: Couldn't close {standard output}
sed: Couldn't close {standard output}
sed: Couldn't close {standard output}
/distro/7.3/buildinstall.tree.15638/mk-images: Failed to copy messages
from /distro/7.3/RedHat/instimage/usr/lib/anaconda-runtime/boot/ to
/tmp/makebootdisk.tree.20568.
Note this is after all of the normal images have been generated...and I
can't even tell what it is trying to generate at the point where the
error occurs. Now I know what could cause the standard disk img files
(boot.img, bootnet.img, etc.) to be too large, and I've tried to reduce
the number of drivers going in to see if this might be impacted, but it
makes no difference. Anyway, shouldn't these secondary images be
allowed to be as large as they need to be?
Anyone have any pointers on how to debug and/or fix this? I'm kind of
stumped at this point...
Thanks!
--
Joe Cooper <joe@xxxxxxxxxxxxx>
Web caching appliances and support.
http://www.swelltech.com
