So after clone we do this 

SLES 11
        suse_register --erase-local-regdata
SLES 12
        rm /etc/sysconfig/rhn/systemid


Then for sles 11 to SMT we were using "suse_register -r" next.
i never bothered to figure out how to register 12 to SMT since we have SUSE 
Manager now.

Now for both we run the SUSE Manager bootstrap script.


Marcy



-----Original Message-----
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Duane 
Beyer
Sent: Thursday, December 01, 2016 1:10 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES 12 SP1 service - File './repo/repoindex.xml' not 
found

Hi Folks,
I am looking for some input from the community:

I have opened a ticket with Suse support concerning this issue I encountered 
where our SLES 12 SP 1 systems suddenly started failing when we run zypper or 
yast to apply service or install new products (earlier in this thread).  I was 
told by support that each system needs a unique token for service to work 
properly.  The procedure to correct the problem involves deleting files on the 
SLES 12 SP1 system and re-registering it (see below).

Is anyone aware of a documented restriction with SLES 12 SP1 requiring each 
image to have a unique token?  We have been cloning our SLES systems for years. 
 SLES 9, SLES 10, SLES 11, and never had an issue with applying service or 
installing new products to a clone.

I feel like Suse has made a change to the way service works without telling us. 
 Especially since it was working just fine on SLES 12 SP1 from
Jan 2016 to October 2016.   Before I go an make a big deal about this,
just wanted to check with the community if they are aware of any such 
restriction.

I did find information for SLES 12 systems not booting after cloning,  but that 
was due to the UUID of the IPL device not matching or the SWAP device having a 
different UUID and the system was unable to locate the recovery data (from 
sleep/suspend).  But I have not come accross anything stating you would not be 
able to apply service on a cloned system if it did not have a unique token.


Here is the fix I was giving from support to correct the problem.   It
does work,  but I really don't want to be deleting files on systems that are 
currently in production.

Step 1. delete all the files in the following directories:
        /etc/zypp/credentials.d/*
        /etc/zypp/repos.d/*
        /etc/zypp/services.d/*
Step 2,  Re-register the system with Suse.


I appreciate any input anyone can share.

Thanks,
Duane

Duane Beyer
Marist College
(845) 575-3216 - Office
(845) 475-1331
E-mail - duane.be...@marist.edu

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit http://wiki.linuxvm.org/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to