There's typically two scenarios presented when there's not enough space on these platforms:

1) Some virtual-chassis cases will still exhibit a high utilization despite following KB31198 [juniper.net].

• For these scenarios a request system zeroize previous to a the software upgrade could work if the switch is running Junos 21.4R1 or newer due to the following PR: https://prsearch.juniper.net/problemreport/PR1533861.
• Also a format install is recommended to bypass the issue.

2) Some virtual-chassis will show low utilization and will still fail to upgrade. For this scenario there’s a workaround I will document below.

When we upgrade a VC, we typically execute it from the Master member and we let it push the bundle onto every other member automatically. This will have Junos create a temporary file named "mchassis-install.tgz" into /var/tmp on every single member of the VC:

{master:0}

root@switch> file list /var/tmp detail | match mchassis

-rw-r--r-- 1 root wheel 357708572 Nov 10 2021 mchassis-install.tgz

This automatically takes away valuable free space from /dev/gpt which is causing a lot of upgrades to fail, so this procedure is not recommended for VC upgrade.

Let's imagine we have a 2 member VC. The Master being FPC0 and the Backup being FPC1.

1) Make a copy of the Junos image on every member you are going to locate it on /tmp folder. Do not use /var/tmp, the reason because it contributes to /dev/gpt/ partition.

Here an example on how to copy the image from Master FPC0 to FPC1:

{master:0}

root@switch> file copy /tmp/junos-arm-32-20.2R3-S3.6.tgz fpc1:/tmp/

2) Now this is key, we will push the bundle one member at a time, using the local image of each member that we just copied in the previous step. Doing this will bypass the storage error.

{master:0}

root@switch> request system software add /tmp/junos-arm-32-20.2R3-S3.6.tgz force no-validate member 0

<snippet> ...

NOTICE: 'pending' set will be activated at next reboot...

{master:0}

root@switch> request session member 1

...

{backup:1}

root@d19-39> request system software add /tmp/junos-arm-32-20.2R3-S3.6.tgz force no-validate member 1

<snippet> ...

NOTICE: 'pending' set will be activated at next reboot...

3) At this point we have pushed the bundle individually and both members are ready for upgrading. Now you can return to the Master and reboot all members together:

{backup:1}

root@switch> request session member 0

<snippet> ...

{master:0}

root@d19-39> request system reboot at now all-members

Reboot the system at now? [yes,no] (no) yes

.....

....

...

..

.