SUSE Mgr3 SP migration question

SUSE Manager
1

While running SUSE Mgr3, i’m performing a “dry run” Service pack migration and i see the results in the system event history.
It tells me that x number of packages will be upgraded, installed, downgraded and removed. Is there a way to see a detail report of what these packages are ? Or even a way to manually perform the SP migration on the system itself through zypper ? I can do this somewhat on a failure as the update repos are still listed after a failed migration and i can go to the system and run “zypper update” and see exactly what the problem was. Sometimes I can fix it right there.

Any information on this process would be helpful.

Thanks

2

Hi
From the system your looking at updating add some verbosity to the zypper dup command;

zypper dup --help
zypper -vv -D dup
3

How will this work when we initiate the migration form Suse Manager ? The migration uses multiple repos.

I tried the “zypper -vv -D dup” on a server that needs to be migrated from SLES 12 SP0 to SP1 - it didn’t like it.

4

Ok it didn’t like the order

zypper dup -D --dry-run --details -is working somewhat not sure what I’m seeing at the moment.

Should this command be able to determine that I want to go to SP1 form SP0 ?

5

Hi
Add the -vv (that’s v v) option to provide some more details on where
the packages are coming from. Then you can work out what needs to be
updated if they are non standard repos. Then you need to get the SuMA
repos up to date for SP1 and then you should be able to do another dry
run from SuMA, hopefully that will clear things up.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-44-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

6

Ok I’m missing a step or something. When i run the “zypper -vv dup -D --dry-run --details” I do see what repos it is using and they are the current ones for the current version. Do I have to remove all the current repos and add the equivalent ones for the SP I’m going to in odder for this to work ?
Which in our case would be 16 different repos. - script time :slight_smile:

7

Hi
Are they all standard ones (as in subscription)? Or are some from
somewhere like OBS?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-44-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

8

Yes they are subscriptions (channels) based on the registration key. Each SP has a separate Reg Key so they get the correct channels for patching.

9

Hi
Not sure about each SP has a different key… do you mean bootstrap key?

In the SLES 12 Updates Channel is patch SUSE-12-2015-966 this should
be installed?

Under the Admin menu option, there are the logs for the dry-run, which
should show more detail on what is failing.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-44-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

10

In SUMA we created a separate activation key for each OS and SP, so SLES12 SPO, SP1 and SP2 each have a different activation key. Each key have a set of repos assigned to it pertaining to its version.

As for the dry-run logs under the Admin menu - I don’t see them. System History Event is the only location i see the results of a attempted SP migration whether successful or not. Under the Schedule Menu, Failed Actions, The SP Mig Action or under the system itself - Events tab.

11

Hi
OK, you mean a bootstrap activation key then? That should be fine, Is
the migration patch update installed on the target system
SUSE-12-2015-966?

Else if you look at Yast2-migration on the target system and run this
how does it go?

On my test systems (from memory) on SuMA 2.1 the dry-run ran and logged
the packages that needed updating, once I had those up to SP1, the dry
run went fine…

So in the output what can you see? Can you post the info?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-44-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

12

Unfortunately SUSE-12-2015-966 doesn’t show up in the patches list - so i can’t really tell. Probably because SLES 12 SP0 is no longer supported. Is there a way to search based on patch release “SUSE-12-2015-966” - never tried this before but i can see where it would come in handy.

We are running SUMA 3 on SLES12 SP1 - not 2.1 -

Here is an example I see:
Summary: Service Pack Migration scheduled by admin
Details: This action will be executed after 1/10/17 5:58:00 PM EST
This action’s status is: Completed.
The client picked up this action on 1/10/17 5:58 PM
The client completed this action on 1/10/17 5:58 PM
Client execution returned
You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See ‘man zypper’ for more information about this command.
Refreshing service ‘spacewalk’.
Loading repository data…
Reading installed packages…
Computing distribution upgrade…
upgrade: 691
install: 72
downgrade: 8
remove: 43
(code 0)

This is all we get - no list of what packages will be installed, upgraded, etc…

13

Hi
Likewise I have SuMA 3.0 now, did my upgrades awhile ago… :wink:

So in SuMA if you select Channels and then expand SLES12-Pool for x86_64 and select SLES12-Updates for x86_64, now select the ‘Patches’ tab and search on migration. It should show a list, including SUSE-12-2015-966 “SLE 12 SP migration enablement”?

You might have to look at the logs manually;

fgrep -r "Service Pack Migration" /var/log/*

Also look at the Tomcat logs down there as well if the fgrep doesn’t work.

14

Ok - I found it - it does exist. ok so we know that the SUSE 12 SP 0 systems have the patch -but tried to run yast2-migration and it doesn’t find the command. The package is there, version 3.1.0.12-3.1.

15

Hi
It’s a YaST module, so no dash :wink:

yast2 --list (--help for other bits)
yast2 migration

So you found the logs indicating which packages are going to change, downgrade etc?

16

Ok the Yast Online migration opens and loads then gives me the “The system is not registered, to run the online migration you need to register the system first.” Of course it is registered with SUMA not SCC to this error is correct. So it appears that yast migration has not been modified yet to work with SUMA is seems.

17

Hi
Sounds like a SR/Bug report time…

What about logs for the files to change from the dry run?

18

There are none that i can find - I just get a count of the packages to updated, etc… This is the info I’m looking for myself.

Tomcat log have nothing, this is all I can find in SUMA 3 - I can’t find another way to do a dry-run that will work except through SUMA.

Summary: Service Pack Migration scheduled by Admin
Details: This action will be executed after 1/10/17 5:58:00 PM EST
This action’s status is: Completed.
The client picked up this action on 1/10/17 5:58 PM
The client completed this action on 1/10/17 5:58 PM
Client execution returned
You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See ‘man zypper’ for more information about this command.
Refreshing service ‘spacewalk’.
Loading repository data…
Reading installed packages…
Computing distribution upgrade…
upgrade: 691
install: 72
downgrade: 8
remove: 43
(code 0)
Time: 1/10/17 5:58:00 PM EST

This was from last night.

19

Hi
OK, so on the target system, look in the /var/log/zypper.log file it
should have data there.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-44-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

20

Ok the zypper.log did have the info - just a lot to go through. Over 7000+ lines

Thanks