And now, for those of you that are beta-testers (which I am not) there is a fix proposed. If anyone of you testers can report…
(please insert here a smiley with a hopeful, staring look)
https://bugtracker.fairphone.com/project/fairphone-android-7/issue/7
(the link I am not allowed : https://forum.fairphone.com/t/fp2-fairphone-os-fairphone-open-19-02-1/48239 )
I tested and so far it looks good. I shut down about 20 times and one time it rebooted, but I think I may have just accidentally pressed reboot.
I just wanted to note that as tempting it might be to make such assumptions, having been a professional software developer in the past I can 99% ensure you that the reasons for a seemingly lack of progress on an individual issue are hardly ever “lack of interest”. Besides having to juggle over 100 bug reports in the Android 7 tracker, communication on progress is a lot more finicky than it might seem; developers want to be as accurate as possible about a topic that they cannot assume the reader is an expert in, while at the same time maintaining realistic expectations that don’t lead to disappointment. This is easy to get wrong: technical stories get misinterpreted, the complexity of problems are underestimated by the reader, well intended timelines presented as “if everything goes right” soft targets are interpreted as hard deadlines, and so on and so forth.
The temptation for developers is thus often to “just retreat while I fix this stuff for you now, I’ll tell you when it’s ready”, which to the outside world looks like a lack of commitment or progress until the very last phase of “a fix is ready to test”. This approach isn’t great as it can frustrate engaged users, but very understandable from the developers perspective if the alternative leads to “punishment” by the very same users for not meeting expectations.
In recent days I can see that Fairphone is trying to be more systematic about their approach to communication. They have created wiki-pages explaining the lifecycle of a bug through the various statuses, what a transition from status to status means and how they prioritise issues. This is good: expectations are conveyed to the user in a generic manner decoupled from technical detail, and systematic communication is easier to deal with for developers. I suspect they’ll continue getting better at communication and with that, they’ll get better at telling you why a bug is seemingly left untouched for a while.
Coming back to the quote I highlighted: I’m sorry to hear that the team hasn’t been able to live up to your expectations so far. I’d never tell you you have no right to feel disappointed, but I hope you can appreciate that the process of bug fixing (yes, even fixing regressions, things they seemingly got right before) is filled with uncertainty on the way that sometimes is very difficult to communicate about. In that light, I would encourage you, as FP2 user to FP2 user, to reconsider the assumptions you’ve made as to why you feel they have disappointed you. It’s likely to be an oversimplification of the truth and, as a developer, reading an “accusation” like this would work demotivating if anything.
I’m personally going to look at the now half-full glass and cheer for the progress reported, hopefully there’ll be a released update in a matter of weeks. 
I’m a software developer, too, and while I mostly do in-house software, the one time I developed software sold to consumers we had an external and internal bug tracker. So that people from the outside didn’t get to see all the internals. Of course it’s all guesswork, but please consider this next time before stating as a fact what RSpliet already quoted.
Good !
Do you know if the modem files in your new image are different from the previous one?
Maybe a new modem.zip could be released soon to fix the bug for LineageOS users like me as well 
emmc_appsboot.mbn is different, the rest of the modem files are the same.
Don’t get your hopes up just yet.
I flashed the beta modem files manually to my LineageOS 15.1 for microG, and not only did they not fix the shutdown bug, they also stopped the flashlight workaround from working.
Installing the 18.03.1 modem.zip again restored the former status quo.
So, I think either the fix is not in emmc_appsboot.mbn (but in the updated Fairphone OS and Open OS), or it just doesn’t work this way for my LineageOS 15.1 for microG.
The other side of the story of course is that as a company you do have a responsibility to communicate clearly and accurately. Users have the right for their purchased product to function well and remains functioning well, and have every right to be disappointed/frustrated/angry if this is not the case. That goes double when the product is sold as a sustainable solution. Disappointed users might express their disappointment in counter-productive or “raw” language, but the disappointment is real. As a producer/seller, clear, concise, timely and honest communication can really make the difference between an understanding customer and a frustrated (potential ex-)customer.
From the external signals, it looks like Fairphone is very much in search of good procedures to better that balance and improve their public communication. Naturally they can’t please everybody, but I’m glad to see they’re trying.
What about flashing the boot.img? Is this possible to do anyway, using FP boot.img and LineageOS?
I couldn’t imagine that … but I just tried to be safe … and no, it doesn’t even boot, just shows the Fairphone logo 
.
Reflashed LineageOS’s boot.img … boots again.
The „Torch-Trick“ (with flashlight) worked on my FP2 (OS 18.10.0) since I have activated the „System UI Tuner“ (advanced status bar). Thank you for your report.
Der Trick mit der Taschenlampe funktionierte bei mir FP2 (OS 18.10.0) erst, seit ich den „System UI Tuner“ (Erweiterte Statusleiste) aktiviert habe. Danke für deine Vorinformation.
Unfortunately, that option (turning on the flashlight) doesn’t work for me! I tried it several times, and it reboots anyway with the flashlight turning back on as soon as the phone turns back on !
Are there others for whom this trick doesn’t work either? Or is it just me? I appreciate your feedback. It’s better to feel I’m not alone! 
Make sure your phone is not connected via USB to a computer or a charger. And try with Bluetooth turned off.
This had an impact on the workaround for other users here.
A permanent fix for this bug is in beta testing currently.
Thanks, but my phone is not connected via USB and Bluetooth is also off.
In this case, keep Volume + pressed while the phone reboots, until you get into the recovery (should be TWRP - Team Win Recovery Project).
In TWRP, choose Reboot, then choose Power Off.
This was the workaround before the flashlight workaround.
If you have encrypted your phone, you can alternatively turn it off at the point when it prompts for your decryption password. Long-press the power button until the menu shows up like it does in Android, then choose Shutdown (or similar, can’t check the caption there right now).
Thanks !! It actually worked !!
At first it seemed it’s gonna reboot again, but fortunately it did actually turn off.
Of course this method seems a bit of over-kill, but since I don’t need to turn my phone off as often, I am rather fine with it for now. Hopefully the bug will be fixed soon.
There’s still removing the battery .
Dear all, the FP bug tracker now announces the issue is solved, “in the 19.02.1 releases of Fairphone OS and Fairphone Open”
I for one am still on Open 18.04.3 (to which I regressed because of the bug to be in line with the couple of people I support)… [edit : done the switch, it does work now!]
Now, I feel obliged to answer RSpliet post as, given the length of his reaction, I certainly shocked him/her a lot.
First Id’ like to remind the purpose of my post was to announce the bug was being addressed : so, a good news, and I was the first to announce it.
Second, I do assume my words ‘by lack of any interest’, but honestly, in my sentence this concerns the management of the bugs : not the devs in any way -the guy that decided that the only bug that attracted 76 watchers (vs one or two for all others) was to be allocated to a dev after six months.
IMHO this still means something worrying : at the very least this may mean the dev team is very small, even though they evolved a lot since the FP1 (where you just didn’t get a bugtracker anyway).
But at worst, I maintain that the guy in charge of deciding which concern is frontmost to be solved, may not be competent : from all the measurable data I see, he chose to spend half a year to solve issues that 1% of users complain about, and the remaining 99%, if I dare the comparison, the ones that all came and registered into the tracker just for that (which no single other bug triggered), these guys can wait.
Let’s be more polite : he has a wrong way to evaluate a situation.
And this decision, the only thing I criticized, isn’t dev stuff.
RSpliet, with my apologies…
OK !! This is better than removing the battery !! But it would have been great if the shut down function actually worked !!
Haha, turned off my fairphone for the first time in months. Now it can rest for a while.
Thx, works for me fine!