Skip to content
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

Open
blocktrron opened this issue Aug 22, 2023 · 8 comments · May be fixed by #3141
Open

Read-Only filesystem on Ubiquiti airmax devices #2939

blocktrron opened this issue Aug 22, 2023 · 8 comments · May be fixed by #3141
Labels
0. type: bug This is a bug 3. topic: hardware Topic: Hardware Support
Milestone

Comments

@blocktrron
Copy link
Member

blocktrron commented Aug 22, 2023

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

@rotanid rotanid added 3. topic: hardware Topic: Hardware Support 2. status: waiting-on-upstream Waiting for upstream changes labels Sep 6, 2023
@neocturne neocturne added this to the v2023.2 milestone Oct 10, 2023
@rotanid rotanid added the 0. type: bug This is a bug label Oct 10, 2023
blocktrron added a commit to blocktrron/gluon that referenced this issue Nov 24, 2023
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]>
blocktrron added a commit to blocktrron/gluon that referenced this issue Nov 24, 2023
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]>
blocktrron added a commit to blocktrron/gluon that referenced this issue Nov 24, 2023
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]>
blocktrron added a commit that referenced this issue Nov 26, 2023
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]>
@blocktrron
Copy link
Member Author

Removing this ticket for the upcoming v2023.2 milestone, as the devices were removed from Gluon.

Keeping this ticket open for visibility.

@blocktrron blocktrron modified the milestone: v2023.2 Dec 10, 2023
@rotanid
Copy link
Member

rotanid commented Dec 26, 2023

@blocktrron this seems to be solved upstream?

@blocktrron
Copy link
Member Author

DO you have a commit as reference?

@rotanid
Copy link
Member

rotanid commented Dec 27, 2023

@blocktrron f024f4b1b0380b3b2e18115bd8e4f35393fccc70 was mentioned here openwrt/openwrt#14237

@herbetom
Copy link
Contributor

herbetom commented Jan 2, 2024

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.

@blocktrron
Copy link
Member Author

@rotanid I've seen this commit, I'd like to have this verified before reverting though.

@herbetom herbetom linked a pull request Jan 3, 2024 that will close this issue
@neocturne neocturne modified the milestones: v2023.2, v2024.1 Jan 6, 2024
@nrbffs
Copy link
Contributor

nrbffs commented Jan 13, 2024

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?

@rotanid rotanid removed the 2. status: waiting-on-upstream Waiting for upstream changes label Apr 21, 2024
@rotanid
Copy link
Member

rotanid commented Apr 21, 2024

openwrt/openwrt@c55aaa7

@blocktrron shouldn't this be part of gluon already which would render this issue fixed?

hafu pushed a commit to Freifunk-Potsdam/gluon that referenced this issue Jun 2, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. type: bug This is a bug 3. topic: hardware Topic: Hardware Support
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants