raspi-config breaks octopi-wpa-supplicant.txt link to wpa_supplicant.conf

[John-Mc]

I experienced an issue where the information in /boot/octopi-wpa-supplicant.txt stops updating the network information in /etc/wpa_supplicant/wpa_supplicant.conf. I experienced this in OctoPi 0.14rc1. I have not tried it in version 0.13.

When working normally, issuing ls -l /etc/wpa_supplicant/
yields (among other things):
lrwxrwxrwx 1 root root 21 Jul 27 2016 wpa_supplicant.conf -> /boot/octopi-wpa-supplicant.txt

When I run sudo raspi-config > localisation > Change WiFi Country > US , then select "finish", raspi-config prompts me to reboot. (I selected yes) After this the wpa_supplicant.conf file stops getting updated when /boot/octopi-wpa-supplicant.txt is edited.

The output from ls -l /etc/wpa_supplicant/ changes to:
-rwxr-xr-x 1 root root 619 Apr 1 22:58 wpa_supplicant.conf. [Note: per conversation with K. Jiang, the link is broken even before the Pi reboots after editing WiFi Country.]

From further poking around, I discovered that using raspi-config to change the localisation Time Zone, does not break the link. When changing the time zone, Raspi-config does not prompt you to reboot, it just exits when you click finish. Manually rebooting after this also does not break the link.

I've not done enough testing to know if the break is specific only to setting the WiFi Country, or if there are other settings in Raspi-config that might cause a break.

[kennethjiang]

It turns out to be a subtle problem in raspi-config. I just opened a PR for them.

However, it'll probably take quite a while before my PR is merged and propagated all the way to next OctoPi release. I'm open to options of a short-term fix.

[foosel]

Meh.

How about checking on boot (via a service file) if the symlink exists and if not a) repeating the sed on the /boot file (the country should be extractable from the existing conf) if necessary, then b) re-doing the symlink?

[kennethjiang]

I'm not confident about re-establishing the symlink. To do so we need to choose one between /boot/octopi-wpa-supplicant.txt and /etc/wpa_supplicant/wpa_supplicant.conf as the "golden" version. However either (or both) of them may have been further changed by user after the link is broken.

It looks like RPi-Distro team was quick in merging my PR. At this moment I'd say just wait until the PR makes it way into next Jessie release. Meanwhile the users can work around the problem by not using raspi-config to change wifi country.

[foosel]

either (or both) of them may have been further changed by user after the link is broken

I think the chances for this are pretty slim though considering that raspi-config prompts for a reboot after the breaking change takes place which most people will probably follow. And the two files would be synced up again during the reboot (or rather, the only change from the /etc/ version would be merged into the /boot/ version and then the symlink would be recreated).

just wait until the PR makes it way into next Jessie release. Meanwhile the users can work around the problem by not using raspi-config to change wifi country.

The problem with that though is that unless a user actively updates their version of raspi-config through apt-get upgrade to a fixed version (once said fixed version is available on the package repository), doing this particular change on OctoPi 0.14 will break things. We could mitigate that with a big fat disclaimer in the octopi-wpa-supplicant.txt file though ("Note: If you utilize this file, make sure to NOT change your WiFi country through raspi-config. Doing so will most likely break the functionality provided through this file. Read more at
[link to this issue]"). No matter what though IMHO we can't just leave that trap as it is right now.

The problem here is communication - yes, users can easily work around this, but if they forget it or just don't read (and the latter is way more common than you'd think) they will run into this. So personally I'd rather find a way to work around this issue that doesn't require knowledge and action (or specific in-action) on the user's part.

[John-Mc]

Sorry for the topic drift, but I have to say it's impressive watching you guys work this out (even though much of it goes over my head). I appreciate all of the effort you put in to making OctoPi what it is.

[kennethjiang]

Totally agreed @foosel on ensuring we sufficiently communicate the problem to users.

Regarding a new service to fix this problem: are you suggesting:

• check if /etc/wpa_supplicant/wpa_supplicant.conf is a link.
  • if yes: do nothing.
  • if no: overwrite /boot/octopi-wpa-supplicant.txt with /etc/wpa_supplicant/wpa_supplicant.conf; delete /etc/wpa_supplicant/wpa_supplicant.conf; relink /etc/wpa_supplicant/wpa_supplicant.conf -> /boot/octopi-wpa-supplicant.txt

[foosel]

Nope. I'm suggesting

