octopi-networks.txt not present, and seemingly ignored upon boot when present

[Knetic]

I've never used Octopi before this week, but have spent days trying to get the 13RC2 image to work. I took the zip from #224 and extracted it (the zip name is 4/19, but the image inside says 3/18), and wrote to my sd with: sudo pv ./2016-03-18-octopi-jessie-lite-0.13.0.img | sudo dd bs=8k of=/dev/sdc.

The readme vaguely notes octopi-networks.txt, and says to "edit it". Unfortunately, that file doesn't exist in the image. In neither partition does this file exist. The format of the file isn't specified, but other random blog posts seem to indicate it wants to put the result in /etc/wpa_supplicant/wpa_supplicant.conf, so I match that format and put in my wifi details in that format. When I put the sd into the pi and boot, it goes through the usual boot process and drops me to a login prompt - I login and there's zero connectivity to wlan0. Worse, a netstat -tln shows that the only thing listening on any port is the sshd - no octoprint to be found. In fact, there's no service for octoprint, no logs, nothing to indicate that octoprint is even present except a few random scripts in the home directory which reference other scripts that do not exist.

I've tried putting the octopi-networks.txt file practically everywhere on both partitions - it never does anything. I've flashed at least a dozen times, and while I can make the device connect to my wifi by manually editing wpa_supplicant configuration, that doesn't address a distinct lack of an octoprint service. While poking around I noticed a chroot script that it seems like it's expecting a file to be on the ext4 partition under /boot/octopi-networks.txt, but there's no indication that this was called, nor that that script is ever even called.

So this issue is raising two points:

1. readme is frustratingly unclear on what you're even supposed to do with octopi-networks.txt
2. the image doesn't work even with tremendous effort, and doesn't show any indication that it would ever work

I think it's reasonable to say that even if i'm doing something wrong that the documentation and process about what I should be doing is severely lacking.

[markwal]

octopi-networks.txt is in the FAT partition, it is merely included from /etc/network/interfaces. The design is such that if you are using Windows, the only partition you can see contains the file and when you edit it, the instructions are inside of the text file.

When the image is run on the Pi, the FAT partition is mounted into /boot, so to edit the file from the Pi itself, the path is /boot/octopi-networks.txt

Also, you mention some confusion between 4/19 and 3/18. 4/19 is the date of the octopi image, but it is based on the 3/18 jessie image.

The RC1 unfortunately did not actually complete the image making process so didn't include the file (but there were other problems). RC2 should, I'll check tomorrow.

[foosel]

readme is frustratingly unclear on what you're even supposed to do with octopi-networks.txt

Quoting the readme (emphasis mine):

Configure your WiFi by editing octopi-network.txt on the root of the flashed card when using it like a thumb drive

That holds true for most people who are using OctoPi (which run either Windows or Mac - 89%), and most Linux distributions should also auto-mount the included FAT partition that @markwal mentioned. And right in the root of that FAT partition you'll find octopi-network.txt. Explaining that it's "in the root of the FAT partition" doesn't have any meaning for most people. "Root of the card when using it as a thumb drive" does. Is that misleading for people who are aware that there are two partitions on that image and that the partition mounted as / is actually not the FAT one whereas /boot is? Admittedly yes. But people who DO realize that there are two partitions on that image will usually also be able to just look into both partitions.

Why is it in the FAT partition in the first place? Because most people using the image are not able to mount EXT4 partitions on their desktop machines. The FAT partition however usually gets detected automatically. That way people can edit the file (which explains what they need to do) before they boot up their image for the first time - which is a good thing because most people using OctoPi also understandably are a bit overwhelmed with having to setup WiFi through other means (wired connection + SSH first, keyboard + monitor, mounting the root partition locally and editing the config files under /etc/).

the image doesn't work even with tremendous effort, and doesn't show any indication that it would ever work

I'm sorry you feel that way, but most of the existing users would disagree with that opinion as far as I can say.

If you have a suggestion for better wording that will NOT mislead people who are completely unfamiliar with Linux or file systems in general (the word "partition" for example is probably not a good idea from my personal experience) and is still short (because long instructions are scary for a lot of people), it would certainly be welcome.

As a side note, most people get OctoPi from either the OctoPrint download page (31%) or the OctoPi page (24%). Both also contain a link to Thomas Sanladerer's video instructions. The Github repo (3.3%) targets developers rather than users.

[Knetic]

I appreciate the responses.

