Just startet the update for my TO router and got the following error-message:
[31-Aug-2023 11:26:32] ERROR: Another FPM instance seems to already listen on /var/run/php8-fpm.sock
[31-Aug-2023 11:26:32] ERROR: FPM initialization failed
Do I need to do anything after manually after the reboot? This is related to nextcloud-installation I assume.
edit: Nextcloud is running well after reboot, so no idea if this error is of any relevance.
edit 2: Seems all updates went well that far for my TO router (only app running currently is NC instance) and two dumb APs (MOX A(SDIO)D(2,5GBE)B(WLE1216v5-20) + TO with 1xNP1+2xNPD).
MOX A+D TOS 6.4.1 > 6.4.2
Have approval enabled and hit install today.
Took a couple of minutes rhen the MOX locked up and my link to the world was gone.
Had to go down to the basement and pull the plugg to get it running again.
Following forum I saw many cases when after update something went amiss, but after reboot or powering off/on things got to normal… I wonder whether making reboot after any update mandatory wouldn’t solve such cases… maybe to allow for some delay to enable to check update result/log before forcing reboot…
Most updates require a reboot. At least those upgrading kernel, and most of them do it. After such update, the router is rebooted in a few days if you don’t do it earlier yourself.
I personally prefer to do a reboot immediately after updating. And if I want to defer reboot for some time, I’d defer the update with it. I think it’s really difficult to do perfect reboot-less nontrivial updates (including all corner cases), even if kernel isn’t touched.
Looks like HDD or filesystem failure. Log in via ssh and look through dmesg and /var/log/messages if you find anything related to btrfs or /dev/sd … If the drive is not mounted, you can also try btrfs scrub to find errors on it.
OK, solved. I’ve had disabled the NAS package group in reForris prior to the installation (as I didn’t think I needed any of its functionalities). Apparently, this uninstalls many dependencies, including block-mount.
With the package uninstalled, LuCi System menu does not offer Mount Points, and the mSATA disk does not get mounted on boot, apparently.
After reinstalling the NAS package group and rebooting, the drive and LXC containers are back.
I am still blocked on version 6.3.3. I tried to install this update a few minutes ago but, as with the previous one, it broke everything and couldn’t access the dashboard nor SSH to my Mox.
Sharing here for visibility, and if someone had a similar issue in the past.
Background info:
I first had auto-update ON which installed Turris OS 6.4.0 on the 27th Jul, and after a 3 day delays (that I setup), the updated was applied (July 30th).
However, I had no internet connection nor access to reForis at 192.168.1.1.
What I did:
Check ip a on my computer: I noticed there was no inet anymore,
only inet6, which I found strange.
I used recovery mode 5 (unsecure SSH) to SSH into my Turrix MOX and rollback before update with schnapps
Can now access Internet and reForis at 192.168.1.1
It may have been possible to SSH through IPv6 but honestly no idea how to do that with Turris MOX.
I’ve stopped auto-update for now since then and contacted support who asked me to wait for the next update.
I tried again this morning with 6.4.2 but still the exact same issue.
Other info:
Device
CZ.NIC Turris Mox Board
reForis version
1.4.1
Turris OS version
6.3.3
Turris OS branch
HBS
Kernel version
5.15.114
Potential cause of issue?
I am using ds-lite (which is not supported by reForis). Not sure if that is the cause of the issue
I am using experimental packages OpenWrt's process jail and Secure Computing Mode (seccomp)
I am also using Morce (experimental, high memory)
Please let me know if there are other diagnostic/troubleshooting I can do to help pin point the issue.
Try manually stopping morce and other memory-intensive apps before installing the update. Make sure via htop you have at least 300 MB free RAM. It can happen that if the RAM is full during the update, something will fail and leave the router in a half-configured state.
All of this is (well) known I agree with @vcunat and similarly reboot immediately after any update, be it reboot recommended or not, even though configuration of my TO and MOX is very simple…
I just suggested that reboot could be optionally included in update procedure… to be on safe side.
Yes, I think all the “High memory” apps installed via Reforis should be automatically stopped before update and started after it. These low memory issues have hit a lot of people and generate bug reports where there is actually no bug with the update itself. @miska is this somewhere on the roadmap?
As a workaround, you can do it yourself, for example: