Red Hat Bugzilla – Bug 1313676
no way in webUI how to switch to EUS channel if you have mistakenly switched to main channel
Last modified: 2016-03-03 02:59:25 EST
Description of problem:
There is no way in webUI how to switch to EUS base channel if you have mistakenly switched to main (X-stream) channel or to custom channel or to none channel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Register system redhat-release-server-6Server-126.96.36.199.el6.x86_64 with:
# rhnreg_ks --force --username=admin --password=nimda --use-eus-channel
2. Ensure you have e.g. these channels synced on your Satellite:
(note that in my testing it did not worked when synced with "--no-packages")
3. In Systems -> <system> -> Software -> Channels Channels -> Base Software
Channel it offers custom channels + "(none, disable service)" and 6.4.z,
6.6.z and 6 channels
4. Switch to some custom channel or to ...-6 channel or to "(none, disable
Now, no EUS channel is offered.
When we are in custom channel or "(none, disable service)", we should offer EUS channel (see Grant's note in bug 1282474 comment #15).
As a workaround you can just re-register with command stated above.
According to my knowledge the correct way to go from a custom to an EUS channel is over the default non-eus channel, so:
custom channel -> rhel-x86_64-server-6 -> rhel-x86_64-server-6.4.z
JanH, can you confirm, this scenario does not work?
Yeah, something definitely seems wrong here - I'll do some testing when I get in as well.
Actually, this Comment#1 scenario works for me in upstream.
(In reply to Tomas Lestach from comment #1)
> According to my knowledge the correct way to go from a custom to an EUS
> channel is over the default non-eus channel, so:
> custom channel -> rhel-x86_64-server-6 -> rhel-x86_64-server-6.4.z
> JanH, can you confirm, this scenario does not work?
Yep, that does not work for me as well :-/
The overall requirement for switching base-channels on an EUS-system is, "You can only move up". Up, in this case, is based on the redhat-release-server RPM on the client in question.
'none' and 'custom' only let you go to 'base-rhel' (because we have no idea what you might have done to them, so 'latest' is the assumption)
Once your base-channel has been switched to 'base-rhel', you can only be switched to the highest-level EUS channel available.
Switching to an EUS base-channel, lets you then switch to any EUS channel *greater than or equal to* that supported by your redhat-release-server RPM.
Once you update your redhat-release-server RPM, you're now a different EUS than you were before, and have a different choice of channels.
So, assume the following:
* Sat5 that has 6.4, 6.6, 6.7, and 6-base, and a custom channel.
* A client, '6_4', with redhat-release-server-6Server-188.8.131.52.el6
* A client, '6_6', with redhat-release-server-6Server-184.108.40.206.el6
6_4 should be able to switch from 6.4.0 to 6.6, 6.7, base, custom, and none
6_6 should be able to switch from 6.6.0 to 6.7, base, custom, and none
Either, switched to 'base-rhel', should only allow switching to 6.7
6_4, switched to 6.7, should then allow you to go to 6.4, 6.6, 6.7, or base-rhel
6_6, switched to 6.7, should then allow you to go to 6.6, 6.7, or base-rhel
All of this is the behavior I see on my test-system.
I won't ask if this 'makes sense', because it kind of doesn't, but it's the way it's been since EUS was invented in 2007. If this is what we're seeing, then this BZ should be closed as NOTABUG.
Ah, OK, you are absolutely right:
Satellite(@Oracle) with 5, 5.9.z, 6, 6.4.z, 6.6.z, 7, 7.1.eus and 7.2.eus.
Client with 5.9.z can move to 5 and from 5 to 5.9.z. When in "(none, disable service)" or in custom channel, only 5 is offered.
Client with 6.4.z can move to 6.6.z, then to 6, then to 6.6.z (but not from 6 to 6.4.z). When in "(none, disable service)" or in custom channel, only 6 is offered.
Client with 7.1.eus can move to 7.2.eus, then to 7 and then to 7.2.eus (but not from 7 to 7.1.eus). When in "(none, disable service)" or in custom channel, only 7 is offered.