Description

The commit configuration mode command enables you to save the Junos OS configuration changes to the configuration database and to activate the configuration on the device. The device configuration is saved using a commit model—a candidate configuration is modified as desired and then committed to the system. When a configuration is committed, the device checks the configuration for syntax errors, and if no errors are found, the configuration is saved as  juniper.conf.gz  and activated.

This document explains steps to follow when the user runs into 'error: patch generation error - not syncing patch​' while committing a configuration. Since this error prevents the user from making any successful configuration change until resolved, this document will be very helpful to follow.

Symptoms

Commit Error:

user@host# commit 
re0:
error: patch generation error - not syncing patch
re1:
configuration check succeeds

Solution

  1. Step 1: Mastership Switch:

    In the case of a dual RE system, identify the RE on which the error is seen. If the error is seen on the primary, switch mastership temporarily for troubleshooting by ensuring that the current backup is fully efficient to take over.
    A Referenced Link helps you navigate to the command to be used to achieve a mastership switch. 

  2. Verify active alarms for RE:

    user@host> show chassis alarms

  3. Verify the recent core dumps:

    user@host> show system core-dumps
    /var/crash/*core*: No such file or directory
    -rw-------  1 root  wheel  731353088 Apr 21 11:52 /var/tmp/commitd.core.0
    /var/tmp/pics/*core*: No such file or directory
    /var/crash/kernel.*: No such file or directory
    total files: 1

    If there is a core file generated( example core file displayed above ), please jump to Step 9.

  4. Verify the boot list:

    Login as a root user 
    {BACKUP.EN_US}
root@host> start shell                                       
% sysctl -a | grep bootdev
machdep.currbootdev: compact-flash
machdep.nextbootdev: usb
machdep.bootdevs: usb,compact-flash,disk1,disk2,lan              
%

    An ideal boot list will display USB, compact flash, and disks( 1 or 2 depending on RE type). 

    To identify the storage detected on the RE, you can check the output for " show chassis hardware detail"

    Example: 
    root@jtac> show chassis hardware detail
Hardware inventory:
Item             Version  Part number  Serial number     Description
<snip>
Routing Engine 1 REV xx   7xxxxxxx2   9xxxxxxxxxx        RE-S-1800x4
  ad0    3998 MB  VTxxxxxxxxxxxxx2     4xxxxxxxxx        Compact Flash
  ad1   28496 MB  Stoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2xxx Disk 1 
  ad2   28496 MB  Stoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2xxx Disk 2

    In case something is missing from your boot list, you might want to reboot the router in order to allow the boot of all the storage units again. Ensure you do not reboot the router when it is in the primary role.

  5. Check storage:

    Type " show system storage ". Check for " /var " and identify the available storage associated with it.

    root@host> show system storage no-forwarding

    Filesystem              Size       Used      Avail  Capacity   Mounted on
    /dev/da0s1a             904M       264M       567M       32%  /
    devfs                   1.0K       1.0K         0B      100%  /dev
    /dev/md0                 67M        67M         0B      100%  /packages/mnt/jbase
    /dev/md1                310M       310M         0B      100%  /packages/mnt/jkernel-ppc-16.1R7-S1.2
    /dev/md2                181M       181M         0B      100%  /packages/mnt/jpfe-MX104-16.1R7-S1.2
    /dev/md3                 13M        13M         0B      100%  /packages/mnt/jdocs-16.1R7-S1.2
    /dev/md4                153M       153M         0B      100%  /packages/mnt/jroute-ppc-16.1R7-S1.2
    /dev/md5                 15M        15M         0B      100%  /packages/mnt/jcrypto-ppc-16.1R7-S1.2
    /dev/md6                 21M        21M         0B      100%  /packages/mnt/jcrypto-dp-support-16.1R7-S1.2
    /dev/md7                276K       276K         0B      100%  /packages/mnt/jmacsec-16.1R7-S1.2
    /dev/md8                4.3M       4.3M         0B      100%  /packages/mnt/jsd-powerpc-16.1R7-S1.2-jet-1
    /dev/md9                6.6M       6.6M         0B      100%  /packages/mnt/jsdn-powerpc-16.1R7-S1.2
    /dev/md10                27M        27M         0B      100%  /packages/mnt/jweb-ppc-16.1R7-S1.2
    /dev/md11                14M        14M         0B      100%  /packages/mnt/py-base-powerpc-16.1R7-S1.2
    /dev/md12               6.8M       6.8M         0B      100%  /packages/mnt/py-extensions-powerpc-16.1R7-S1.2
    /dev/md13              1008M       8.0K       927M        0%  /tmp
    /dev/md14              1008M        12M       915M        1%  /mfs
    /dev/da0s1e             100M        58K        92M        0%  /config
    procfs                  4.0K       4.0K         0B      100%  /proc
    /dev/da0s1f             5.4G       1.8G       3.1G       37%  /var   <-- /var partition                                   
    /var/jails/rest-api       5.4G       1.8G       3.1G     37%  /packages/mnt/jroute-ppc-16.1R7-S1.2/web-api/var
    /var/jail               5.4G       1.8G       3.1G       37%  /packages/mnt/jweb-ppc-16.1R7-S1.2/jail/var
    /var/log                5.4G       1.8G       3.1G       37%  /packages/mnt/jweb-ppc-16.1R7-S1.2/jail/var/log
    devfs                   1.0K       1.0K         0B      100%  /packages/mnt/jweb-ppc-16.1R7-S1.2/jail/dev

    If the storage space is very low, perform a " request system storage cleanup ". For more details on cleanup, refer to the technical documentation on  request system storage.

    Ensure that you perform a " request system storage cleanup dry-run" first. After verifying all the files to be deleted, go ahead with a cleanup. Usually, core dumps and old JunOS images occupy lot of space. Once the storage is freed up, proceed to perform a dummy commit and check.​

  6. Zeroize the RE:

    Take a backup copy of the existing configuration:

    user@host> show configuration |display set |no-more 

    Also, save a snapshot:

    user@host> request system snapshot

    Zeroize the backup routing engine by running the command below from the backup RE:

    user@host> request system zeroize 

  7. Verify commit-full:

    A 'commit' (performed after configuration changes) checks only the corresponding daemons. However, the 'commit full' action requires all the daemons to check and evaluate the new configuration.  A 'commit full' is useful for if you get an error with a commit or when you've changed the config significantly.

    Note: In case, if you have some uncommitted config on your router, please use the below command to check and then proceed if its good to execute. All the daemons will be evaluated. In this scenario, as a zeroize would be performed, there would be no uncommitted changes.

    user@host# commit full | display detail

  8. Reseat RE:

    If the above steps do not help get rid of the error, manually power cycle the RE by ensuring console connectivity to it. Once it boots back up, check if the issue resolves. If not, move to Step 9.

  9. This might be a hardware or software (in presence of core file) issue with the RE. Please open a case with JTAC for further investigation

Related Information