bonjour cpr0
I am surprised that they do this to you right out of the box. I believe at least the first time I upgraded them using a similar ztp setup it worked fine. But that was a while ago.
I have had to install images on a number of EX2300 , and been confronted with the space issue. Here are the 2 tricks I developped and that work especially well on switches that have been used and are not brand new.
1) I have a bunch of autoboot usb keys with an old Image. I'll line up 10 switches, power them up , connect the vme (mgmt) port to access the dhcp server, plug in the usb keys and just issue a request system reboot usb from the console: the process will go on and put the switch back in a state where it accept the image coming from the DHCP without arguing (I am using 18.2R3S2 - which among other things solve the PR1442376 issue, and it's the recommended JTAC image) . It worked for me every time
2) on a connected switch, I will ftp the image not into the /var/tmp directory as recommended but in the /tmp directory. Then, issuing a request system software add /tmp/junos-arm-32-18.2R3-S2.9.tgz force unlink no-copy reboot . for some reason, I don't get the no space failure. That also worked everytime, and I have 240 of these things !!! I used secureCRT to access my switches, and load an .sh file on each switch that fetched the image and executed it using "cli -c "blablabla" lines. I upgraded 240 switches in an afternoon
once this is done, if I may suggest to disable the miniusb console port : go figure, but I haven't had a single swizzle reboot on the switches I did that ( set system port aux port-type rj45 disable) . You can try it , it will only disable the miniusb port console. If you get message like "getty request...", I strongly suggest you do it.
more on this here
https://forums.juniper.net/t5/Junos/this-can-not-be-good-getty-tcsetattr-dev-ttyu1-Invalid-argument/m-p/469660
have fun !
Michel