Bug 431392

Created attachment 293859 [details]
output of buildinstall with --debug and captured with &>

In my case, the command used was:

/usr/lib/anaconda-runtime/buildinstall --debug --product Fedora --variant
f8-i386-custom-local --version 8 --release "Fedora 8" --prodpath Packages
/var/tmp/revisor-pungi/8/f8-i386-custom-local/i386/os &>
anaconda-buildinstall.log

From the error messages, it appears that the problem lies somewhere in the loop
that starts at line 192 in upd-instroot.

1. Kinda confused: why are you using buildinstall directly.  Why not use pungi
for the whole process?
2. If your objective is to jack the udp-instroot, I suggest you come to the
rawhide code, lots of changed have been made to the udp-instroot and things
might be a little different this time around (f9)
3. From the logs I see that there some errors where buildinstall cannot create
simlinks from /tmp to wherever you have your tree,  I'm assuming that /tmp and
the directory where you have your tree are on different partitions.  Try to do
the sam process having the temp dir and the tree dir in the same device and see
what happens.

In any case the issues regarding upd-insroot are being addressed in f9, so Im
going to close the bug as rawhide.

This "solution" does not describe the actual cause of the message occuring,
could you be more specific?

Ok, lets needinfo it :) 
Now that you mention it, it might be another issue, (not the link one, of course
try it and see if it works.)  The message is caused by the upd-instroot doing
the dependency for the libraries for the initrd image (I'm pretty sure).  but
this does not cause the resulting tree to be invalid (AFAIK), its just the way
that the upd-instroot is build for f8.
Please provide info.
is the resulting tree valid?

In reply to comment #3 (1): I was using revisor, but the resulting DVD would not
operate properly (The boot menu loaded, but the installer never did.) Given
chroot errors were occurring during the isolinux build phase, I investigated
further. Initially, I thought that the problem was in revisor, so I added to Bug
429689 . After finding the revisor debug flag in vi, I was able to determine
that the errors were occurring during the buildinstall call. At that point I
decided to use buildinstall directly in an attempt to find the source of the
problem.

In reply to comment #3 (2): No, my goal is to create an operational custom
distribution DVD.

In reply to comment #5 : When using revisor, the installation rpm tree on the
DVD was fine. Since the installer does not load when booting from the resultant
DVD, I suspect that something is not installing properly in the boot image. As
the DVD booted, the tree is at least partially valid. Is there a good way to
check the validity of the tree?

In reply to comment #3 (3): Thanks for the thought. I will see what happens.

Created attachment 293968 [details]
second attempt, using idea from comment #3

I copied the f8-i386-custom-local directory (with cp -r) to /tmp and ran
buildinstall again. The command was:

/usr/lib/anaconda-runtime/buildinstall --debug --product Fedora --variant
f8-i386-custom-local --version 8 --release "Fedora 8" --prodpath Packages
/tmp/f8-i386-custom-local/i386/os &> anaconda-buildinstall.log

No chroot errors occurred this time through.

I tried pungi, and it seemed to build properly (it apparently works in /tmp).
The images seemed to be created properly from inspection via loopback, and the
resulting DVD booted. Now I seem to be down to some runtime errors:

1) The graphical installer does not load.
2) /usr/sbin/load_policy: can't load policy: no such file or directory
3) RuntimeError: Error running swapoff: No such file or directory

The anaconda rawhide code does seem to be significantly different, although it
is not exactly portable to Fedora 8 (I tried rebuilding the anaconda source rpm,
but there were dependency issues.) I am closer than I was in Fedora 7. Hopefully
Fedora 9 will resolve the runtime issues.

judging by the report this bug is not anaconda.  Buildinstall seem to be working
fine for the user when used directly.  It also seems to be working when used by
pungi.

You'll get the same error messages Joel, in pungi they occur as well, you just
don't see them.

Just commited a patch that /dev/nulls some error messages from find.  Hopefully
this fixes the sed messages strangeness and the chroot strangeness.