Re: [Spacewalk-list] CentOS 6 Related Kickstart Problem in Spacewalk
> > Trevor,
> > once again my recipe:
> > Assemble the following files in a directory:
> >
> > jabberpy-0.5-0.21.el6.noarch.rpm
> > libxml2-2.7.6-8.el6_3.4.x86_64.rpm
> > osad-5.11.10-1.el6.noarch.rpm
> > pyOpenSSL-0.10-2.el6.x86_64.rpm
> > python-ethtool-0.6-2.el6.x86_64.rpm
> > python-gudev-147.1-4.el6_0.1.x86_64.rpm
> > python-hwdata-1.7.3-1.el6.noarch.rpm
> > rhncfg-5.10.36-1.el6.noarch.rpm
> > rhncfg-actions-5.10.36-1.el6.noarch.rpm
> > rhncfg-client-5.10.36-1.el6.noarch.rpm
> > rhncfg-management-5.10.36-1.el6.noarch.rpm
> > rhn-check-1.8.26-1.el6.noarch.rpm
> > rhn-client-tools-1.8.26-1.el6.noarch.rpm
> > rhn-custom-info-5.4.14-1.el6.noarch.rpm
> > rhnlib-2.5.55-1.el6.noarch.rpm
> > rhnmd-5.3.11-1.el6.noarch.rpm
> > rhnsd-5.0.4-1.el6.x86_64.rpm
> > rhn-setup-1.8.26-1.el6.noarch.rpm
> > rhn-setup-gnome-1.8.26-1.el6.noarch.rpm
> > rhn-virtualization-common-5.4.41-1.el6.noarch.rpm
> > rhn-virtualization-host-5.4.41-1.el6.noarch.rpm
> > spacewalk-abrt-0.0.1-1.el6.noarch.rpm
> > spacewalk-backend-libs-1.8.85-1.el6.noarch.rpm
> > spacewalk-certs-tools-1.8.4-1.el6.noarch.rpm
> > spacewalk-client-repo-1.8-4.el6.noarch.rpm
> > spacewalk-oscap-0.0.10-1.el6.noarch.rpm
> > yum-rhn-plugin-1.8.8-1.el6.noarch.rpm
> >
> >
> > Pack it into a tar-ball.
> > Place it in spacewalk-servers /var/www/html/pub
> >
> > and add the following to your kickstart:
> >
> > mkdir -p /tmp/rhn_rpms/optional
> > cd /tmp/rhn_rpms/optional
> > pushd /tmp/rhn_rpms/optional
> > wget http://[spacewalkserver]/pub/tarball.tar
> > tar -xf tarball.tar
> > yum localinstall -y --nogpg *.rpm
> >
> > $SNIPPET('spacewalk/redhat_register')
> >
> >
> >
> > And that should do the trick...
> > Best
> > -Jonathan
>
> Thanks for the reply! That workaround will definitely do the trick, but my
> question/concern
> is that Spacewalk is creating the section of the kickstart to install rpms
> from /tmp/rhn_rpms/optional
> by pulling the necessary packages from the Updates repo which it should not
> be doing. I do NOT have the
> Updates repo selected in the kickstart wizard, so no packages in the
> postscript section should be sourced
> from the Updates repo. The needed packages are available in the Base repo
> and should be sourced from
> there, but that is not what is happening. I can work around this problem,
> but I'd like to understand
> why it is happening to begin with and try to fix it cleanly.
>
> This is under Spacewalk 1.8 with a CentOS 6.3 repo set while using the
> Kickstart wizard in the web
> interface.
>
> Thanks for your help.
The problem I was having with kickstarted systems failing to register seems to
have stemmed
from a bad set of repodata that I needed to clean out. Systems are registering
properly on
kickstart now.
Thanks.
- Trevor T. Kates
> > On 02/13/2013 04:19 PM, Trevor T Kates wrote:
> > > I'm sorry for not including the replies in the text of my reply. I
> haven't
> > setup
> > > a good mailing list reader yet. I may not have been clear in my original
> > post, but
> > > the problem that I am having stems from the fact that the section of my
> > kickstart
> > > that automatically installs the rpms needed for rhnreg is pulling those
> > rpms from
> > > the updates channel of CentOS 6 even when I do not have the updates
> > channel selected
> > > in the body of the kickstart itself. This is causing the registration to
> > fail because
> > > the updated libxml2-python has a dependency on the updated libxml2 which
> > is not
> > > available before registration because the update channel is not
> available.
> > I tried
> > > to include the update channel and was met with the bug you mentioned
> > earlier, so it
> > > feels like a catch 22 situation and I'm not sure how to fix it.
> > >
> > >
> > > Trevor T. Kates
CONFIDENTIALITY NOTICE: This electronic message contains
information which may be legally confidential and/or privileged and
does not in any case represent a firm ENERGY COMMODITY bid or offer
relating thereto which binds the sender without an additional
express written confirmation to that effect. The information is
intended solely for the individual or entity named above and access
by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution, or use of the
contents of this information is prohibited and may be unlawful. If
you have received this electronic transmission in error, please
reply immediately to the sender that you have received the message
in error, and delete it. Thank you.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] CentOS 6 Related Kickstart Problem in Spacewalk
> Trevor,
> once again my recipe:
> Assemble the following files in a directory:
>
> jabberpy-0.5-0.21.el6.noarch.rpm
> libxml2-2.7.6-8.el6_3.4.x86_64.rpm
> osad-5.11.10-1.el6.noarch.rpm
> pyOpenSSL-0.10-2.el6.x86_64.rpm
> python-ethtool-0.6-2.el6.x86_64.rpm
> python-gudev-147.1-4.el6_0.1.x86_64.rpm
> python-hwdata-1.7.3-1.el6.noarch.rpm
> rhncfg-5.10.36-1.el6.noarch.rpm
> rhncfg-actions-5.10.36-1.el6.noarch.rpm
> rhncfg-client-5.10.36-1.el6.noarch.rpm
> rhncfg-management-5.10.36-1.el6.noarch.rpm
> rhn-check-1.8.26-1.el6.noarch.rpm
> rhn-client-tools-1.8.26-1.el6.noarch.rpm
> rhn-custom-info-5.4.14-1.el6.noarch.rpm
> rhnlib-2.5.55-1.el6.noarch.rpm
> rhnmd-5.3.11-1.el6.noarch.rpm
> rhnsd-5.0.4-1.el6.x86_64.rpm
> rhn-setup-1.8.26-1.el6.noarch.rpm
> rhn-setup-gnome-1.8.26-1.el6.noarch.rpm
> rhn-virtualization-common-5.4.41-1.el6.noarch.rpm
> rhn-virtualization-host-5.4.41-1.el6.noarch.rpm
> spacewalk-abrt-0.0.1-1.el6.noarch.rpm
> spacewalk-backend-libs-1.8.85-1.el6.noarch.rpm
> spacewalk-certs-tools-1.8.4-1.el6.noarch.rpm
> spacewalk-client-repo-1.8-4.el6.noarch.rpm
> spacewalk-oscap-0.0.10-1.el6.noarch.rpm
> yum-rhn-plugin-1.8.8-1.el6.noarch.rpm
>
>
> Pack it into a tar-ball.
> Place it in spacewalk-servers /var/www/html/pub
>
> and add the following to your kickstart:
>
> mkdir -p /tmp/rhn_rpms/optional
> cd /tmp/rhn_rpms/optional
> pushd /tmp/rhn_rpms/optional
> wget http://[spacewalkserver]/pub/tarball.tar
> tar -xf tarball.tar
> yum localinstall -y --nogpg *.rpm
>
> $SNIPPET('spacewalk/redhat_register')
>
>
>
> And that should do the trick...
> Best
> -Jonathan
Thanks for the reply! That workaround will definitely do the trick, but my
question/concern
is that Spacewalk is creating the section of the kickstart to install rpms from
/tmp/rhn_rpms/optional
by pulling the necessary packages from the Updates repo which it should not be
doing. I do NOT have the
Updates repo selected in the kickstart wizard, so no packages in the postscript
section should be sourced
from the Updates repo. The needed packages are available in the Base repo and
should be sourced from
there, but that is not what is happening. I can work around this problem, but
I'd like to understand
why it is happening to begin with and try to fix it cleanly.
This is under Spacewalk 1.8 with a CentOS 6.3 repo set while using the
Kickstart wizard in the web
interface.
Thanks for your help.
> On 02/13/2013 04:19 PM, Trevor T Kates wrote:
> > I'm sorry for not including the replies in the text of my reply. I haven't
> setup
> > a good mailing list reader yet. I may not have been clear in my original
> post, but
> > the problem that I am having stems from the fact that the section of my
> kickstart
> > that automatically installs the rpms needed for rhnreg is pulling those
> rpms from
> > the updates channel of CentOS 6 even when I do not have the updates
> channel selected
> > in the body of the kickstart itself. This is causing the registration to
> fail because
> > the updated libxml2-python has a dependency on the updated libxml2 which
> is not
> > available before registration because the update channel is not available.
> I tried
> > to include the update channel and was met with the bug you mentioned
> earlier, so it
> > feels like a catch 22 situation and I'm not sure how to fix it.
> >
> >
> > Trevor T. Kates
CONFIDENTIALITY NOTICE: This electronic message contains
information which may be legally confidential and/or privileged and
does not in any case represent a firm ENERGY COMMODITY bid or offer
relating thereto which binds the sender without an additional
express written confirmation to that effect. The information is
intended solely for the individual or entity named above and access
by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution, or use of the
contents of this information is prohibited and may be unlawful. If
you have received this electronic transmission in error, please
reply immediately to the sender that you have received the message
in error, and delete it. Thank you.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] tito build of spacewalk git sources
Thanks, I will try to follow the steps you mentioned. Now, for my new question: How do I go about building all the support files in the spec-tree directory? Do I need to download the files specified in the spec file and run tito? Where do I put the source files that I download? What is you method of doing this? Thanks, Andy On 02/12/2013 01:36 PM, Stephen Herr wrote: Hi Andy, Tito will always work with the most recent version in git. If you run with --test it is the most recent git commit, period. If you don't run with --test then it's the most recent version that has been tagged in git. Tito will never pick up changes that have not been committed yet, which yes can lead to difficulty when trying to fix build errors. The workflow I usually use when I have tito build problems is to 1) fix whatever I think needs to be changed, git commit. Then, before pushing the changes to my upstream repo (if any), try a 'tito build --rpm --test --offline'. If other errors are present or if the first fix didn't actually fix anything, then 2) continue fixing, git commit --amend This keeps all your fixes in that most recent commit. Then once everything is finally working again, you can push your single git commit upstream (if any). -Stephen On 02/12/2013 11:50 AM, genanr wrote: How does TITO work? I understand the tito build --rpm --test to build rpms, but my problem comes when I run into a problem with one of the files. In spacewalk/admin I ran tito build --rpm --test and pod2man complained about an missing =back in validate-sat-cert.pod. This is fine, and I added the =back before the =head at line 35. Then, when I re-run tito build --rpm --test, it still manages to find the error at the same line even though running pod2man on the file I get no errors. I can even delete the file and the tito command still gives me the same error. Where is it getting the file? In the good old day you wound run make, fix errors, run make and every would be fine. Tito seems to be pulling old files out of the air. There must be something I am missing, but I do not know what it is. Andy ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] CentOS 6 Related Kickstart Problem in Spacewalk
I'm sorry for not including the replies in the text of my reply. I haven't setup a good mailing list reader yet. I may not have been clear in my original post, but the problem that I am having stems from the fact that the section of my kickstart that automatically installs the rpms needed for rhnreg is pulling those rpms from the updates channel of CentOS 6 even when I do not have the updates channel selected in the body of the kickstart itself. This is causing the registration to fail because the updated libxml2-python has a dependency on the updated libxml2 which is not available before registration because the update channel is not available. I tried to include the update channel and was met with the bug you mentioned earlier, so it feels like a catch 22 situation and I'm not sure how to fix it. Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
