This KB discusses the requirements for upgrading to Junos 24.4 or later for the SRX300, SRX320, SRX340, SRX345, and SRX380. The examples below are from an SRX340, but the process is the same for all the SRX Branch devices. This is valid for up to 25.2. For versions later than 25.5, the device begin on 24.4 or later and this KB will not apply. The addresses only crossing the line between 24.2 and 24.4.For this Junos update, the device file system is being upgraded. The upgrade process is designed to take into account the existing configuration and device state as well as possible in order to preserve the configuration, licenses, certificates, scripts, and IDP databases. All data in /var/log and /var/tmp will be lost. You will need to save any data on the device you wish to keep. With some upgrade methods, the device will be returned to a factory default state and the configuration will have to be re-added at the end of the process.For SRXs in chassis clustering, ISSU/ICU is not supported for this upgrade. Either a simple upgrade (reboot both at the same time) or LICU (minimum downtime) upgrades must be done.
Part 1: Minimum requirements.
Minimum Junos versions for upgrade to 24.4+
You must upgrade from the following Junos versions as a jumping point to 24.4.23.4R2-S3 or later24.2R2 or laterStarting file system requirements.All SRX branch devices use dual root partitioning beginning with 12.1X45. If you are using a device that was originally shipped with 15.1X49, it will have the original dual root partitioning, if it has never been upgraded with the "partition" option. If that is the case, you will get the following error if you try to upgrade to 24.4:root@srx340> request system software add no-copy no-validate /var/tmp/junos-install-srxsme-mips-64-24.4R1.9.tgz ERROR: Device has old partition layout, re-install junos-srxsme* image with 'partition' option to make space for upgradeBefore upgrading to a valid jump version, you can verify the current partitioning. In the new partitioning, /dev/bo0s3f will be ~5GB, and in the case of the SRX380 it will be ~85GB. The SRX380 does not support any Junos version with the old dual root partitioning. See verification steps below.
For SRX300, SRX320, SRX340, and SRX345
This is the old partitioning:root@srx340> start shell root@srx340% df -hFilesystem Size Used Avail Capacity Mounted on/dev/da0s2a 2.4G 434M 1.8G 19% /devfs 1.0K 1.0K 0B 100% /dev/dev/md0 20M 12M 5.7M 68% /junos/cf/packages 2.4G 434M 1.8G 19% /junos/cf/packagesdevfs 1.0K 1.0K 0B 100% /junos/cf/dev/dev/md1 1.4G 1.4G 0B 100% /junos/cf 20M 12M 5.7M 68% /junos/cfdevfs 1.0K 1.0K 0B 100% /junos/dev//cf/packages 2.4G 434M 1.8G 19% /junos/cf/packages1procfs 4.0K 4.0K 0B 100% /proc/dev/bo0s3e 185M 42K 170M 0% /config/dev/bo0s3f 2.1G 1.0G 952M 52% /cf/var/dev/md2 1.0G 109M 840M 11% /mfs/cf/var/jail 2.1G 1.0G 952M 52% /jail/var/cf/var/jails/rest-api 2.1G 1.0G 952M 52% /web-api/vardevfs 1.0K 1.0K 0B 100% /jail/dev/dev/md3 1.8M 4.0K 1.7M 0% /jail/mfsroot@srx340%This is the new partitioning:root@jtac-SRX340% df -hFilesystem Size Used Avail Capacity Mounted on/dev/da0s1a 579M 434M 98M 82% /devfs 1.0K 1.0K 0B 100% /dev/dev/md0 20M 12M 5.7M 68% /junos/cf/packages 579M 434M 98M 82% /junos/cf/packagesdevfs 1.0K 1.0K 0B 100% /junos/cf/dev/dev/md1 1.4G 1.4G 0B 100% /junos/cf 20M 12M 5.7M 68% /junos/cfdevfs 1.0K 1.0K 0B 100% /junos/dev//cf/packages 579M 434M 98M 82% /junos/cf/packages1procfs 4.0K 4.0K 0B 100% /proc/dev/bo0s3e 185M 74K 170M 0% /config/dev/bo0s3f 4.9G 986M 3.6G 80% /cf/var/dev/md2 1.0G 110M 839M 12% /mfs/cf/var/jail 5.0G 3.6G 949M 80% /jail/var/cf/var/jails/rest-api 5.0G 3.6G 949M 80% /web-api/vardevfs 1.0K 1.0K 0B 100% /jail/dev/dev/md3 1.8M 4.0K 1.7M 0% /jail/mfs/dev/altroot 587M 14M 525M 3% /altrootroot@jtac-SRX340%
For the SRX380, you can simply verify that it is dual root with the following command:root@srx380> show system snapshot media internal Information for snapshot on internal (/dev/ad0s1a) (primary)Creation date: Apr 13 09:19:06 2026JUNOS version on snapshot: junos : 23.4R2-S5.5Information for snapshot on internal (/dev/ad0s2a) (backup)Creation date: Sep 29 12:03:10 2025JUNOS version on snapshot: junos : 23.4R2-S5.5
If your SRX has the old partitioning, or if your SRX380 is not dual root, it must be upgraded to the jump version with the "partition" option. If you are already on a valid jump version, but with the old partitioning, you must first re-install to the same version with the partition option before moving forward to Junos 24.4.{primary:node0}root@jtac-SRX340> request system software add no-copy no-validate partition /var/tmp/junos-srxsme-23.4R2-S3.9.tgz Note: If the SRX is already on the later partitioning, it will not cause any harm to use the "partition" option.
Additional requirements
Before upgrade, there must be over 2GB free space on /dev/bo0s3f. The SRX needs this space to create /var/preserve where it will save the current system data such as the configs, certificates, licenses, and scripts for the upgrade.
If you have insufficient free space, you will see the following error:Saving /var/db/appid,certs for srx340tar: /cf/var/upgrade/install.tar: Wrote only 0 of 10240 bytestar: Error is not recoverable: exiting nowERROR: insufficient space for /cf/var/upgrade/install.tar
No-validate must be used as the normal validation process for this will not pass for this upgrade.ERROR: Configuration validation failed with /var/tmp/junos-install-srxsme-mips-64-24.4R1.9.tgz
Part 2: Device backup.
Before upgrading it is very highly recommended that the devices be backed up.
The preferred backup method is to create an image of the SRX3xx to a USB drive. For the SRX300 / SRX320 / SRX340 / SRX345, an 8GB or larger USB drive of a trusted brand is needed for each unit to be backed up. The internal storage on these devices is 8GB. The SRX380 has an internal SSD of 100GB. You may use a 100GB+ thumb drive for the SRX380, or see the end of this section to determine the minimum size of drive that will be required.A USB drive larger than 8GB can be used up to the 2TB support of FAT32. However, the the entire drive will be reserved for the snapshot no matter the size of the thumb drive. This process will create a bootable USB drive that is a complete copy of the entire system as it is now. This USB drive can be used as recovery to restore the SRX to exactly the state that it was when the snapshot was taken.Insert the USB drive into the SRX, or one into each node if this is a cluster. Do not mount the USB drives. This can take over 30 minutes to complete. It will return to the normal CLI prompt when it is completed.root@srx340> request system snapshot media usb
Clearing current label...Partitioning usb media (/dev/da1) ...Partitions on snapshot: Partition Mountpoint Size Snapshot argument s1a /altroot 579M none s2a / 587M none s3e /config 185M none s3f /var 4.9G none s4a /recovery/software 324M none s4e /recovery/state 15M noneCopying '/dev/da0s1a' to '/dev/da1s1a' .. (this may take a few minutes)Copying '/dev/da0s2a' to '/dev/da1s2a' .. (this may take a few minutes)Copying '/dev/da0s3e' to '/dev/da1s3e' .. (this may take a few minutes)Copying '/dev/da0s3f' to '/dev/da1s3f' .. (this may take a few minutes)Copying '/dev/da0s4e' to '/dev/da1s4e' .. (this may take a few minutes)Copying '/dev/da0s4a' to '/dev/da1s4a' .. (this may take a few minutes)The following filesystems were archived: /altroot / /config /var /recovery/state /recovery/softwareIn cluster, the snapshot command will be run on both SRXs, so it will be necessary to have the USB drive plugged into both SRXs before you begin.
{primary:node0}root@srx340> request system snapshot media usb node0:--------------------------------------------------------------------------Clearing current label...Partitioning usb media (/dev/da1) ...Partitions on snapshot: Partition Mountpoint Size Snapshot argument s1a /altroot 579M none s2a / 587M none s3e /config 185M none s3f /var 4.9G none s4a /recovery/software 324M none s4e /recovery/state 15M noneCopying '/dev/da0s1a' to '/dev/da1s1a' .. (this may take a few minutes)Copying '/dev/da0s2a' to '/dev/da1s2a' .. (this may take a few minutes)Copying '/dev/da0s3e' to '/dev/da1s3e' .. (this may take a few minutes)Copying '/dev/da0s3f' to '/dev/da1s3f' .. (this may take a few minutes)Copying '/dev/da0s4e' to '/dev/da1s4e' .. (this may take a few minutes)Copying '/dev/da0s4a' to '/dev/da1s4a' .. (this may take a few minutes)The following filesystems were archived: /altroot / /config /var /recovery/state /recovery/softwarenode1:--------------------------------------------------------------------------Clearing current label...Partitioning usb media (/dev/da1) ...Partitions on snapshot: Partition Mountpoint Size Snapshot argument s1a /altroot 579M none s2a / 587M none s3e /config 185M none s3f /var 4.9G none s4a /recovery/software 324M none s4e /recovery/state 15M noneCopying '/dev/da0s1a' to '/dev/da1s1a' .. (this may take a few minutes)Copying '/dev/da0s2a' to '/dev/da1s2a' .. (this may take a few minutes)Copying '/dev/da0s3e' to '/dev/da1s3e' .. (this may take a few minutes)Copying '/dev/da0s3f' to '/dev/da1s3f' .. (this may take a few minutes)Copying '/dev/da0s4e' to '/dev/da1s4e' .. (this may take a few minutes)Copying '/dev/da0s4a' to '/dev/da1s4a' .. (this may take a few minutes)The following filesystems were archived: /altroot / /config /var /recovery/state /recovery/softwareOnce this is completed, remove the USB drives and label them appropriately. It does not need to be unmounted.
Note for USB drive size to be used for backup for the SRX380.
The SRX380 uses a 100GB internal SSD. That said, it is extremely rare for the SRX380 to use even 10% of that space. Therefore, it is typically not necessary to use a 100GB+ USB drive. Given the large storage size, it is highly recommended that any unnecessary files be deleted before backup as this can significantly increase the time required to create the backup. The backup procedure will take more than 1.5 hours at 30GB usage on /dev/bo0s3f and over 3 hours at 60GB usage, significantly higher than the typical ~15-30 minutes.To determine the minimum USB drive size, we need to check the usage of /dev/bo0s3f (after removing any unnecessary files). Next, we need to verify the usable size of the USB drive being used. To determine the usable size of your USB drive, plug it into the SRX. If you are connected to the serial console this will be printed to the console. If not, you can go into shell and check dmesg.In the following example, the USB drive, although it is sold as a 32GB drive has 29GB usable space.
user@srx380> start shell user rootPassword:root@srx380% dmesg | grep da0:da0 at umass-sim0 bus 0 target 0 lun 0da0: <USB SanDisk 3.2Gen1 1.00> Removable Direct Access SCSI-6 device da0: 80.000MB/s transfersda0: 29358MB (60125184 512 byte sectors: 255H 63S/T 3742C)The minimum safe usable USB drive size required is 8GB + the used size of /dev/bo0s3f.EXAMPLE 1: This SRX380 has used only 12MB on /dev/da0s3f. 8GB+ 12MB, is basically just 8GB.root@srx380> show system storage Filesystem Size Used Avail Capacity Mounted on/dev/ad0s1a 590M 435M 108M 80% /devfs 1.0K 1.0K 0B 100% /dev/dev/md0 20M 12M 5.7M 68% /junos/cf/packages 590M 435M 108M 80% /junos/cf/packagesdevfs 1.0K 1.0K 0B 100% /junos/cf/dev/dev/md1 1.5G 1.5G 0B 100% /junos/cf 20M 12M 5.7M 68% /junos/cfdevfs 1.0K 1.0K 0B 100% /junos/dev//cf/packages 590M 435M 108M 80% /junos/cf/packages1procfs 4.0K 4.0K 0B 100% /proc/dev/bo0s3e 2.3G 52K 2.1G 0% /config/dev/bo0s3f 85G 12M 78G 0% /cf/var/dev/md2 1.0G 107M 842M 11% /mfs/cf/var/jail 85G 12M 78G 0% /jail/var/cf/var/jails/rest-api 85G 12M 78G 0% /web-api/vardevfs 1.0K 1.0K 0B 100% /jail/dev/dev/md3 1.8M 4.0K 1.7M 0% /jail/mfs
EXAMPLE2: This SRX380 has used 30GB of space in /dev/bo0s3f. 8GB+ 30GB, the drive must have a usable size of 38GB or more.root@srx380> show system storage Filesystem Size Used Avail Capacity Mounted on/dev/ad0s2a 590M 437M 106M 80% /devfs 1.0K 1.0K 0B 100% /dev/dev/md0 20M 12M 5.7M 68% /junos/cf/packages 590M 437M 106M 80% /junos/cf/packagesdevfs 1.0K 1.0K 0B 100% /junos/cf/dev/dev/md1 1.5G 1.5G 0B 100% /junos/cf 20M 12M 5.7M 68% /junos/cfdevfs 1.0K 1.0K 0B 100% /junos/dev//cf/packages 590M 437M 106M 80% /junos/cf/packages1procfs 4.0K 4.0K 0B 100% /proc/dev/bo0s3e 2.3G 42K 2.1G 0% /config/dev/bo0s3f 85G 30G 48G 39% /cf/var/dev/md2 1.0G 107M 842M 11% /mfs/cf/var/jail 85G 30G 48G 39% /jail/var/cf/var/jails/rest-api 85G 30G 48G 39% /web-api/vardevfs 1.0K 1.0K 0B 100% /jail/dev/dev/md3 1.8M 4.0K 1.7M 0% /jail/mfsIf you use a USB drive that is too small, it will write as much of /dev/bo0s3f as it can. Once the s3f partition is full it will move on to the next. Any additional data will be lost as there was not enough space on the USB drive. Most of the time what is lost will not be critical data, such as excessive logging in /var/log or extra Junos upgrade images or varlog archives in /var/tmp. However, it may also lose important data such as what is in /var/db. So although it completes, and appears to be okay, it may be a problematic backup.For example, this is the result of backup up the above Example 2 SRX380 to the USB drive with 29GB usable space. We see that the system always creates the most critical partitions s1a and s2a with their default sizes. Next, s3e, s4a, and s4e have slightly variable sizes depending on the USB drive size. Finally, whatever is left over is assigned to s3f. In the current example, with a 29GB drive the leftover assigned to s3f is 25GB.Given that our /dev/bo0s3f usage is 30GB, we are going to lose 5GB of data, even though it will complete anyway.
root@srx380> request system snapshot media usb Jun 05 09:32:18Clearing current label...Partitioning usb media (/dev/da0) ...Partitions on snapshot:
Partition Mountpoint Size Snapshot argument s1a /altroot 579M none s2a / 587M none s3e /config 718M none s3f /var 25G none s4a /recovery/software 895M none s4e /recovery/state 85M noneCopying '/dev/ad0s1a' to '/dev/da0s1a' .. (this may take a few minutes)Copying '/dev/ad0s2a' to '/dev/da0s2a' .. (this may take a few minutes)Copying '/dev/ad0s3e' to '/dev/da0s3e' .. (this may take a few minutes)Copying '/dev/ad0s3f' to '/dev/da0s3f' .. (this may take a few minutes)Copying '/dev/ad0s4a' to '/dev/da0s4a' .. (this may take a few minutes)The following filesystems were archived: /altroot / /config /var /recovery/state /recovery/software
Note that when a 64GB (58680MB usable) drive is used, s3f is partitioned to 51G and s3e, s4a, and s4e are increased slightly leaving 51GB for s3f.root@srx380> request system snapshot media usb Clearing current label...Partitioning usb media (/dev/da0) Partition Mountpoint Size Snapshot argument s1a / 579M none s2a /altroot 587M none s3e /config 1.4G none s3f /var 51G none s4a /recovery/software 1.6G none s4e /recovery/state 170M none
You can track the progress of the backup process with a separate SSH session by checking the system storage when the "Copying" messages begin as it temporarily mounts each partition for to copy the backup data.
root@srx380> request system snapshot media usb Jun 05 11:52:12. <<<< backup start time for Example 2Clearing current label...Partitioning usb media (/dev/da0) ... Partition Mountpoint Size Snapshot argument s1a /altroot 579M none s2a / 587M none s3e /config 718M none s3f /var 25G none s4a /recovery/software 895M none s4e /recovery/state 85M noneCopying '/dev/ad0s1a' to '/dev/da0s1a' .. (this may take a few minutes)Copying '/dev/ad0s2a' to '/dev/da0s2a' .. (this may take a few minutes)Copying '/dev/ad0s3e' to '/dev/da0s3e' .. (this may take a few minutes)Copying '/dev/ad0s3f' to '/dev/da0s3f' .. (this may take a few minutes)Copying '/dev/ad0s4e' to '/dev/da0s4e' .. (this may take a few minutes)Copying '/dev/ad0s4a' to '/dev/da0s4a' .. (this may take a few minutes)The following filesystems were archived: /altroot / /config /var /recovery/state /recovery/software(separate SSH session)root@srx380> show system storage | match snap-tmp Jun 05 11:57:49/dev/da0s1a 579M 79M 454M 15% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682
You can set it to refresh. However, it is recommended to not set the refresh value to less than three minutes as it will take a long time to complete, even with a reasonably sized backup (~15-30 minutes). In this case with 30GB used on da0s3f (25GB copied) the total time was from 11:52 to 13:31, over 1.5 hours.
root@srx380> show system storage | match snap-tmp | refresh 180 Jun 05 12:00:21---(refreshed at 2026-06-05 12:00:21 PDT)---/dev/da0s2a 587M 212M 328M 39% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 12:03:21 PDT)---/dev/da0s3f 25G 310M 22G 1% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 12:06:21 PDT)---/dev/da0s3f 25G 1.1G 22G 5% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682
If the da0s3f partition is too large it will eventually give up when it is full and then complete the last partition. Note that data from /var/db may not have been retained in this case. It is recommended to free up space to fit your USB drive or use one large enough to contain everything.---(refreshed at 2026-06-05 13:15:21 PDT)---/dev/da0s3f 25G 22G 1014M 96% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:18:21 PDT)---/dev/da0s3f 25G 23G 45M 100% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:21:21 PDT)---/dev/da0s3f 25G 24G -889.6M 104% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:24:21 PDT)---/dev/da0s3f 25G 24G -1.8G 108% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:27:21 PDT)---/dev/da0s3f 25G 25G -2.0G 109% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:30:21 PDT)---/dev/da0s3f 25G 25G -2.0G 109% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682<...>---(refreshed at 2026-06-05 13:31:22 PDT)---/dev/da0s3f 25G 25G -2.0G 109% /mfs/tmp/snap-tmp.44682/mnt_snap_tgt.44682---(refreshed at 2026-06-05 13:31:27 PDT)--- <<< Backup end time for Example 2.---(refreshed at 2026-06-05 13:31:32 PDT)---
root@srx380> show system snapshot media usb Jun 05 14:10:23Information for snapshot on usb (/dev/da0s1a) (backup)Creation date: Jun 5 11:59:21 2026JUNOS version on snapshot: junos : 23.4R2-S7.4Information for snapshot on usb (/dev/da0s2a) (primary)Creation date: Jun 5 12:01:21 2026JUNOS version on snapshot: junos : 23.4R2-S7.4
root@srx380>
Additionally, manual backups of the configuration, licenses, certificates, and scripts can be done.As with any upgrade, we recommend that there be serial console access available, as well as someone on site to address any eventuality.
Upgrade process:
Note: Be sure that the SRX(s) does not lose power during this process or the device may have to be recovered via bootable USB or via the boot loader.
Instructions for cluster:
Note: For LICU (minimal downtime) the way to manage the interfaces and traffic cutover as the same as described in KB17947 [juniper.net] and can be integrated into this upgrade. Please coordinate with your account team for any assistance with preparing this procedure for your environment.Copy the 24.4 Junos image to the SRX /var/tmp directory of both nodes, then run the upgrade command with no-validate. The upgrade command is the standard command with no-validate. This should be done on both nodes.
{primary:node0}root@srx340> request system software add no-validate /var/tmp/junos-install-srxsme-mips-64-24.4R1.9.tgz
{secondary:node1}root@srx340> request system software add no-validate /var/tmp/junos-install-srxsme-mips-64-24.4R1.9.tgz
Once the upgrade process is complete. Reboot both nodes.On reboot, the SRX file system will be rewritten. During the upgrade process It will reboot again to complete the Junos installation and transfer the preserved data. The whole upgrade process should take about 30-60 minutes, depending on how much preserve data is saved.When Junos boots up, we can see the file system will be different.
{primary:node0}root@srx340> show system storage node0:--------------------------------------------------------------------------Filesystem Size Used Avail Capacity Mounted on/dev/gpt/junos 5.3G 932M 4.0G 19% /.mounttmpfs 1.1G 20K 1.1G 0% /.mount/tmp/var/jails/rest-api 5.3G 932M 4.0G 19% /.mount/packages/mnt/junos-runtime/web-api/vartmpfs 668M 4.4M 664M 1% /.mount/mfsnode1:--------------------------------------------------------------------------Filesystem Size Used Avail Capacity Mounted on/dev/gpt/junos 5.3G 949M 4.0G 19% /.mounttmpfs 1.4G 40K 1.4G 0% /.mount/tmp/var/jails/rest-api 5.3G 949M 4.0G 19% /.mount/packages/mnt/junos-runtime/web-api/vartmpfs 668M 4.2M 664M 1% /.mount/mfs{primary:node0}root@srx340> Upgrade process for standalone:
Copy the 24.4 Junos image to the SRX /var/tmp directory, then run the upgrade command with no-validate.
root@srx340> request system software add no-validate /var/tmp/junos-install-srxsme-mips-64-24.4R1.9.tgz
Once the upgrade process is complete, reboot the SRX. Take care that the SRX does not lose power during the upgrade or you may have to recover via the boot loader or bootable USB drive.
Upgrade process via loader via TFTP or non-bootable USB drive:
WARNING: You must back up the configuration, etc before proceeding. This install process will result in all data being wiped from the SRX. It will be set to a factory default condition. This was not normally the case for an upgrade via the loader, but for 24.4 and later, install via loader will always result in a system wipe back to factory default.
When installing via the boot loader to Junos 24.4 or later, the SRX uses a new file naming scheme, which aligns with other Junos platforms. Instead of using the typical junos-srxsme-24.xRx-Sx.tgz, the file name will instead need to be junos-install-media-net-srxsme-mips-64-24.xRx-Sx.tgz. It must be the file that includes "net" whether the install will be from network TFTP or a locally plugged in USB drive.
For example:
From TFTPloader> install tftp://10.0.113.2/junos-install-media-net-srxsme-mips-64-24.4R1.9.tgz
For more detail on upgrading from TFTP:https://www.juniper.net/documentation/us/en/software/junos/junos-install-upgrade/topics/topic-map/install-software-on-srx.html#id-installing-junos-os-on-srx-series-devices-from-the-boot-loader-using-a-tftp-server
From a USB driveloader> install file:///junos-install-media-net-srxsme-mips-64-24.4R1.9.tgz
For more detail on upgrading via USB from loader:https://www.juniper.net/documentation/us/en/software/junos/junos-install-upgrade/topics/topic-map/install-software-on-srx.html#id-installing-junos-os-on-srx-series-devices-from-the-boot-loader-using-a-usb-storage-device
Upgrade process via bootable USB drive:
Note: As is always the case with the bootable USB drive, all data on the SRX will lost and replaced with the data on the bootable USB drive. The "install-media-usb" images will overwrite the SRX to a factory default condition.
The file to use to create the bootable USB drive will have "install-media-usb" in the name, not to be confused with "install-media-net".
Windows:
First unzip the file so that it is .img and not .gz. You may need to check the file properties to verify as Windows will hide file extensions.
Using third party software such as Rufus, write the img file to the USB drive. Please refer to the documentation of the third party software chosen for precise instructions.
Unix based operating systems such as MacOS, Linux, any Junos device, etc.
For any Unix based system, we can use the basic tool dd to write the image to the USB drive.
root@jtac-SRX340:/var/tmp # gunzip junos-install-media-usb-srxsme-mips-64-24.4R1.9.img.gzroot@jtac-SRX340:/var/tmp # ls -l junos-*-rw------- 1 root wheel 700596224 Nov 22 10:29 junos-install-media-usb-srxsme-mips-64-24.4R1.9.imgroot@jtac-SRX340:/var/tmp #
If you run dd from an SRX you must make sure that the USB thumb drive is NOT mounted or the SRX may crash.
The dd version on srx3xx devices earlier than 24.4 do not support the "status=progress" option. Be certain the the output is /dev/da1
root@jtac-SRX340:/var/tmp # dd if=/var/tmp/junos-install-media-usb-srxsme-mips-64-24.4R1.9.img of=/dev/da1 bs=1m status=progressdd: unknown operand status
root@jtac-SRX340:/var/tmp # dd if=/var/tmp/junos-install-media-usb-srxsme-mips-64-24.4R1.9.img of=/dev/da1 bs=1m668+1 records in668+1 records out700596224 bytes transferred in 28.459923 secs (24616940 bytes/sec)
This is an example of running this from MacOS. You can verify the correct USB drive under Applications > Utilities > Disk Utility. In this case, the inserted USB drive is disk4s1. We remove the "s1" part and use just disk4.
user@user-mbp Downloads % dd if=junos-install-media-usb-srxsme-mips-64-24.4R1.9.img of=disk4 bs=1m status=progress 681574400 bytes (682 MB, 650 MiB) transferred 28.004s, 24 MB/s668+1 records in668+1 records out700596224 bytes transferred in 28.723374 secs (24391154 bytes/sec)user@user-mbp Downloads %
Once the bootable USB thumb drive has been created, insert it into the SRX, but do not mount it. Then in the cli, reboot the SRX, specifying USB.
root@jtac-SRX340> request system reboot media usbReboot the system ? [yes,no] (no) yes
Upgrade process via USB Autoinstallation process.
The full detailed instructions can be found in KB23882 [juniper.net].
Note: For the upgrade to 24.4, the SRX will be wiped out and returned to a factory default condition. You must make backups of the configuration, etc. before upgrade.
The USB drive must be properly prepared first.
When you plug in the USB drive, in the serial console you will see the following:
root@srx340> umass1: USB SanDisk 3.2Gen1, rev 3.20/1.00, addr 2da1 at umass-sim1 bus 1 target 0 lun 0da1: <USB SanDisk 3.2Gen1 1.00> Removable Direct Access SCSI-6 device da1: 80.000MB/s transfersda1: 29340MB (60088320 512 byte sectors: 255H 63S/T 3740C)
From the messages logs, you can verify that the device is ready:
Nov 22 18:01:00 a01-16 usb_autoinstall: Device info: /dev/da1Nov 22 18:01:00 a01-16 usb_autoinstall: running srxsmec autoinstallNov 22 18:01:12 a01-16 usb_autoinstall: Detected the autoinstall USB keyNov 22 18:01:12 a01-16 usb_autoinstall: Waiting for the user to press the config button...
When the reset config button is pressed, you will see the following in the messages log:
Nov 22 18:02:43 a01-16 usb_autoinstall: USB Image: bsdx_image:yes bsd6_image:Nov 22 18:02:43 a01-16 usb_autoinstall: Autoinstallation process started...Nov 22 18:02:43 a01-16 usb_autoinstall: bsd6:yes bsdx_image:yes
Then in the serial console you will see the upgrade process begin.
Installing package '/tmp/mnt_usb_dev/junos-install-srxsme-mips-64-24.4R1.9.tgz' ... Verified manifest signed by PackageDevelopmentECP256_2024 method ECDSA256+SHA256
When the install preparation process is done, you will see the following message printed to serial console:
WARNING: A reboot is required to complete installation.Saving package file in /var/sw/pkg/junos-install-20241120.120132__cd-builder_release_244_throttle.tgz ...Saving state for rollback ... USB image auto-installation complete, waiting for the USB removal
And in the messages logs:
Nov 22 18:15:22 a01-16 /kernel: WARNING: A reboot is required to complete installation.Nov 22 18:15:25 a01-16 /kernel: Saving package file in /var/sw/pkg/junos-install-64-24.4R1.9.tgz ...Nov 22 18:19:00 a01-16 /kernel: Saving state for rollback ...Nov 22 18:19:01 a01-16 usb_autoinstall: Successfully completed the autoinstallation process!Nov 22 18:19:01 a01-16 usb_autoinstall: Config file not found. Cannot perform config update.Nov 22 18:19:01 a01-16 usb_autoinstall: Waiting for the USB removalNov 22 18:19:01 a01-16 /kernel: USB image auto-installation complete, waiting for the USB removal
Note: Do not simply reboot the SRX. You must unplug the USB drive and allow it to reboot itself.
As seen from serial console:
umass1: at uhub1 port 2 (addr 2) disconnected(da1:umass-sim1:1:0:0): lost device(da1:umass-sim1:1:0:0): removing device entryumass1: detachedNov 22 18:21:59 init: system-health-management (PID 2340) terminate signal 15 sentNWaiting (max 60 seconds) for system process `vnlru_mem' to stop...doneWaiting (max 60 seconds) for system process `vnlru' to stop...doneWaiting (max 60 seconds) for system process `bufdaemon' to stop...doneWaiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...0 0 0 0 done
syncing disks... All buffers synced.Uptime: 1h43m40sRebooting...cpu_reset: Stopping other CPUs
Rollback
Note: "request system software rollback" is not supported from 24.4 to previous versions.
Rollback using the bootable recovery USB thumb drive.
If rolling back to the previous version is deemed necessary, this would typically be due to some sort of problem. Therefore, the best way to ensure nothing to do with the upgrade will be carried back to the previous version is to use the snapshot created before the upgrade began.
Insert the bootable USB drive created before upgrade to 24.4. Then reboot from USB. The "media" option is no longer present in 24.4+.
root@srx340> request system reboot usb
For cluster, insert the appropriate USB drive into each node and run the reboot on both nodes individually, but at the same time.
The SRX will boot from the USB drive and will appear to be the same as it was before upgrade to 24.4. However, the device will still be running from the external USB drive.
login: rootPassword:
--- JUNOS 23.4R2-S3.9 built 2024-11-19 06:58:13 UTC------ NOTICE: System is running on alternate media device (/dev/da1s1a).---
root@jtac-SRX340-r017-old> show system storage Filesystem Size Used Avail Capacity Mounted on/dev/da1s1a 579M 435M 98M 82% /
The internal drive is da0. /dev/da0s1a or /dev/da0s2a.
To re-image the internal drive of the SRX from the USB thumb drive, run the following command. In cluster, this should execute on both nodes. If there is a clustering issue, it may be necessary to run this on each node individually.
root@jtac-SRX340> request system snapshot media internal Clearing current label...Partitioning internal media (/dev/da0) ...Partitions on snapshot:
Partition Mountpoint Size Snapshot argument s1a / 579M none s2a /altroot 587M none s3e /config 185M none s3f /var 4.9G none s4a /recovery/software 316M none s4e /recovery/state 15M noneCopying '/dev/da1s1a' to '/dev/da0s1a' .. (this may take a few minutes)Copying '/dev/da1s2a' to '/dev/da0s2a' .. (this may take a few minutes)Copying '/dev/da1s3e' to '/dev/da0s3e' .. (this may take a few minutes)Copying '/dev/da1s3f' to '/dev/da0s3f' .. (this may take a few minutes)Copying '/dev/da1s4e' to '/dev/da0s4e' .. (this may take a few minutes)Copying '/dev/da1s4a' to '/dev/da0s4a' .. (this may take a few minutes)The following filesystems were archived: / /altroot /config /var /recovery/state /recovery/software
root@jtac-SRX340>
As soon as it completes, power off the SRX, remove the USB drive, and then power it back on. Do not remove the USB drive until it is powered off or the USB drive may be corrupted and no longer usable for recovery.
root@jtac-SRX340> request system power-off Power Off the system ? [yes,no] (no) yes
After booting back up, there is no warning about alternate media, and we see we are running from /dev/da0.
root@jtac-SRX340> show system storage Filesystem Size Used Avail Capacity Mounted on/dev/da0s1a 579M 435M 98M 82% /
If restoring from a previous snapshot is not an option, the downgrade process back to the jump version will be the same as the procedure that was done to upgrade to the jump version.
You must use the reboot option when downgrading or it will abort.
root@jtac-SRX340-r017-old> request system software add /var/tmp/junos-srxsme-23.4R2-S3.9.tgz reboot
Downgrading via loader TFTP or USB will also be the same, and again, this downgrade will return the SRX to a factory default state.
USBloader> install file:///junos-srxsme-23.4R2-S3.9.tgz
TFTPloader> install tftp://10.0.113.2/junos-srxsme-23.4R2-S3.9.tgz
Downgrading via USB Autoinstallation will also again return the SRX to factory defaults.
2024-12-24: First public posting of this article.2024-12-26: Minor typos and formatting.2026-04-16: Added clarification for SRX380 partitioning.2026-06-05: Added clarification for SRX380 device backup.