On 22 March 2011 at 18:57 Hugh Brown <hbrown@xxxxxxxxxxxxxxx> wrote:
> On 03/22/2011 01:37 PM, Michael Mayer wrote:
> > Hi all,
> >
> > i have a weird issue with RHEL5.5 and kickstart.
> >
> > My current setup is:
> >
> > All RHEL5.5 RPMs(i.e. the whole tree) and two additional repositories
> > are in a subversion repo. The repo is accessible via http to the client
> > to be installed.
> > The client is a virtual machine hosted on an ESX server. I have modified
> > boot.iso as well to contain the kickstart file which points to the
> > subversion repo via the "url" and "repo" commands. The boot.iso (about
> > 10 MB in size) is attached to the virtual machine as a virtual CD-ROM.
> >
> > If the virtual server boots up, it reads the kickstart file and then
> > proceeds to download the second-stage installer from the repository. It
> > sets up networking, formats the disk as wanted, browses through the RPM
> > repos for dependency resolution. Once that is finished, the screen
> > appears where RPMs are going to be installed.
> >
> > So far so good.
> >
> > Now things are going odd: anaconda complains about packages being
> > corrupt, broken or missing. This cannot be true here because I have
> > checked md5sum of the rpm both in the repo and after downloaded via
> > wget. In the SVN server access logs the respective RPM is downloaded 10
> > times, each time with return code 200 which for me indicates successful
> > download. If I am looking on the kickstarting server, there are no RPMs
> > to be seen anywhere. If I run a wget on that kickstarted server with the
> > same URL the RPM is downloaded correctly. Depending on which repos I am
> > using in the kickstart file, a different RPM is thought to be corrupt.
> >
>
>
> This is most likely a problem with the filelists.xml.gz file in your yum
> repository. Each package gets stored with a pkgid that is hash of the
> package (the hash depends on the checksum employed by createrepo). If
> it is complaining about a package in one of your additional
> repositories, then I'd start by making sure that a
>
> createrepo --update /path/to/repo
>
> has been done recently (needs to be done after any new packages are added).
>
> If the repodata is current, then I've seen issues like this where the
> ram was going bad.
>
> On 03/22/2011 01:37 PM, Michael Mayer wrote:
> > Hi all,
> >
> > i have a weird issue with RHEL5.5 and kickstart.
> >
> > My current setup is:
> >
> > All RHEL5.5 RPMs(i.e. the whole tree) and two additional repositories
> > are in a subversion repo. The repo is accessible via http to the client
> > to be installed.
> > The client is a virtual machine hosted on an ESX server. I have modified
> > boot.iso as well to contain the kickstart file which points to the
> > subversion repo via the "url" and "repo" commands. The boot.iso (about
> > 10 MB in size) is attached to the virtual machine as a virtual CD-ROM.
> >
> > If the virtual server boots up, it reads the kickstart file and then
> > proceeds to download the second-stage installer from the repository. It
> > sets up networking, formats the disk as wanted, browses through the RPM
> > repos for dependency resolution. Once that is finished, the screen
> > appears where RPMs are going to be installed.
> >
> > So far so good.
> >
> > Now things are going odd: anaconda complains about packages being
> > corrupt, broken or missing. This cannot be true here because I have
> > checked md5sum of the rpm both in the repo and after downloaded via
> > wget. In the SVN server access logs the respective RPM is downloaded 10
> > times, each time with return code 200 which for me indicates successful
> > download. If I am looking on the kickstarting server, there are no RPMs
> > to be seen anywhere. If I run a wget on that kickstarted server with the
> > same URL the RPM is downloaded correctly. Depending on which repos I am
> > using in the kickstart file, a different RPM is thought to be corrupt.
> >
>
>
> This is most likely a problem with the filelists.xml.gz file in your yum
> repository. Each package gets stored with a pkgid that is hash of the
> package (the hash depends on the checksum employed by createrepo). If
> it is complaining about a package in one of your additional
> repositories, then I'd start by making sure that a
>
> createrepo --update /path/to/repo
>
> has been done recently (needs to be done after any new packages are added).
>
> If the repodata is current, then I've seen issues like this where the
> ram was going bad.
>
Done that, even recreated the repodata for the RHEL Server stuff as well (Server, VT, ...) keeping the group information But the situation is still pretty much the same.
Michael.
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
