Broken Dependencies after move-to-sles10-sp4

I moved several SLES 10 SP3 servers to SP4 in the last weeks (some of them
OES2) - there where some minor problems but it worked.

Today while updating the last four servers I ran into problems. I used the
rug procedure from TID 7008357; step “rug in -t patch move-to-sles10-sp4”
was successful - but then I get the following (on all four servers!):

s1:~ # rug up -t patch
Resolving Dependencies…

ERROR: Dependency resolution failed:
Unresolved dependencies:
product:SUSE_SLES_SP3-10.3-1.i386[System packages] provides SUSE-Linux-
Enterprise-Server-SP3-fromSP2 == 10.3-0, but is scheduled to be uninstalled.
product:SUSE_SLES_SP3-10.3-1.i386[SLES10-SP3-Online] provides SUSE-Linux-
Enterprise-Server-SP3-fromSP2 == 10.3-0, but it is uninstallable. Try
installing it on its own for more details.
There are no installable providers of SUSE-Linux-Enterprise-Server-SP3-
fromSP2 for script:move-to-sles10-sp3-script.sh-0-26.noarch[System packages]
Establishing script:move-to-sles10-sp3-script.sh-0-26.noarch[System
packages]
This would invalidate script:move-to-sles10-sp3-script.sh-0-26.noarch[System
packages].
Marking this resolution attempt as invalid.

Any ideas what went wrong and what to do?

Thanks,
Mirko

[QUOTE=Mirko Guldner]I moved several SLES 10 SP3 servers to SP4 in the
last weeks (some of them OES2) - there where some minor problems but it
worked.

Today while updating the last four servers I ran into problems. I used
the rug procedure from TID 7008357; step “rug in -t patch
move-to-sles10-sp4” was successful - but then I get the following (on
all four servers!):

s1:~ # rug up -t patch
Resolving Dependencies…

ERROR: Dependency resolution failed:
Unresolved dependencies:
product:SUSE_SLES_SP3-10.3-1.i386[System packages] provides SUSE-Linux-
Enterprise-Server-SP3-fromSP2 == 10.3-0, but is scheduled to be
uninstalled. product:SUSE_SLES_SP3-10.3-1.i386[SLES10-SP3-Online]
provides SUSE-Linux- Enterprise-Server-SP3-fromSP2 == 10.3-0, but it is
uninstallable. Try installing it on its own for more details.
There are no installable providers of SUSE-Linux-Enterprise-Server-SP3-
fromSP2 for script:move-to-sles10-sp3-script.sh-0-26.noarch[System
packages] Establishing
script:move-to-sles10-sp3-script.sh-0-26.noarch[System packages]
This would invalidate
script:move-to-sles10-sp3-script.sh-0-26.noarch[System packages].
Marking this resolution attempt as invalid.

Any ideas what went wrong and what to do?

Thanks,
Mirko

[/QUOTE]
Hi
You don’t have some old repositories still active on those systems?


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 3 days 7:45, 4 users, load average: 0.00, 0.13, 0.41
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

malcolmlewis wrote:

[…][color=blue]

Hi
You don’t have some old repositories still active on those systems?
[/color]

Yes, indeed I have/had. The difference between those servers where SP4 was
successful and those were it wasn’t is that the latter were older and
originaly were installed with SLES 10 SP2 or earlier.

So they had still an old SLES 10 SP as installation source (network, http)
even though they were long ago upgraded to SP3; until now this never caused
any problemes.

It was one of the first thing I tried, when that dependency error occured,
to remove that installation source. It made no difference, still that
dependency error. But I removed the installation source only afer move-to-
sles10-sp4 was run, should probably have done this before?

Unfortunately I startet move-to-sles10-sp4 on all remaining servers in
parallel, to save time, after upgrading 9 servers one after the other was
successful - so I can not try what happens if I remove old installation
sources first.

Another question: there is this file in /var/lib/zypp/db/products:

<?xml version="1.0" encoding="UTF-8"?>


SUSE_SLES_SP3

i386
SUSE_SLES_SP3 ==
10.3-1
SUSE_SLES == 10.3-0
SUSE_SLES_SP2 == 10.3-0
SUSE-Linux-Enterprise-Server-SP3-fromSP2 ==
10.3-0
SUSE_SLE == 10.3-0

SUSE_SLES <
10.3-0
SUSE-Linux-Enterprise-Server-SP3-migration <
10.3-0
patch-move-to-sles10-sp3

sles-release-10
basesystem


0
0
false
0
1329835790
SUSE-Linux-Enterprise-Server-SP3
10-online

SLES10-SP3-Online

There are those references to SP2 - might this be related to the problem?

On one of the servers I tried the following steps from 3087507 to re-run
move-to-sles10-sp4:

rm -rf /var/lib/zmd
rm -rf /var/cache/zmd
rm -rf /etc/zmd/deviceid
rm -rf /var/lib/zypp/db/sources
rm -rf /etc/zmd secret
suse_register …

The result seems to be a “clean” SP3 status, but applying again move-to-
sles10-sp4 does not work:

s3:~ # rug sl

| Status | Type | Name | URI

–±-------±-----±----------------------±---------------------
1 | Active | NU | https://nu.novell.com | https://nu.novell.com

s3:~ # rug ca

Sub’d? | Name | Service
-------±----------------------------±---------------------
Yes | SLES10-SP3-Online | https://nu.novell.com
Yes | SLES10-SP3-Updates | https://nu.novell.com
Yes | SLES10-SP3-Pool | https://nu.novell.com
| SLE10-SP3-Debuginfo-Updates | https://nu.novell.com
| SLE10-SP3-Debuginfo-Pool | https://nu.novell.com
| SLE10-SP3-Debuginfo-Online | https://nu.novell.com

