I’ve always had this nagging question on my SLES 11 SP4 servers that have been upgraded over the years from SP2 to SP3 and then to SP4. How do I remote all the old repos that still appear in the repo list after an upgrade? I know they all get disabled after an upgrade. I’ve tried removing them all using zypper rr, but if I do a zypper ref -s, they all come back:
zypper ref -s
Refreshing service ‘nu_novell_com’.
Adding repository ‘SLE11-SP4-Debuginfo-Updates’ [done]
Adding repository ‘SLES11-Extras’ [done]
Adding repository ‘SLES11-SP2-Updates’ [done]
Adding repository ‘SLE11-WebYaST-SP2-Pool’ [done]
Adding repository ‘SLES11-SP1-Pool’ [done]
Adding repository ‘SLES11-SP3-Updates’ [done]
Adding repository ‘SLES11-SP2-Extension-Store’ [done]
Adding repository ‘SLES11-SP3-Pool’ [done]
Adding repository ‘SLE11-Public-Cloud-Module’ [done]
Adding repository ‘SLE11-SP3-Debuginfo-Pool’ [done]
Adding repository ‘SLE11-SP2-WebYaST-1.3-Pool’ [done]
Adding repository ‘SLES11-SP2-Core’ [done]
Adding repository ‘SLE11-WebYaST-SP1-Updates’ [done]
Adding repository ‘SLE11-SP1-Debuginfo-Updates’ [done]
Adding repository ‘SLE11-WebYaST-SP1-Pool’ [done]
Adding repository ‘SLES11-SP1-Updates’ [done]
Adding repository ‘SLES11-SP3-Extension-Store’ [done]
Adding repository ‘SLE11-SP2-WebYaST-1.3-Updates’ [done]
Adding repository ‘SLE11-WebYaST-SP2-Updates’ [done]
Adding repository ‘SLE11-Security-Module’ [done]
Adding repository ‘SLE11-SP1-Debuginfo-Pool’ [done]
Adding repository ‘SLE11-SP3-Debuginfo-Updates’ [done]
Adding repository ‘SLE11-SP4-Debuginfo-Pool’ [done]
Adding repository ‘SLE11-SP2-Debuginfo-Updates’ [done]
Adding repository ‘SLE11-SP2-Debuginfo-Core’ [done]
All services have been refreshed.
Repository ‘SLES11-SP4-Pool’ is up to date.
Repository ‘SLES11-SP4-Updates’ is up to date.
All repositories have been refreshed.
zypper lr
| Alias | Name | Enabled | Refresh
—±--------------------------------------------±------------------------------±--------±-------
1 | nu_novell_com:SLE11-Public-Cloud-Module | SLE11-Public-Cloud-Module | No | Yes
2 | nu_novell_com:SLE11-SP1-Debuginfo-Pool | SLE11-SP1-Debuginfo-Pool | No | Yes
3 | nu_novell_com:SLE11-SP1-Debuginfo-Updates | SLE11-SP1-Debuginfo-Updates | No | Yes
4 | nu_novell_com:SLE11-SP2-Debuginfo-Core | SLE11-SP2-Debuginfo-Core | No | Yes
5 | nu_novell_com:SLE11-SP2-Debuginfo-Updates | SLE11-SP2-Debuginfo-Updates | No | Yes
6 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Pool | SLE11-SP2-WebYaST-1.3-Pool | No | Yes
7 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Updates | SLE11-SP2-WebYaST-1.3-Updates | No | Yes
8 | nu_novell_com:SLE11-SP3-Debuginfo-Pool | SLE11-SP3-Debuginfo-Pool | No | Yes
9 | nu_novell_com:SLE11-SP3-Debuginfo-Updates | SLE11-SP3-Debuginfo-Updates | No | Yes
10 | nu_novell_com:SLE11-SP4-Debuginfo-Pool | SLE11-SP4-Debuginfo-Pool | No | Yes
11 | nu_novell_com:SLE11-SP4-Debuginfo-Updates | SLE11-SP4-Debuginfo-Updates | No | Yes
12 | nu_novell_com:SLE11-Security-Module | SLE11-Security-Module | No | Yes
13 | nu_novell_com:SLE11-WebYaST-SP1-Pool | SLE11-WebYaST-SP1-Pool | No | Yes
14 | nu_novell_com:SLE11-WebYaST-SP1-Updates | SLE11-WebYaST-SP1-Updates | No | Yes
15 | nu_novell_com:SLE11-WebYaST-SP2-Pool | SLE11-WebYaST-SP2-Pool | No | Yes
16 | nu_novell_com:SLE11-WebYaST-SP2-Updates | SLE11-WebYaST-SP2-Updates | No | Yes
17 | nu_novell_com:SLES11-Extras | SLES11-Extras | No | Yes
18 | nu_novell_com:SLES11-SP1-Pool | SLES11-SP1-Pool | No | Yes
19 | nu_novell_com:SLES11-SP1-Updates | SLES11-SP1-Updates | No | Yes
20 | nu_novell_com:SLES11-SP2-Core | SLES11-SP2-Core | No | Yes
21 | nu_novell_com:SLES11-SP2-Extension-Store | SLES11-SP2-Extension-Store | No | Yes
22 | nu_novell_com:SLES11-SP2-Updates | SLES11-SP2-Updates | No | Yes
23 | nu_novell_com:SLES11-SP3-Extension-Store | SLES11-SP3-Extension-Store | No | Yes
24 | nu_novell_com:SLES11-SP3-Pool | SLES11-SP3-Pool | No | Yes
25 | nu_novell_com:SLES11-SP3-Updates | SLES11-SP3-Updates | No | Yes
26 | nu_novell_com:SLES11-SP4-Pool | SLES11-SP4-Pool | Yes | Yes
27 | nu_novell_com:SLES11-SP4-Updates | SLES11-SP4-Updates | Yes | Yes
I know it technically doesn’t matter, but I want to clean that up. How do I do that?
That’s exactly what I did, as I mentioned in the original post. I did zypper rr, removed them all. But then I did a zypper ref -s and they all get added right back.
[QUOTE=malcolmlewis;36023]Hi
So this is a pure SLES install not OES? If it is you should be able to switch to SCC rather than Novell repos. Or don’t use the -s option?[/QUOTE]
It’s pure SLES. These are pretty old VMs, they date back to SLES for VMWare and were converted to non-VMWare distro at some point in history.
So would it be best to unregister and reregister then?
What does the “-s” do exactly? I just picked that up out of docs from previous patching/updates but I’m not sure what it does.
What really got me curious is that this particular site is using a third-party product to do the patching (I need to check and see what it is) and I noticed that every time they use it, it re-enables ALL of those repos and sets them all to refresh, greatly slowing things down. I remove them with zypper rr and a few weeks later they are all back again. That’s why I wanted to get rid of them once and for all.
On 11/01/17 16:14, malcolmlewis wrote:
[color=blue]
So this is a pure SLES install not OES? If it is you should be able to
switch to SCC rather than Novell repos. Or don’t use the -s option?[/color]
Except switching to SUSE Customer Center (SCC) won’t help … unless
you’re thinking that repos for SLES11 SP3 and earlier are not available
via SCC so won’t be able to be added back … ?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
That’s exactly what I did, as I mentioned in the original post. I did
zypper rr, removed them all. But then I did a zypper ref -s and they
all get added right back.[/color]
Please can you post the output from the following commands:
cat /etc/*release
rpm -qa *release *migration
zypper products
zypper services
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
It’s pure SLES. These are pretty old VMs, they date back to SLES for
VMWare and were converted to non-VMWare distro at some point in
history.
So would it be best to unregister and reregister then?[/color]
I don’t think that’s going to help here.
[color=blue]
What does the “-s” do exactly? I just picked that up out of docs from
previous patching/updates but I’m not sure what it does.[/color]
It refreshes services which are a level about repositories, hence one of
my questions in previous reply is the output of “zypper services”.
[color=blue]
What really got me curious is that this particular site is using a
third-party product to do the patching (I need to check and see what it
is) and I noticed that every time they use it, it re-enables ALL of
those repos and sets them all to refresh, greatly slowing things down.
I remove them with zypper rr and a few weeks later they are all back
again. That’s why I wanted to get rid of them once and for all.[/color]
What is the third-party product? Does it involve an agent being
installed on the server which could be interfering with zypper?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
So this is a pure SLES install not OES? If it is you should be able to
switch to SCC rather than Novell repos. Or don’t use the -s option?[/color]
Except switching to SUSE Customer Center (SCC) won’t help … unless
you’re thinking that repos for SLES11 SP3 and earlier are not available
via SCC so won’t be able to be added back … ?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------[/QUOTE]
Ok, I kinda was wondering about that. So just re-doing the registration against SCC won’t “fix” this.
I’ve asked others in the past about this and never got an answer. If I build a “fresh” SLES 11 SP4 box I get just the two channels, but on pretty much all my boxes that have upgraded from SP2 and SP3 (or earlier) I end up with that long lists of channels and I never can quite figure out how to get rid of them.
[QUOTE=smflood;36029]On 11/01/17 15:54, matt wrote:
[color=blue]
That’s exactly what I did, as I mentioned in the original post. I did
zypper rr, removed them all. But then I did a zypper ref -s and they
all get added right back.[/color]
Please can you post the output from the following commands:
cat /etc/*release
rpm -qa *release *migration
zypper products
zypper services
[/QUOTE]
Hi
Yes, well they exist right back to SLE 10 on SCC, but it must be products/services that are retaining them…
[QUOTE=smflood;36029]On 11/01/17 15:54, matt wrote:
[color=blue]
That’s exactly what I did, as I mentioned in the original post. I did
zypper rr, removed them all. But then I did a zypper ref -s and they
all get added right back.[/color]
Please can you post the output from the following commands:
cat /etc/*release
rpm -qa *release *migration
zypper products
zypper services
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------[/QUOTE]
Here is the output:
cat /etc/*release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 4
LSB_VERSION=“core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64”
NAME=“SLES”
VERSION=“11.4”
VERSION_ID=“11.4”
PRETTY_NAME=“SUSE Linux Enterprise Server 11 SP4”
ID=“sles”
ANSI_COLOR=“0;32”
CPE_NAME=“cpe:/o:suse:sles:11:4”
rpm -qa *release *migration
lsb-release-2.0-1.2.18
sles-release-11.4-1.109
zypper products
Retrieving repository ‘SLES11-SP4-Updates’ metadata [done]
Building repository ‘SLES11-SP4-Updates’ cache [done]
Loading repository data…
Reading installed packages…
S | Repository | Internal Name | Name | Version | Arch | Is Base
–±-----------±--------------±------------------------------------±-----------±-------±-------
i | @System | SUSE_SLES | SUSE Linux Enterprise Server 11 SP4 | 11.4-1.109 | x86_64 | Yes
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 4
LSB_VERSION=“core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64”
NAME=“SLES”
VERSION=“11.4”
VERSION_ID=“11.4”
PRETTY_NAME=“SUSE Linux Enterprise Server 11 SP4”
ID=“sles”
ANSI_COLOR=“0;32”
CPE_NAME=“cpe:/o:suse:sles:11:4”
rpm -qa *release *migration
lsb-release-2.0-1.2.18
sles-release-11.4-1.109
zypper products
Retrieving repository ‘SLES11-SP4-Updates’ metadata [done]
Building repository ‘SLES11-SP4-Updates’ cache [done]
Loading repository data…
Reading installed packages…
S | Repository | Internal Name | Name |
Version | Arch | Is Base
–±-----------±--------------±------------------------------------±-----------±-------±-------
i | @System | SUSE_SLES | SUSE Linux Enterprise Server 11 SP4 |
11.4-1.109 | x86_64 | Yes[/color]
Okay the above all tallies with the server being at SLES11 SP4
suggesting the upgrade was successful - the release file and package are
correct, there are no migration-related packages installed, and zypper
agrees.
[color=blue]
Ok, I kinda was wondering about that. So just re-doing the registration
against SCC won’t “fix” this.[/color]
No I don’t think it will fix this.
[color=blue]
I’ve asked others in the past about this and never got an answer. If I
build a “fresh” SLES 11 SP4 box I get just the two channels, but on
pretty much all my boxes that have upgraded from SP2 and SP3 (or
earlier) I end up with that long lists of channels and I never can quite
figure out how to get rid of them.[/color]
Yes if you build fresh SLES11 SP4 you’ll only see the SP4-related repos
post-install. Unfortunately upgrades leave some stuff behind, mostly
because it’s safer, and your situation isn’t helped by SLES11 SP2 using
SLES11 SP1 repos so when you have upgraded to SLES11 SP3 you’ll see SP1,
SP2, and SP3 repos (though only the latter should be active post-upgrade).
In my personal experience I’ve always been able to “zypper remove” the
old repos though I am aware of them reappearing but struggling to
remember the details.
What happens if you physically delete a repo file from
/etc/zypp/repos.d, say “rm
/etc/zypp/repos.d/nu_novell_com\:SLE11-SP1-Debuginfo-Pool” ? Does the
SLE11-SP1-Debuginfo-Pool repo return when you subsequently do “zypper
ref -s” ?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------[/QUOTE]
So basically, there is no way to clean this up:
zypper lr
# | Alias | Name | Enabled | Refresh
---+---------------------------------------------+-------------------------------+---------+--------
1 | nu_novell_com:SLE11-Public-Cloud-Module | SLE11-Public-Cloud-Module | No | Yes
2 | nu_novell_com:SLE11-SP1-Debuginfo-Pool | SLE11-SP1-Debuginfo-Pool | No | Yes
3 | nu_novell_com:SLE11-SP1-Debuginfo-Updates | SLE11-SP1-Debuginfo-Updates | No | Yes
4 | nu_novell_com:SLE11-SP2-Debuginfo-Core | SLE11-SP2-Debuginfo-Core | No | Yes
5 | nu_novell_com:SLE11-SP2-Debuginfo-Updates | SLE11-SP2-Debuginfo-Updates | No | Yes
6 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Pool | SLE11-SP2-WebYaST-1.3-Pool | No | Yes
7 | nu_novell_com:SLE11-SP2-WebYaST-1.3-Updates | SLE11-SP2-WebYaST-1.3-Updates | No | Yes
8 | nu_novell_com:SLE11-SP3-Debuginfo-Pool | SLE11-SP3-Debuginfo-Pool | No | Yes
9 | nu_novell_com:SLE11-SP3-Debuginfo-Updates | SLE11-SP3-Debuginfo-Updates | No | Yes
10 | nu_novell_com:SLE11-SP4-Debuginfo-Pool | SLE11-SP4-Debuginfo-Pool | No | Yes
11 | nu_novell_com:SLE11-SP4-Debuginfo-Updates | SLE11-SP4-Debuginfo-Updates | No | Yes
12 | nu_novell_com:SLE11-Security-Module | SLE11-Security-Module | No | Yes
13 | nu_novell_com:SLE11-WebYaST-SP1-Pool | SLE11-WebYaST-SP1-Pool | No | Yes
14 | nu_novell_com:SLE11-WebYaST-SP1-Updates | SLE11-WebYaST-SP1-Updates | No | Yes
15 | nu_novell_com:SLE11-WebYaST-SP2-Pool | SLE11-WebYaST-SP2-Pool | No | Yes
16 | nu_novell_com:SLE11-WebYaST-SP2-Updates | SLE11-WebYaST-SP2-Updates | No | Yes
17 | nu_novell_com:SLES11-Extras | SLES11-Extras | No | Yes
18 | nu_novell_com:SLES11-SP1-Pool | SLES11-SP1-Pool | No | Yes
19 | nu_novell_com:SLES11-SP1-Updates | SLES11-SP1-Updates | No | Yes
20 | nu_novell_com:SLES11-SP2-Core | SLES11-SP2-Core | No | Yes
21 | nu_novell_com:SLES11-SP2-Extension-Store | SLES11-SP2-Extension-Store | No | Yes
22 | nu_novell_com:SLES11-SP2-Updates | SLES11-SP2-Updates | No | Yes
23 | nu_novell_com:SLES11-SP3-Extension-Store | SLES11-SP3-Extension-Store | No | Yes
24 | nu_novell_com:SLES11-SP3-Pool | SLES11-SP3-Pool | No | Yes
25 | nu_novell_com:SLES11-SP3-Updates | SLES11-SP3-Updates | No | Yes
26 | nu_novell_com:SLES11-SP4-Pool | SLES11-SP4-Pool | Yes | Yes
27 | nu_novell_com:SLES11-SP4-Updates | SLES11-SP4-Updates | Yes | Yes
An upgraded box will always have all those old repos listed and they cannot be removed?