When the image is run on the Pi, the FAT partition is mounted into /boot, so to edit the file from the Pi itself, the path is /boot/octopi-networks.txt

That at least explains which partition and path the file needs to be in. Unfortunately, no matter the existence or contents of the file, it seems to have zero effect on the system. And there are no discernible logs that I could use to diagnose the problem on my own.

I definitely see the boot partition being mounted, and can even cat my hand-crafted octopi-network.txt, but it seems to have no effect on the system's ability to make wlan0 actually work. And, as a note, if i manually cat append the contents of octopi-network into wpa_supplicant config, then ifdown / ifup on wlan0, I receive internet. However even once manually setting up wlan0 and restarting, there still exists no Octoprint on the Pi.

It's also not clear to me when exactly Octoprint is installed - is it hidden somewhere in the image (some random scripts in the image seem to think it's installed into a home directory, but it doesn't exist there)? Is it installed from some internet source only on first boot, and the Pi must have internet to accomplish this? Do I need to freshly flash the sd card every time I try something new to get octopi-network.txt to work, otherwise the install process fails and the installation will never work? I have very little data with which to solve my own problem.

I'm sorry you feel that way, but most of the existing users would disagree with that opinion as far as I can say.

Thus why I opened the issue; this is supposed to be a predictable process - It seems that if the image doesn't work and is missing files for me, it must be that way for everyone else - which means this release has a regression and all of your users will encounter this problem.

The Github repo (3.3%) targets developers rather than users.

I did not come to github first - I only came to open an issue (and search issues to see how many others were affected) after a day of being unable to get it to work. I didn't find #224 until tonight, and am relatively sure that I got the 13 version from the main download page at 4/23 8pm PST - though looking there now it seems to only advertise version 12. I can't be certain where exactly I got the broken version 13, because my chrome download history only lists that it was acquired from storage.google... which is where all versions seem to be hosted.

If you have a suggestion for better wording that will NOT mislead people who are completely unfamiliar with Linux or file systems in general

Since it looks like the image has bugs that caused it to not have octopi-network.txt, my comments on the readme's level of detail seem less critical. If octopi-network.txt existed and had all the boilerplate that I understand is supposed to be there, and Octoprint was installed into the image, I likely wouldn't have spent much time on the readme.

[foosel]

All the problems you seem to be having (no octopi-network.txt, no OctoPrint preinstalled where it should be in ~/oprint with the source checked out at ~/OctoPrint) hint at the image that you flashed NOT being the RC2 image.

Please double check if you in fact did flash the correct image. Crosscheck the md5sum of the zip file. Make sure you flashed the image contained in the zip file and not something else accidentally.

All I can tell you is that the RC2 image from what I'm seeing (freshly downloaded this morning from the link in #224, flashed, wifi configured, pi booted, currently running) is solid, has everything where it belongs and works as it should.

And for the record: OctoPrint and all the other tools packed into the image (webcam server, slicer etc) are indeed packed into the image, not downloaded on the fly or something like that.

[pelrun]

I just hit the same thing after downloading the RC1 image off the nightly build page; it looks like a vanilla raspbian image. Grabbing RC2 from #224 worked properly.

[foosel]

@pelrun guess why rc2 was made ;)

[Knetic]

Huh, you're right! The zip that I have (which I'm positive came from the octopi site itself) is named differently, and contains a different md5, than the RC2 listed above. Top row is what I opened the issue against, bottom row is what's in 224 RC2.

Archive Name	Image Name	Image MD5
2016-04-19_2016-03-18-octopi-jessie-lite-0.13.0.zip	2016-03-18-octopi-jessie-lite-0.13.0.img	06bf62c2811d76a2a3280e18cf8fbca2
octopi-jessie-lite-0.13.0_RC2.zip	2016-03-18-octopi-jessie-lite-0.13.0.img	f9dd0014fd0fb51d43523ea957069878

Unfortunately, downloading the current version 12 image from the main site and flashing it results only in a colorful blank screen (a square of blue, orange, and red) with no terminal (it stayed that way all day). The 13RC2 above encounters a series of startup failures before proceeding a (seemingly) infinite loop of starting/stopping Getty, D-bus, and login services. Plugging in a keyboard at this point sometimes prompts for a localhost login, but pi/raspberry creds are not accepted.

Either way, it seems like since I can't reproduce the behavior you're seeing with any octopi image, I'll close this and assume that it must be some hidden variable preventing Octopi from working on my end.