migrate_server import stuck on 4%

[Don_Paterson]

Anyone else seeing an R81.10 migrate_server import stuck (on 4%)?

R80.40 migrate_server export file being used.

migrate_server import stuck on 4%

Edit:
This is with the -l option, so it includes a small amount of logs and fw logwsitch was done before the export. 

[Alex-]

Check out sk176603.

[the_rock]

Do not use -l option...I had this exact issue before and running it without -l flag worked fine. sk @Alex- is excellent reference as well.

Andy

[Don_Paterson]

Thank you both for the replies. Very helpful.
Update:
I am still having problems.
One  import worked (without -l) but subsequent imports have failed (no -l used) and I am still trying to figure out the main issue.
At the moment I see one ERROR in the cpm.elg and it is not the same one as the SK (see attached for the error).
It appears as soon as the import moves from 3% to 4% (where is is then stuck).
The error implies that the SMC User and System Domains are in play at the time of the hang.

Take 45 applied and still the same problem.

Will post an update here if I find a solution.

Thanks,

Don

[the_rock]

You have TAC case open for this?

[Don_Paterson]

Nope. It is not a prod environment. It is a lab for the CCSE course, where the procedure is to import an R80.40 config onto a CPUSE clean install of R81.10 (overwriting the exported R80.40 SMS).

Hope to find a solution and otherwise have a work-around until I have one.

[Don_Paterson]

@PhoneBoy 
Hi Dameon,
Just wanted to put this on your radar in case you hear anyone else having problems, which the SK does not cover but still has the import stuck on 4%.
I will update if I get progress but wanted to check if you maybe knew any more on this issue?
Thanks,

Don

[Chris_Atkinson]

Can you confirm the CPUSE build and if there is a JHF applied to the R81.10 instance already?

[Don_Paterson]

I think CPUSE was up-to-date (as of today), 2176, (in at least two of the tests)  and Take 9 applied on top of R81.10 B335
Upgrade Package Tools = 996000341

[JozkoMrkvicka]

The latest Upgrade Package Tools for R81.10 is 996000397 (see sk135172).

The latest Jumbo Take for R81.10 is 45 (see sk175186).

try to update them and then give it another try.

[Don_Paterson]

Edit:
I also tried with Take45 and without any takes.
No time now but will test again soon. The next time will be a clean install or R81.10 and not a CPUSE clean-install (R81.10 over R80.40).
Will follow that with the import attempt.

[Chris_Reinecke1]

Hi Don, do you perhaps have any updates on this issue. We just had the exact same issue migrating from R80.40 to R81.10 using upgrade tools 996000398 on both and sides also trying with and without -l. We are importing into a clean install R81.10 with Jumbo Take 45 installed. The import gets stuck at 4% and then eventually times out after 2 hours. No errors seen in cpm.elg. We do have a TAC case open but was hoping that somebody might have figured this one out. 

[Antec42]

Same problem here. Import gets stuck at 4% and no error logs.

/Marcus

[Chris_Atkinson]

How were the machines first built in your scenario?

Refer:

https://community.checkpoint.com/t5/Management/migrate-server-import-issue-not-proceeding-past-4/m-p... 

[Chris_Reinecke1]

Hi Chris, I have a theory as it seems that all machines with the problem was built using CPUSE. We have built a new test server using the ISO image and installed Jumbo Take 45. Using the same export that originally failed with the same Upgrade Tools, the import was successful. Our first install was on a server built with CPUSE. Today I am going to built another server using CPUSE and then go through the process again. I see that thread was started by Simon who is one of my colleagues, so he is also describing the same issue I am describing in here. I did not see that he started a new thread. 

[Don_Paterson]

Hi Chris,

Update:

I have only been able to get an import to work if the server is installed using the DVD (virtual DVD drive in the VM) and the R81.10 ISO file (Build 335 it is).

I agree that it is the CPUSE clean install that is the problem here, and it blocks the import from working.

The Blink clean install did not work for me.
I did an R81.10 Blink install (no JHFAs), clean install, using CPUSE and the import on that also got stuck at 4%.

@PhoneBoy  to give you an update on this one. It seems it is not an isolated issue and is repeatable and therefore seems to be a bug.

Regards,

Don

[Antec42]

I believe it was first installed as a clean install open server. However, it has since it's first install been "re-installed" with the blink iso through CPUSE. If this qualifies as a CPUSE build I do not know but I would expect so.

/Marcus 

[Chris_Reinecke1 · Accepted solution]

I have some more updates on this. Just completed the re-install of the same server using CPUSE, installer clean-install. Used the same export and imported using the same version upgrade tools. This time I could replicate the issue and it got stuck at 4%.

So the temporary solution in my mind is to NOT make use of CPUSE at this stage to clean-install the box, but rather use ISOmorphic or other external drive options to image the box.

[Antec42]

Good finding! This is the exact scenario I was in. I tried to use the Blink image and did an upgrade instead of clean install and this also worked. But it would still be good to know how we can use the migrate_server command without ending up in this mess again... "Time stealer" to say the least...

[Don_Paterson]

Hi Chris,
I did not get any more time on the issue but will do again next week.
In the meantime I think you are onto the main issue there and I am also dealing with an R80.40 that was CPUSE clean-install using CPUSE.
I did not get a chance to try the old-style clean build but that was/is my next test. Will update you but I think the result will be predictable. 😉
Thanks for sharing.

Regards,

Don

[the_rock]

I know this post is few months old, but wanted to share something I experienced the other day. I had EXACT same situation when importing migrate export customer sent, but I totally forgot when he sent it vua our secure transfer portal, it added their email at the end of the export

example -> file was say called migrate_export_R81.10.tgz and way I got it on the portal said migrate_export_R81.10 (john@companyabcd.com).tgz

Not realizing this, I tried importing, it was stuck at 4% for probably 50 mins, I rebooted the lab server, changed the name of the file and removed his actual email, imported, bam, all good!

Just in case anyone encounters the same in the future...

Andy

[JozkoMrkvicka]

If you tried to import it within the LAB, I would replicate it one more time by adding the email address back. I kind of dont believe the export file name containing brackets, dots and "@" can cause this problem.

EDIT: Is there space before the e-mail in file name? It can be considered as additional parameter for import utility which can confuse it.

migrate_export_R81.10 is first parameter.

(john@companyabcd.com).tgz is second parameter.

[the_rock]

Hey @JozkoMrkvicka ,

Maybe I did not clarify it properly.

What I meant was this...so say if file generated is called migrate_export.tgz, works fine

Say if its called migrate_export@whatever.tgz, works fine

Now, due to secure transfer portal we use, for some odd reason, this seems to happen ONLY with tgz files, when customers send them, it appeands their email at the end of the file, so say file called migrate_export.tgz will "become" migrate_export(johndoe@abcdcompany).tgz ), it adds their email at the end of the file.

In such case, if you try import file with whole name like that, 100% will FAIL, until you remove the email address, along with the brackets, save, re-import, bam, works fine.

Andy

P.S. And again, since you love memes, here it comes lol