77896 - FWG Rev A (Orig) - Seems to have lost boot device - reboots to yellow nsh Shell> prompt
FWG has been operating flawlessly for months until just now when I attempted to connect the Firewalla app (from two phones) to the box and could not, neither over the network nor Bluetooth.
At this point the network was functioning perfectly. The internet and all local networks were accessible. I'm guessing that the OS data drive was not available to present configuration state to the app but the OS in memory was switching, routing and filtering fine. Linux is amazing.
I connected a USB Serial cable to the FWG and rebooted the device. It presented the BIOS boot option in the console and then loaded the nsh Shell> prompt. Normally this behaviour indicates the BIOS could not find a boot volume.
I rebooted into BIOS and the only boot option in the boot list was:
Boot Option #1 [UEFI: Built-in EFI Shell]
I contacted Firewalla Support and presented a numbered list of the sequence I just went through and images of the console output.
They had me download the latest 22.04 LTS recovery image and follow the instructions to reinstall from a USB Flash. The process went smoothly until the unattended installation stopped at the firestaller login and commenced a failure sequence of three beeps every five seconds. This login prompt appears to be presented by the booted Linux installer.
Firewalla Support got me to download the older version of 20.04 LTS and this resulted in the same unattended installer failure - presenting the firestaller login.
Has anyone had this kind of issue?
-
I see you have a case open already, best work with support. They already asking you a few questions like the model of the firewalla you are using and if it is possible to connect HDMI to the unit and see what the monitor displays.
Also, not sure if they asked, if you ever did any hardware modifications to the unit?
-
In the latest email FW Support did say that the HDMI output some error codes that were not output to the console. I was able to hook the FWG up to an HDMI monitor and it said:
! ! FAIL ! ! - cannot determine the flash device
As the flash device appears to be embedded I have asked if I can populate the M.2 Slot to restore operation until the RMA unit arrives and I can send this back in the RMA packaging.
Interestingly, because the device was still operational after the flash failure. Meaning that Linux was still functioning in memory, it might be possible for the FWG software to indicate a flash failure (it clearly could not write to storage) and advise Firewalla Support before an outage occurs and before the customer is even aware of the failure.
In such a case additional tests could be run to confirm status and the client advised not to reboot the device and that an RMA was on the way.
If the FWG software was designed to be able to function entirely in memory. Including being able to interact with the Firewalla app on paired devices, the client could also be notified of the failure through the Firewalla app and advised not to reboot the device. This would provide a significantly higher experience of fault tolerance, a better service experience, and reduce support costs (no time consuming support calls).
Please sign in to leave a comment.
Comments
2 comments