The system is registered at SuSE Manager
which SUSE Manager version is this, do you have current patches applied to it, are you already connecting to SCC?
And YES, I’ve already read the documentation & Releasenotes to get some migration information
My current approach is:
looking at it from a “let’s do it without SUSE Manager” point of view, like your current approach does, I see significant deviations from the SUSE-documented steps (i.e. https://www.suse.com/support/kb/doc/?id=7016711, “2) Update by using zypper”):
- update the SLES11SP3 system to latest code level (why SMT? Doesn’t your SUSE Manager provide the required channels?) (zypper ref -s; zypper --non-interactive patch --auto-agree-with-licenses --with-interactive; zypper --non-interactive patch --auto-agree-with-licenses --with-interactive")
- install applicable product migration packages
- switch the system to the SLES11SP4 channels via SUSE Manager
- refresh the repositories, disable any possibly still enabled SP3 repositories, enable any possibly not enabled SP4 channels
- “zypper dup …” per above article
But of course, your usage of the “old SMT server” may be related to the state of the SLES11SP3 channels in your SUSE Manager.
But this seems to be very hard way.
I agree to some extend - but at least it’s a scriptable way, if you’re using a mechanism that lets you synchronize installing the SP3 migration packages, switching channels and then running appropriate “zypper dup” per server.
We have about 300 SLES11SP3 Systems to migrate and I look for a good automated way over SuSE Manager.
From my personal point of view, automating that update needs to take into account the servers’ inter-dependencies and does have a great potential for running havoc, if not prepared to handle upgrade failures. Of course, initiating the SUSE Manager “SP Migration” should be available via some automated way, but usually not “all at once”
And of course you’re right to expect SP migration to work within SUSE Manager, maybe that’s something to tackle first?