On Mon, 16 Apr 2007, John Summerfield wrote:
> Date: Mon, 16 Apr 2007 07:15:49 +0800
> From: John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx>
> Reply-To: CentOS mailing list <centos@xxxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: Scripts to generate exact copy of
> CentOS-5.0-i386-bin-DVD.iso from CD images
>
> Wojtek.Pilorz wrote:
> > On Sun, 15 Apr 2007, Akemi Yagi wrote:
> >
> >> Date: Sun, 15 Apr 2007 06:37:18 -0700
> >> From: Akemi Yagi <amyagi@xxxxxxxxx>
> >> Reply-To: CentOS mailing list <centos@xxxxxxxxxx>
> >> To: CentOS mailing list <centos@xxxxxxxxxx>
> >> Subject: Re: Scripts to generate exact copy of
> >> CentOS-5.0-i386-bin-DVD.iso from CD images
> >>
> >> On 4/14/07, Wojtek.Pilorz <wpilorz@xxxxxx> wrote:
> >>> I am enclosing scripts and config files to generate exact copy
> >>> of CentOS 5.0 i386 installation DVD image, that is
> >>> CentOS-5.0-i386-bin-DVD.iso
> >>> if you have CD images for i386.
> >> I have 2 questions:
> >>
> >> (1) There is one thing that is puzzling to me. You present an
> >> alternative method that makes use of the existing
> >> CentOS-5.0-i386-bin-DVD.iso file. In this case (if you already have
> >> it), what is the purpose of running the scripts?
> >
> > You prepare a DVD containing CD images and include scripts to generate DVD
> > image - so on one media you have, in a sense, both. Other than that, perhaps
> > not much reason.
> >
> >> (2) The scripts are specific for CentOS 5.0 as you described. What
> > The method I use is general. The scripts should be made more general,
> > indeed. That would require a bit of planning.
> >
> >> would it take to make them more generic?
> >> Is there any way to achieve
> >> the same without having to extract info from the original DVD?
> > Actually I did not have DVD image file. I had CD images on local fast mirror
> > which I could easily download.
> > I downloaded header of DVD image (part containing all directories definition)
> > and compared file length and timestamps.
> > With CentOS 5.0 it was easy - there were less than 50 files differing, most
> > of them needed to be downloaded (specific parts of DVD image).
> >
> > The file resulting from the tree had SHA1 and MD5 checksums as advertised on
> > CentOS mirrors, so I could use it further in the process.
> >
> > [
> > In case it did not match, I would use sha1 values for image segments from
> > bittorrent definition file to find out, where are the differences.
> >
> > I have scripts that help me with that, but the process is not easy, unless
> > one is fluent with perl or similar tool.
> > ]
> >
> > Once I have destination DVD image, the process is quite straighforward, it
> > amounts to finding what files should be placed where in the image. To find out
> > I run the script which compares SHA1 values for 2K-aligned 2K chunks of
> > destination image with SHA1 values of 2K chunks for files supposed to be in the
> > image.
> >
> > If anyone is interested in the tools I use, I can post then (all mine, all GPL).
> >
> >
> >> Akemi
> > Best regards,
> >
> > Wojtek
>
> Wojtek
>
> Debian's been using a similar system for years. Their current tool is
> called Jigdo-file, and requires special action by the CD/DVD authors. So
Yes, I was aware of jigdo.
> far as I know, Debian is the only project using Jigdo, though I do know
Recently fedora was asking opinions about jigdo. I voted for jigdo.
> at least one Linux magazine has used it.
>
> The Debian special action is to create two files, a .jigdo file and a
> .template. Together, they provide a similar function to the .bittorrent
> files so many authors do create.
>
> Jigdo uses the two files and some input from the user to download the
> files from one or more (hopefully, local) sites and reconstruct the images.
>
> It doesn't directly use an existing ISO image, but it can use its
> contents if it's mounted.
>
> Jigdo has some advantages:
> 1. I can choose a local download site, my side of the Internet
> connexion, where components of the required image can be found.
> 2. I can choose more, friendly to my IAP, download sites to get further
> packages to fill in for where the most local falls short.
>
> In contrast, bittorrent chooses its own download sites, and my IAP pays
> over and over for the same downloads, even if he has a local copy.
>
> 3. It uses standard download protocols, http and ftp, that uses ports
> most commonly open in firewalls and is practical for everyone.
>
> In contrast, bittorrent requires special firewall rules and one can't
> (and shouldn't) give everyone bittorrent access, even if they have http
> and ftp access to the Internet.
>
> Your use of the so-popular bittorrent images is a big advantage for your
Actually I use only bittorent definitionf file *.torrent;
I extract SHA1 values for regions of images - this allows me to find out
where the differences are. This is needed only if I do not have the image
I want to create. Perhaps I would have never tried that If had faster
network access.
> idea. Whether your use of existing ISO images is an advantage depends,
> but it's valuable that you can.
>
> Do you think you could discuss the matter with Richard Atterer, the
> Jigdo guru at Debian? Find whether Would it be possible to combine the
Sure,
> approaches, so that jigdo-lite (the downloader part) could use the
> bittorrent image? If the two approaches could be combined into the one
I tried jigdo a few years ago to recreate CD images I needed from files,
but at that time it was quite slow and size of files was non-optimal on my
data, so I created my own tool, which is not as ambitious as jigdo (just
one function - creating ISO 9660 images from files), but works quite fast
and reliably for me over last two years or so.
I have not tried jigdo since then.
> tool, it would be wonderful.
Good idea. I am open for discussion, sending code and what is needed to
achieve that goal.
>
> It would also ensure your new tool doesn't get lost.
>
>
> You can find jigdo-file from here:
> http://packages.debian.org/stable/utils/jigdo-file
>
>
Thank you,
Wojtek
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
