-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read-Only filesystem on Ubiquiti airmax devices #2939
Comments
Remove due to ticket freifunk-gluon#2939 These devices risk being bricked in a way that can not be recovered without running full TFTP or serial recovery, as the flash ends up in a read-only state with no way of upgrading to a fixed version. Thus, remove the support for the time being. Don't just flag them as BROKEN, as this would deliberately brick these boards when installating such an image. Signed-off-by: David Bauer <[email protected]>
Remove due to ticket freifunk-gluon#2939 These devices risk being bricked in a way that can not be recovered without running full TFTP or serial recovery, as the flash ends up in a read-only state with no way of upgrading to a fixed version. Thus, remove the support for the time being. Don't just flag them as BROKEN, as this would deliberately brick these boards when installating such an image. Signed-off-by: David Bauer <[email protected]>
Remove due to ticket freifunk-gluon#2939 These devices risk being bricked in a way that can not be recovered without running full TFTP or serial recovery, as the flash ends up in a read-only state with no way of upgrading to a fixed version. Thus, remove the support for the time being. Don't just flag them as BROKEN, as this would deliberately brick these boards when installating such an image. Signed-off-by: David Bauer <[email protected]>
Remove due to ticket #2939 These devices risk being bricked in a way that can not be recovered without running full TFTP or serial recovery, as the flash ends up in a read-only state with no way of upgrading to a fixed version. Thus, remove the support for the time being. Don't just flag them as BROKEN, as this would deliberately brick these boards when installating such an image. Signed-off-by: David Bauer <[email protected]>
Removing this ticket for the upcoming v2023.2 milestone, as the devices were removed from Gluon. Keeping this ticket open for visibility. |
@blocktrron this seems to be solved upstream? |
DO you have a commit as reference? |
@blocktrron f024f4b1b0380b3b2e18115bd8e4f35393fccc70 was mentioned here openwrt/openwrt#14237 |
I could validate the fix on the NanoBeam 5AC 19 (XC). Hoewer that device is currently in Darmstadt and it's currently raining which doesn't help with my motivation to do so right now. Hoewer, in theory we could validate it and reintroduce support before the next release. |
@rotanid I've seen this commit, I'd like to have this verified before reverting though. |
We have M5 Loco XM (5x) and M5 Loco XW (3x). Is the fix already in master? What needs to be done to verify this? |
@blocktrron shouldn't this be part of gluon already which would render this issue fixed? |
Remove due to ticket freifunk-gluon#2939 These devices risk being bricked in a way that can not be recovered without running full TFTP or serial recovery, as the flash ends up in a read-only state with no way of upgrading to a fixed version. Thus, remove the support for the time being. Don't just flag them as BROKEN, as this would deliberately brick these boards when installating such an image. Signed-off-by: David Bauer <[email protected]>
As far as I understand, the fix from OpenWRT commit c55aaa7c9a ("ath79: generic: disable SPI-NOR write protect unconditionally") is now in Gluon main. To drive this issue forward, I would do the following:
If the above test was successful and nobody objects until next week, I will prepare a PR for revert of a0f5b4e. |
@nrbffs Yes, let's get this hopefully over with. I've rebased #3141 which is a revert of a0f5b4e. Locally it seems to build. So i think the CI should succeed as well. The testing procedure sounds fine to me. I'll test it on the NanoBeam 5AC 19 (XC) today or tommorrow and if you can also provide some testing results (ideally from another affected Model) then we should have something mergeable with a reasonable high degree of confidence. Edit: Tested it but it doesn't work: #3141 (comment) |
These appear to be the current Upstream Issues:
(But there are more.) And then there is a PR which claims to fix it: |
Bug report
What is the problem?
Several Ubiquiti airmax devices (ath79 target) report a Read-only filesystem with OpenWrt 23.05
Upstream ticket: openwrt/openwrt#12882
What is the expected behaviour?
The rootfs_data partition is not read-only
Gluon Version:
Gluon based on OpenWrt 23.05
Site Configuration:
n/a
Custom patches:
n/a
The text was updated successfully, but these errors were encountered: