I've been working on a prototype for an imaging tool. The thought would be that you'd install OctoPi in the following manner:
Download and burn the OctoPi image
Download and run the octopi-init program to do your initial edits prior to booting
Add the microSD to the Raspberry and finish up
Currently, I see that "simply editing" the various boot files on the microSD could be a little difficult/problematic for some. Perhaps a program might make this more comfortable for them.
I suppose I need to ask: What else would we need to configure in the boot partition before starting up OctoPrint?
It might be nice to try to add some sanity to the process of configuring webcams that aren't "the usual" ones we expect. It might also be nice to try to set things up for those who have LCD/TFT displays and those who need a different HDMI mode perhaps.
I'm looking for suggestions from those who provide support here to see what things you typically suggest.
[x] Get it to read the /boot/octopi-wpa-supplicant.txt contents
[x] Update the network section of that for the purpose of setting the default wi-fi credentials and the country code (from the initial image)
[ ] Get it to update it in the case where it's already been updated before
[x] README.md and github
[x] Add an eject button
[x] OSX installer
[x] Windows installer
[x] Linux/Debian/Ubuntu installer
If OSX had a working driver that would allow you to read from that pesky second partition, it would be easy to turn this into a backup/restoral tool as well. In theory, you'd put the microSD in there before an OctoPi upgrade, push a button to back it up, push the upgrade button and magic happens to automatically 1) pull/burn the new image, 2) re-apply your wi-fi credentials and 3) restore your data backup from before. I could actually do all that in Ubuntu, for what it's worth.
Wait a minute... so what if all of this works like the gparted boot disc? In the case of gparted, you boot up a live GNU/Linux platform so that you have the drivers I mentioned before. In the case of gparted, it allows you to easily manipulate the partitions of a hard drive. In our case, it would allow you to perform the upgrade path I mentioned. Let me think about that one as a later effort but it seems straighforward enough if you assume a USB-based thumbdrive, right?
Does that already support configuring more than one network?
I'd see upgrade/backup/restore rather as a separate app to be honest. Or... at least with regards to backup/restore, what about discovering the instance via mdns, then doing the needful via SSH?
All it will do at the moment is to add one network paragraph in /boot/octopi-wpa-supplicant.txt to support a single wi-fi zone.
I suppose I could allow it to add more than one wi-fi zone if you thought people did that.
I've discussed the backup/restore earlier in the script thread. When I wrote the earlier script, it just seems like there's a lot of work that is asked of the user. I'm envisioning an easier process and playing with some ideas to make it simple for users who don't know what git is, who don't know much about the command line, etc.
I'm still fussing with their listing. It creates a snapshot-in-time of your README.md which then has outdated download links. We're working to get that resolved.
In the meantime, should you want to play with it, try the actual repository.
Quick first feedback on the windows version - your SD detection isn't working. My card reader puts the card at I: and H: (boot and root), E: (which OctoPi-init is trying to read) is an HDD holding my data
These lines seem to be the culprit here? Maybe something like drivelist and scanning for entries that match isRemovable == true or even isCard == true would be an easy (and cross platform) solution here.
...as given on a command line produce the correct results but under control of child_process.exec() the response doesn't seem to make it back to stdout on my rig. I'm not sure if it's because of the VM or not. Note my frustration there in bootPath = 'e:'; when I hard-coded it in this initial version for Windows.
I'll throw in another round of testing on this to see why child_process is being problematic in this scenario. (Thanks for testing.)
@guysoft Although I like this approach, it didn't gather much use as far as I can tell.
I remember starring your CustomPiOS and we may or may not have had a conversation about the service-based thing that I wrote for that 3D printer manufacturer which—I'm guessing—does a lot of the same things. That one was just under a private repository so I couldn't share it. I'd love to dive back into this at some point but I've got too many projects stacked up right now.