[Spacewalk-list] Need help with registration problems.

Edward Drummond spacewalkList-iscool at snkmail.com
Mon Feb 4 16:27:58 UTC 2013


Well...

I'm not so sure your issue was with starting with DVDs/ISOs. I took your
advice and created a child channel, fedora16-x86_64-lost. I added it and
fedora16-x86_64-update and spacewalk18-client-fedora16-x86_64 to the file
and dropped my only key. What I found was packages being found now, but not
in every case. rhn-client-tools and rhn-setup are visible, but some of
their
dependencies are not. To get through the install, I had to use this package
list:

%packages
@ Base
rhn-client-tools
rhn-setup
m2crypto
python-gudev
python-dmidecode
%end

The last three packages being in fedora16-x86_64-lost. The
result is a registered client with no software or config
channel assignments. I hope adding the key back will address this.

Funny thing is the last three packages are not missing. They exist in
the parent channel. ""yum install  --downloadonly" never came
into play because I used the spacewalk interface to copy them from
the parent into the 'lost' channel.

So I never did use DVDs/ISOs for channel content. I repo-synced
everything across the network, as painful as that was. I got all
the packages needed to install, but some are visible and some
are not.

Odd. Why would this be?





On Thu, Jan 31, 2013 at 5:59 PM, Jon Miller
jonebird-at-gmail.com|spacewalkList-iscool|
<45ka6oedht at sneakemail.com> wrote:

> My challenge started with how I created my Distribution. I created my
> distribution from the 4G DVD which does not have all of the packages on it.
> The interesting part, which I didn't understand originally, is that when my
> client began it's kickstart it was reading the repodata that originally
> existed on the DVD and wasn't picking up on other packages that I might
> have uploaded to the main channel. As I mentioned before, by creating a
> separate child channel and selecting it within your kickstart profile, the
> client will then activate that channel as an available repo and be able to
> find the extra packages you need during the kickstart.
>
> My understanding regarding activation keys vs. channels specified in your
> kickstart is that once you activate the key, it will configure your client
> to use whatever channel repos you have designated. That will happen during
> the %post of your kickstart process, so you want to select the channels
> within your kickstart profile so that you can find those packages that are
> listed in your %packages section. For me, I plan to keep the selected
> channels in sync with both my activation key as well as my kickstart
> profile. So yes, it is a timing issue.
>
> -- Jon Miller
>
>
> On Thu, Jan 31, 2013 at 2:24 PM, Edward Drummond <
> spacewalkList-iscool at snkmail.com> wrote:
>
>>
>>
>> That's a very interesting idea and I will try it. The implication is
>> there are things needed during install that are not available in the
>> "proper" channels, such as:
>> fedora16-x86_64
>> fedora16-x86_64-updates
>> spacewalk18-client-fedora16-x86_64
>>
>> Is this true? Or is it the case that for me, the channels themselves
>> are not available?
>>
>> Also, to be clear, you suggest I put the children on the ks file
>> directly. Right now I have no child channels on the file, but I do
>> have them on an activation key on the ks file. Are you making a
>> distinction between these two things? The spacewalk interface
>> (I believe) says either of these schemes will work, but they are
>> mutually exclusive.
>>
>> Is it possible putting the child channels on a key creates a
>> timing issue? Is the client first registered, then activation
>> keys are applied?
>>
>>
>>
>>
>>
>> On Thu, Jan 31, 2013 at 4:18 PM, Jon Miller jonebird-at-gmail.com|spacewalkList-iscool|
>> <45ka6oedht at sneakemail.com> wrote:
>>
>>> I had to setup a child channel, populate it with packages I was missing,
>>> and then explicitly select it in your kickstart profile under Kickstart
>>> Details -> Operating System. If you have a working client, with good yum
>>> repos, you can try the command "yum install  --downloadonly
>>> --downloaddir=/tmp rhn-setup rhn-check" (and any others to that list) which
>>> will download not only those packages but also their dependencies. Finally,
>>> use "rhnpush" to upload those packages to the child channel. At that point
>>> you should be able to put those packages in your package list and have them
>>> successfully installed. Repeat the process for any other packages you need
>>> during install.
>>>
>>> -- Jon Miller
>>>
>>>
>>> On Thu, Jan 31, 2013 at 1:07 PM, Edward Drummond <
>>> spacewalkList-iscool at snkmail.com <spacewalkList-iscool at snkmail..com>>wrote:
>>>
>>>> I have tried this. If I make it:
>>>>
>>>> %packages
>>>> @ Base
>>>> rhn-setup
>>>> rhn-check
>>>>
>>>> %end
>>>>
>>>> the installer tells me these packages don't exist.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 31, 2013 at 11:47 AM, Jon Miller jonebird-at-gmail.com|spacewalkList-iscool|
>>>> <45ka6oedht at sneakemail.com> wrote:
>>>>
>>>>> I've seen a similar error during some of my initial kickstarts.. The
>>>>> error that sticks out to me is your:
>>>>>    /tmp/ks-script-QpNRzX: line 207: rhnreg_ks: command not found
>>>>>    /tmp/ks-script-QpNRzX: line 213: rhn_check: command not found
>>>>>
>>>>>  What I did was explicitly include "rhn-setup" and "rhn-check" in my
>>>>> packages list for my kickstart profile. Try including those packages and
>>>>> see if your registration works.
>>>>>
>>>>> -- Jon Miller
>>>>>
>>>>>
>>>>>  On Thu, Jan 31, 2013 at 8:14 AM, key 1 <
>>>>> spacewalkList-iscool at snkmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Can anyone help me. I'm new to spacewalk and a little bit stuck.......
>>>>>>
>>>>>>
>>>>>> I have installed spacewalk1.8-postgres on a f17 box. I have
>>>>>> repo-sync'ed
>>>>>> channels for fedora 16 & 17, as well as CentOS 5 & 6.. (all x86_64)..
>>>>>>
>>>>>> ...
>>>>>>
>>>>>
>>>> -snip
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130204/98a3dd31/attachment.htm>


More information about the Spacewalk-list mailing list