Closed
Bug 803029
Opened 12 years ago
Closed 10 years ago
[Settings] 'make reset-gaia' doesnt remove all networks stored.
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect)
Tracking
(blocking-basecamp:-)
RESOLVED
WONTFIX
blocking-basecamp | - |
People
(Reporter: borjasalguero, Unassigned)
Details
After saving a new SSID and configure it, it's impossible to delete it making a 'make reset-gaia'
Comment 1•12 years ago
|
||
I believe this is not a blocker. Right?
Reporter | ||
Comment 2•12 years ago
|
||
Well, it has impact for QA Team, because despite of making a 'make reset-gaia', 'Settings App' and 'FTU' are going to have weird behaviour (Settings shows something like 'Connecting to null....' and 'FTU' fails due to during the first boot it find a previous configuration.. :S).
Yes it will be useful for us (QA) to test the Full time experience feature.
Updated•12 years ago
|
Component: Gaia → Gaia::Settings
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 4•12 years ago
|
||
Resetting the SSID involves doing stuff outside of gaia, which is why make reset-gaia doesn't do anything. The configured networks are stored in /system/etc/wifi/wpa_suppplicant.conf You reset that particular file by pushing the default version. The default version (for otoro and unagi) is found here: B2G/device/qcom/msm7627a/wpa_supplicant.conf
Updated•12 years ago
|
blocking-basecamp: ? → -
Comment 5•10 years ago
|
||
If we want to reset networks then we should do so with full flashes in between test runs. As a developer, we often reset gaia but would like to keep our networks, so I think we should close this bug. Please re-open or file a new bug if you still feel strongly about it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•