Is there any way to store OctoPrint on a SATA, etcher doesn't like big sd cards so I want to flash my pi on a small sd but then have everything else instance on a HD.
Thanks,
Trick
I haven't tried win32 will it let me image octoprint on a 128gb card?
I have seen raspi sata adapters but didn't know of I could use that space through octoprint
You might try it...
A better option would be to install OctoPrint (OctoPi image in this case) to a smaller SD card (~16GB?) and then change the folders it uses for storage heavy parts in the settings. You can change all of these:
To wherever you want. I recommend getting a USB HD (or SATA -> USB adapter), since it will be far more reliable than anything that goes on the GPIO pins, since the RPi (as @Ewald_Ikemann noted) has no native SATA interface
1 Like
Perfect thats what I was looking for thank you!
1 Like
I have a mac so I can't run win32
1 Like
I have had good experience with the official Raspberry Pi imager, get it from https://raspberrypi.org/downloads
I have heard before of Etcher having a few quirks, hence I go to the official one.
1 Like
I'll give it a shot
1 Like
If that also doesn't work try it in the shell
It's also possible to have /boot only on Pi's SD cared and all the other stuff on by USB attached storage.
Charly already mentioned SATA -> USB adapter.
But then you have to install manually.
I got tired of scrambled SD cards on one of my printers and moved the entire system over to a USB flashstick. If you're running at least a Raspberry Pi 3, you can do that. It takes a little bit longer to boot up, but seems just as responsive once it's up and running.
I've never used Etcher. I've either used dd to blast an image onto a card, or NOOBS to start from scratch. I mostly use Linux, but dd should be available for Mac OS X as well. (NOOBS doesn't care what your desktop runs...just format your SD card FAT32 and unzip the downloaded archive to it.)
1 Like
This worked the best, I was able to flash octoprint onto 512 SD card instead of using HDD. Thank you!
1 Like
I've had Balena Etcher burn out several of my good SD Cards. I have had good luck writing larger cards up to 400GB. But I do try to avoid Balena if I can.
I second the point with Raspberry Pi imager, I have had good luck with that imager also up to 400GB.
Also, I to agree with moving your /home directory to a SSD on the USB port. That way your /home/pi/.octoprint directory which holds the bulk of the logs, uploads data, timelapses, etc, etc etc go on the SSD or even a good fast HDD. I current use a Western Digital HDD that I had sitting around.
You can see the HDD off to the side in the second picture. Currently it is mounted in a holder behind the 7" screen running OctoDash on top of OctoPi.
I have not tested with octoprint, but once I plugged a USB HDD with external power supply to a raspberry pi with raspian and worker fine for several months 24/7. I copied everything from the SD Card to the HDD and then edited /etc/fstab and /boot/cmdline.txt file to point to the copy in the HDD instead of the original files in the SDCard. Of course the boot partition used has to be on the SD Card for booting. I think that this is easier than doing manual install and probably will be faster than re-installing in a bigger storage. Also, if you edit back the /etc/fstab file and /boot/cmdline.txt everything goes back to the point where you left.
1 Like
This is a fast and pretty good method.
But there are some traps using this method on a running Pi system.
Exclude mounted devices , exclude bound devices, exclude pid files and so on.
As often in live: you have to know, what you are doing if you use this back door. If you try to copy all while the system is up maybe by rsync to avoid access problems, it's not so good.
Sorry, I did not mention that I powered off the RPi, took out the MicroSD card and copied everything in my laptop. Edited the files also in my laptop and then put the card back on the raspberry pi. I guess that before turning off the raspberry pi, it will be useful to write down uuid from the hard drive or have edited the original fstab file for automounting the external hard drive. I am not as confident in my Linux skills to do that while the system is up, but in any case I don't see how that will be necessary for this scenario.
1 Like
e.g if filesystem is EXT*, windows may have problems to read it and to do it by low level image copy the user might be confronted with other traps.
Sure, I see how that be a problem. Thanks, for pointing this out. My laptop is running Linux, so I did not face those issues. I did, indeed, format the external hard disk in ext file system. But, I forgot to mention about some possible problems using Windows for copying and that will be better to use some Linux native filesystem for the hard drive.
oh, you are one of the lucky people who can go around Windows 
/me unfortunately is bound to Windows by job 