Hi,

have you run rstaut USRPRF(*ALL) after the restore?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Me neither, but there is no other chance in real cloud environment...

------------------------------
Igor Novotny
Principal Consultant
MHM Computer, a.s.
Prague 15
00420602369375
------------------------------


Original Message:
Sent: Thu May 02, 2024 11:08 AM
From: Robert Berendt
Subject: Unable to logon after OS restore before IPL options

I've never used STRNETINS

------------------------------
Robert Berendt IBMChampion


Original Message:
Sent: Thu May 02, 2024 11:01 AM
From: Igor Novotny
Subject: Unable to logon after OS restore before IPL options

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

------------------------------
Igor Novotny
Principal Consultant
MHM Computer, a.s.
Prague 15
00420602369375


Original Message:
Sent: Thu May 02, 2024 10:30 AM
From: Robert Berendt
Subject: Unable to logon after OS restore before IPL options

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

------------------------------
Robert Berendt IBMChampion


Original Message:
Sent: Thu May 02, 2024 10:25 AM
From: Robert Berendt
Subject: Unable to logon after OS restore before IPL options

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

------------------------------
Robert Berendt IBMChampion

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Did you use COR (Cloud Optical Repository) for the restore? If not, you may want to try it and I attach a paper on how to set it up herewith.

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Hi Satid,
there seems to be no problem in IBM i NFS server/client communication as all pre-checks work fine (tftp get, WRKIMGLCGE,...).
Also IPL from network, LIC install and first part of OS install via NFS is smooth
incl. "bar graph" step 24 in https://www.ibm.com/docs/en/i/7.5?topic=system-recovering-your-different
But the step 25 is showstopper...

COR is perfect solution for new system install, but my PoC task is:
full system backup via BRMS to iSCSI VTL and its full restore (incl. LIC) - everything in IBM Cloud environment.

Regards Igor.

Did you use COR (Cloud Optical Repository) for the restore? If not, you may want to try it and I attach a paper on how to set it up herewith.

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Dear Igor

I just found a Technote for resetting QSECOFR password using DST menu from manual mode IPL.  The instruction is here: Resetting OS QSECOFR Password Using DST - Version 5 and Higher at  https://www.ibm.com/support/pages/resetting-os-qsecofr-password-using-dst-version-5-and-higher.   Once you do the reset, you continue with the IPL. 

Wishing you luck this time.      

Hi Satid,
there seems to be no problem in IBM i NFS server/client communication as all pre-checks work fine (tftp get, WRKIMGLCGE,...).
Also IPL from network, LIC install and first part of OS install via NFS is smooth
incl. "bar graph" step 24 in https://www.ibm.com/docs/en/i/7.5?topic=system-recovering-your-different
But the step 25 is showstopper...

COR is perfect solution for new system install, but my PoC task is:
full system backup via BRMS to iSCSI VTL and its full restore (incl. LIC) - everything in IBM Cloud environment.

Regards Igor.

Did you use COR (Cloud Optical Repository) for the restore? If not, you may want to try it and I attach a paper on how to set it up herewith.

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?

Hi Satid,

good point, but the Control panel function "(21) Activate dedicated service tools" just disconnects the console (COMM657 error) and no DST menu appears.

At least in IBM Cloud and in this point of recovery...

Regards Igor.

Dear Igor

I just found a Technote for resetting QSECOFR password using DST menu from manual mode IPL.  The instruction is here: Resetting OS QSECOFR Password Using DST - Version 5 and Higher at  https://www.ibm.com/support/pages/resetting-os-qsecofr-password-using-dst-version-5-and-higher.   Once you do the reset, you continue with the IPL. 

Wishing you luck this time.      

Hi Satid,
there seems to be no problem in IBM i NFS server/client communication as all pre-checks work fine (tftp get, WRKIMGLCGE,...).
Also IPL from network, LIC install and first part of OS install via NFS is smooth
incl. "bar graph" step 24 in https://www.ibm.com/docs/en/i/7.5?topic=system-recovering-your-different
But the step 25 is showstopper...

COR is perfect solution for new system install, but my PoC task is:
full system backup via BRMS to iSCSI VTL and its full restore (incl. LIC) - everything in IBM Cloud environment.

Regards Igor.

Did you use COR (Cloud Optical Repository) for the restore? If not, you may want to try it and I attach a paper on how to set it up herewith.

Me neither, but there is no other chance in real cloud environment...

I've never used STRNETINS

You are right, the recovery was started from running system via STRNETINS and it goes to the same disks.

ASP was recreated during LIC install -  yes, I used option 2. in step 7...

On that note, did you use " =>2. Install Licensed Internal Code and Initialize System" on step 7?

Igor,

I reviewed my BRMS recovery report, which I've used for a fair amount of system migrations.  I've looked at your link for recovering your system to a different system.  I've looked also at the related link for general recovering your system.  They all point to the same step 25.

All I can guess is that maybe, you've restored to this system earlier.  Perhaps to test it out, verify that the SAN disk actually connects and is mapped properly or any other number of reasons.  And now you are doing the production restore.  The processes you are following are assuming a scratch system.  

If you have done this earlier test, and have not scratched your system, then yes, there will be a QSECOFR.

Could this be the possibility?