s3:~ # rug lu
No updates are available.
s3:~ # rug lu -t patch

Catalog | Name | Version | Category | Status
-------------------±-------------------±--------±---------±------
SLES10-SP3-Updates | move-to-sles10-sp4 | 0-31 | optional | Needed

s3:~ # SPident

CONCLUSION: System is up-to-date!
found SLE-10-i386-SP3 + “online updates”

Thanks,
Mirko

I am also seeing a similar issue with a small handful of servers that were upgraded from 10.2 to 10.3 and now to 10.4. This is preventing them from getting the correct update channels when doing a suse_register. The product sp 4 marker can’t be installed, so it only gives them SP3 channels instead of SP4 even though SPident shows a correct SP output. Registering to a Subscription Management Tool server.

SPident

CONCLUSION: System is up-to-date!
found SLE-10-x86_64-SP4 + “online updates”

rug ca (edited)

Yes | Yes | SLES10-SP3-Updates | http://svmpsmt02.
| Yes | SLES10-SP3-Pool | http://svmpsmt02.
Yes | Yes | SLES10-SP3-Online | http://svmpsmt02.
Yes | Yes | SLES10-SP4-Online | http://svmpsmt02.

Your rug ca is after move-to-sles10-sp4 was installed? Here it looks like
this:

db:~ # rug sl

| Status | Type | Name | URI

–±-------±-----±----------------------±---------------------
1 | Active | NU | https://nu.novell.com | https://nu.novell.com

db:~ # rug ca

Sub’d? | Name | Service
-------±----------------------------±---------------------
| SLES10-SP3-Online | https://nu.novell.com
Yes | SLES10-SP4-Pool | https://nu.novell.com
Yes | SLES10-SP4-Online | https://nu.novell.com
| SLE10-SP4-Debuginfo-Pool | https://nu.novell.com
| SLE10-SP4-Debuginfo-Updates | https://nu.novell.com
| SLES10-GPLv3-Extras | https://nu.novell.com

I opened a SR with Novell. They said there should be no SLES10-SP3-Online
and even if is not subscribed this could be the problem. But I’m still
waiting for an answer to how to get rid of this catalog…

Mirko

eaws wrote:
[color=blue]

I am also seeing a similar issue with a small handful of servers that
were upgraded from 10.2 to 10.3 and now to 10.4. This is preventing
them from getting the correct update channels when doing a
suse_register. The product sp 4 marker can’t be installed, so it only
gives them SP3 channels instead of SP4 even though SPident shows a
correct SP output. Registering to a Subscription Management Tool
server.

SPident

CONCLUSION: System is up-to-date!
found SLE-10-x86_64-SP4 + “online updates”

rug ca (edited)

Yes | Yes | SLES10-SP3-Updates |
http://svmpsmt02.

| Yes | SLES10-SP3-Pool |
http://svmpsmt02.

Yes | Yes | SLES10-SP3-Online |
http://svmpsmt02.

Yes | Yes | SLES10-SP4-Online |
http://svmpsmt02.

[/color]

So far, we have only one or two servers out of around 80 upgraded to SLES10SP4 that have had this problem without being able to fix it. On a few servers, I was able to use yast online update and it prompted to delete the product-sp3 marker and move-to-sp3 script, which allowed the move-to-sp4 and product-sp4 marker to install correctly.

As a workaround on the two servers, we removed the SMT NU channel and manually added type zypp channels for SLES10-SP4 Pool and Updates.

I opened a SR with Novell - they said the only supported way to fix this is
to do an offline upgrade with SLES10 SP4-media.

Mirko Guldner wrote:
[color=blue]

I moved several SLES 10 SP3 servers to SP4 in the last weeks (some of them
OES2) - there where some minor problems but it worked.

Today while updating the last four servers I ran into problems. I used the
rug procedure from TID 7008357; step “rug in -t patch move-to-sles10-sp4”
was successful - but then I get the following (on all four servers!):

s1:~ # rug up -t patch
Resolving Dependencies…

ERROR: Dependency resolution failed:
Unresolved dependencies:
product:SUSE_SLES_SP3-10.3-1.i386[System packages] provides SUSE-Linux-
Enterprise-Server-SP3-fromSP2 == 10.3-0, but is scheduled to be
uninstalled. product:SUSE_SLES_SP3-10.3-1.i386[SLES10-SP3-Online] provides
SUSE-Linux-
Enterprise-Server-SP3-fromSP2 == 10.3-0, but it is uninstallable. Try
installing it on its own for more details.
There are no installable providers of SUSE-Linux-Enterprise-Server-SP3-
fromSP2 for script:move-to-sles10-sp3-script.sh-0-26.noarch[System
packages] Establishing
script:move-to-sles10-sp3-script.sh-0-26.noarch[System packages]
This would invalidate
script:move-to-sles10-sp3-script.sh-0-26.noarch[System packages].
Marking this resolution attempt as invalid.

Any ideas what went wrong and what to do?

Thanks,
Mirko[/color]

I had a similar issue just today. I managed to get around it by removing the move-to-sles10-sp3 patch:

rug rm -t patch move-to-sles10-sp3

After removing that patch, I was able to continue the SP4 update without any further issues.

[QUOTE=woodsy_ca;5699]I had a similar issue just today. I managed to get around it by removing the move-to-sles10-sp3 patch:

rug rm -t patch move-to-sles10-sp3

After removing that patch, I was able to continue the SP4 update without any further issues.[/QUOTE]

Thanks for that. I ran in to this here, too, and this also worked for me.