[mirror-admin] ERROR: chroot failed for fedora-web

[Carlos Carvalho]

Jesse Keating (jkeating at redhat.com) wrote on 15 January 2009 16:34:
 >On Tue, 2009-01-13 at 23:54 -0200, Carlos Carvalho wrote:
 >>  >We're generating something that rsync can consume directly, rather
 >>  >than building up some other infrastructure around it.
 >> 
 >> What do you mean by "rsync can consume"? Using the filelist generated
 >> by rsync has the info
 >
 >erm, I mean exactly what I say. It appears that rsync --files-from
 >can only consume a file that has paths, either null or newline
 >terminated. No other information.

Correct.

 >So again, I'm not sure what value you're getting from using rsync vs
 >find to generate the filelist.
 
What are we mirrors supposed to do with it? Do you want us to just
feed fullfilelist to --files-from? That's useless because the disk
scavenging will continue to happen on both ends. Should we diff from
the previous version and just give the differences to --files-from?
This doesn't work because files with the same name may have changed.
Since they won't be given to rsync we'll end up with a broken mirror.

This simple list of just file names just increases the size of the
archive and doesn't help mirroring.

You can use find or even ls (with appropriate options) to generate the
list. The important point is that it *must* have enough info for us to
decide if we have to give the name to rsync or not so that we only ask
you to check files that really should be checked, thus avoiding disk
scanning on both ends. There are several ways to do it; one of them is
to check for the n-tuple (permissions,size,timestamp), which is what
rsync does btw. Another one is to use checksums.

Once we have enough info in that file our scripts can determine what
must be given in --files-from. As I said in another post, we already
do it, even using a ls-lR awful list (for other distros). The script
is not a one-liner though.

 >That's correct.  verifytree, which is in yum-utils, does not need to
 >open the rpms themselves.  There is a .treeinfo file in most trees that
 >points to where the repodata is and what the checksum of the repodata
 >should be.  The repodata itself contains checksums of all the individual
 >rpms.  So as long as you can trust and verify .treeinfo, you should have
 >a path of verification down to the individual rpms

Interesting.

 >but in release trees inclusive of the install images and kernel
 >images, and the iso files.

I didn't understand this part. There are only 3 .treeinfo in the whole
archive now, all in development. How can releases and updates be checked?

--