Auto-commit blocking changes - auto-commit scheduled in future

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Auto-commit blocking changes - auto-commit scheduled in future

L2 Linker

Hi,

Currently cannot upgrade a new pa820 (10.1.4), its auto-commit is set to run tomorrow and blocking any updates or current config commits.

 

Does not stop when using 'stop job' from GUI or clear job CLI.

 

Enqueued Dequeued ID PositionInQ Type Status Result Completed
------------------------------------------------------------------------------------------------------------------------------------------
2022/04/27 17:50:53 17:50:53 1 AutoCom ACT PEND 0%
2022/04/26 18:05:50 18:05:50 3 Downld FIN OK 18:06:00
2022/04/26 18:00:46 18:00:46 2 Downld FIN OK 18:01:35

 

 

Anyway to halt, remove this job, tried not using NTP time and changing date, but seems a little excessive, and didn't work, cannot commit the NTP removal. I am new to PA's.     Should note this is a HA pair, but the pairing is currently broken.

 

Thanks

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@orbcomm,

The auto commit is essentially what gives your box a valid configuration upon start-up. Without that finishing your box doesn't actually have an active configuration, the GUI is just displaying the candidate-config. When you run show jobs id 1 what's the actual status detail for the job? 

 

Steps I would personally take:
1. Since you have a pending autocommit and not a failed commit, you can just try restarting the box and see if it happens again. If it starts up normally then all is good.

2. If it hangs in pending again, you can try clearing the job clear job id 1 and running commit force to see if that actually commits successfully.

3. If none of that works, take a technical support dump and download it so you have the logs to analyze for the failure. Then open a ticket with TAC.

 

If you can't wait for this device to be operational, you can always revert to the previous partition to "undo" the upgrade. 

1. Run debug swm status and make sure that sysroot0 or sysroot1 is in the REVERTABLE state. The other should show as RUNNING-ACTIVE.

2. Run debug swm revert to go back to the previous partition so the device is at least functional again.

 

 

Since your new to PAN, it probably isn't a bad idea to list out how you did the upgrade procedure either (from what version to 10.1.4 did you upgrade, what was your upgrade path?). It's possible that you did something improperly in the upgrade that can cause autocommit issues. 

View solution in original post

2 REPLIES 2

Cyber Elite
Cyber Elite

@orbcomm,

The auto commit is essentially what gives your box a valid configuration upon start-up. Without that finishing your box doesn't actually have an active configuration, the GUI is just displaying the candidate-config. When you run show jobs id 1 what's the actual status detail for the job? 

 

Steps I would personally take:
1. Since you have a pending autocommit and not a failed commit, you can just try restarting the box and see if it happens again. If it starts up normally then all is good.

2. If it hangs in pending again, you can try clearing the job clear job id 1 and running commit force to see if that actually commits successfully.

3. If none of that works, take a technical support dump and download it so you have the logs to analyze for the failure. Then open a ticket with TAC.

 

If you can't wait for this device to be operational, you can always revert to the previous partition to "undo" the upgrade. 

1. Run debug swm status and make sure that sysroot0 or sysroot1 is in the REVERTABLE state. The other should show as RUNNING-ACTIVE.

2. Run debug swm revert to go back to the previous partition so the device is at least functional again.

 

 

Since your new to PAN, it probably isn't a bad idea to list out how you did the upgrade procedure either (from what version to 10.1.4 did you upgrade, what was your upgrade path?). It's possible that you did something improperly in the upgrade that can cause autocommit issues. 

L2 Linker

@BPryThanks for the feedback, the second reboot did the job, auto-commit completed and HA pairing is back up running.  Your explanation about auto-commits for a valid active config and control plane make sense, will continue my research.

 

Regards

  • 1 accepted solution
  • 4843 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!