Found an article on using “zypper migration” (an add-on plugin, installed by default).
Anyways it seem to try and connect to SCC by default, but we use SUMA 3, so the system is not directly registered with SCC. This causes “zypper migration” to fail.
Is there a way to get “zypper migration” to connect to SUMA 3 instead of SCC ?
Looking for more detailed information on a SP migration of a system. SUMA 3 does’t provide enough detail on packages being upgraded, installed or removed.
Thanks
On 10/01/17 16:44, cisaksen wrote:
[color=blue]
Found an article on using “zypper migration” (an add-on plugin,
installed by default).
Anyways it seem to try and connect to SCC by default, but we use SUMA 3,
so the system is not directly registered with SCC. This causes “zypper
migration” to fail.Is there a way to get “zypper migration” to connect to SUMA 3 instead of
SCC ?Looking for more detailed information on a SP migration of a system.
SUMA 3 does’t provide enough detail on packages being upgraded,
installed or removed.[/color]
As per
https://www.suse.com/documentation/sles-12/book_sle_deployment/data/cha_update_spmigration.html
service Ppck migration is supported via SUSE Manager - instead of
register with SCC in step 2 of
https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_update_migr_zypper_onlinemigr.html
make sure your server is registered with your SUSE Manager.
Or are you saying that you have already tried this and “zypper
migration” still wants to connect to SCC? If this is the case does your
server (to be SP migrated) have access to all the necessary repos from
your SUSE Manager?
Simon
SUSE Knowledge Partner
system: ServerA
ServerA was never registered with SCC, it was registered with SUMA 3 using the bootstrap suma activation key method. Channels (repos) are added through this method to the system. So the system is never on SCC and the repos added are based on the Activation Key setup in SUMA.
We can migrate through SUMA but there have been some issues where we would like more information on what is happening. We have one instance where the dry-run has failed but there really isn’t alot of information as to what exactly failed. Luckily we found that we can go to the system in question and run zypper update and it will attempt the SP migration and show us when went wrong.
The other instance is when a dry run is successful and but we want to see exactly what packages are going to be updated, installed and removed or replaced. As in php5 will get replaced with php7 on a SP0 to SP1 migration. They fixed this on a SP2 migration where it won’t replace it.
hope this helps
On 10/01/17 18:24, cisaksen wrote:
[color=blue]
system: ServerA
ServerA was never registered with SCC, it was registered with SUMA 3
using the bootstrap suma activation key method. Channels (repos) are
added through this method to the system. So the system is never on SCC
and the repos added are based on the Activation Key setup in SUMA.We can migrate through SUMA but there have been some issues where we
would like more information on what is happening. We have one instance
where the dry-run has failed but there really isn’t alot of information
as to what exactly failed. Luckily we found that we can go to the
system in question and run zypper update and it will attempt the SP
migration and show us when went wrong.The other instance is when a dry run is successful and but we want to
see exactly what packages are going to be updated, installed and removed
or replaced. As in php5 will get replaced with php7 on a SP0 to SP1
migration. They fixed this on a SP2 migration where it won’t replace
it.[/color]
Is this the same issue as, or related to, your thread in the SUSE
Manager forum - https://forums.suse.com/showthread.php?8817 ?
Simon
SUSE Knowledge Partner
Didn’t start out that way on the other post but it did go in that direction. So yes. Is the zypper-migration just the command line equivalent of yast migration ?
Yes, exactly.