• check if /etc/wpa_supplicant/wpa_supplicant.conf is a link.
  • if yes: do nothing.
  • if no:
    • parse wifi country setting from /etc/wpa_supplicant/wpa_supplicant.conf
    • apply to /boot/octopi-wpa-supplicant.txtviased`
    • delete /etc/wpa_supplicant/wpa_supplicant.conf
    • recreate symlink

That way any modifications to the txt file persist. There should hopefully be none but the change of the WiFi country in the conf since the user will most likely have rebooted directly after doing this.

[foosel]

Sorry for the formatting mess, I'm on mobile and the mobile version of Github is a PITA...

[kennethjiang]

My instinct says doing something that complicated just to patch up a problem with simple root cause is overkill. Meanwhile I don't have a good alternative...

I'm very tied up these days. Will get back to it as soon as I get a chance. When is the latest time to get a PR in to fix this issue? @foosel

[foosel]

IMHO it's not THAT complicated - just compared to the actual solution to the problem it tries to workaround it appears completely overkill. But well, what can you do... you should see some things I did in OctoPrint to get around problems ;) Detecting your pip parameters for example - needs to be done by installing a dummy package and have it write some stuff to a temporary file whose path is injected through an environment variable because modern pip versions swallow all output from a running setup.py and the only way to determine certain things about a pip environment is by running inside it, so.... horribly convoluted :)

Anyhow... I don't know about @guysoft 's thoughts on this, personally I'd say with a release like this give people at least a week with an RC, better more. RC1 was released last friday. I can see if I can take a shot at the service thing tomorrow or the day after if that helps.

[kennethjiang]

Thanks a lot @foosel I may be freed up a bit next week. Let me know when/if you want me to take a stab at it.

[foosel]

Whipped something up, see PR #337

[guysoft]

Pulled, I can't built a nightly though because there is no internet the past two days in my apartment (in the works, we think an insane thunderstorm is the culprit), so it will wait and then I will make an RC2.

[kennethjiang]

Thanks @foosel for your excellent work!

[guysoft]

Fixed in 0.14, will keep an eye on removing it when the fix goes in to official Rpi-foudation release.

[kennethjiang]

Woohoo! Thank you @foosel @guysoft

[John-Mc]

@guysoft I'm curious: did Rpi-foundation ever fix this in their release? Perhaps when Raspian Stretch came out?

[guysoft]

You can check this stuff easily qemu now:

CustomPiOS/src/qemu_boot.sh ./image/2017-11-29-raspbian-stretch-lite.zip

Looks like the commit referenced was fixed.

[John-Mc]

Thanks, Guy. I would not have had the vaguest idea of where to look for this. (I also would not have recognized what was going on in the code shown in the screenshot, had I not followed some of the discussion. Beyond my knowledge level.)

[nbelakovski]

So, are the changes made in this PR not necessary anymore? I wonder if it would be sensible to remove them in order to not have unnecessary code in the repo gumming up the works? It would help people like me not chase ghosts :)

[John-Mc]

@nbelakovski - If I followed things correctly, it's still needed in OctoPi 0.14, since that is based on Raspian Jessie-Lite. I may not be needed in OctoPi 0.15 when it comes out, since it appears Raspian Stretch has corrected the problem

[guysoft]

I can build a nightly, but wont have time to test. If anyone volunteers to test then ill do itit.

[John-Mc]

Happy to test it out, if you want. Seeing as I was the one to stumble across the issue in the first place. It will be a few days before I can get to it. I'm away from home now.

Just let me know when it's up, and which version I should test.

[John-Mc]

@guysoft did you already undo the changes referenced a few posts up by nbelakovski? I have not tested any of the nightlies, because I don't know how to tell which one has the change.

[guysoft]

I didn't revert anything afaik. You mean this? : #337

I can revert it, @foosel should we revert and let @John-Mc test a nightly?

[John-Mc]

@guysoft - That's the one. I thought that was what you were referring to when you said "I can build a nightly, but wont have time to test. If anyone volunteers to test then ill do it" a few posts up.

The original problem was fairly obscure. It only happened when someone tried to change the WiFi Country setting via Raspi-config. At one point, I tested a whole bunch of other Raspi-config options, but never found anything else that caused the problem. I have no idea if there are things outside of raspi-config that could also cause the problem. I've never heard of one.

I'm perfectly happy to test whether raspi-config in Raspian Stretch causes a problem. Going beyond raspi-config testing (if any other testing is desired) is probably beyond me. I'm just a user who is good at breaking things, not a programmer.

[foosel]

Sure, go ahead. You'll need to manually revert this in CustomPiOS though I think.

[guysoft]

Reverted, wait for next nightly to test

[guysoft]

Nightly build: https://storage.googleapis.com/octoprint/2018-03-02_2017-11-29-octopi-stretch-lite-0.15.0.zip
Md5:
a483287ef623bf868a54564d578fd0ab

[John-Mc]

Just tested. Using raspi-config to change WiFi Country no longer breaks the link between octopi-wpa-supplicant.txt and wpa_supplicant.conf

[guysoft]

Yay