Reset Search
 

 

Article

How to Recover the Wireless Controller from File System Corruption

« Go Back

Information

 
TitleHow to Recover the Wireless Controller from File System Corruption
Objective
  • How to Recover the Wireless Controller from File System Corruption
  • On virtual controllers, you may notice the boot process in Console stopping at line "Registered vmci device."
Environment
  • IdentiFi
  • System Recovery
  • System Corruption
  • Firmware All
  • UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
  • A power outage can, in rare cases cause file system corruption of the wireless controller. If file system corruption occurs, the controller might not be able to start up and provide service.  
Procedure
To Recover the controller from File System Corruption: 

1. Connect to the console port. Do not use the ESA ports or the Admin port - Using the Serial Console Port on the IdentiFi Wireless Appliance C25, C35, C4110, C5110, and C5210
2. For V2110 controller console connection, please see the following instruction: How to gain access to IdentiFi V2110 Rescue mode on ESXi deployment for password recovery or file system issues
2. Monitor the console output of the system startup. In case there are file system corruptions, you will see similar output containing unexpected file system inconsistency with a request for the manual actions. 
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Mounting readonly root filesystem...done.
Checking root file system...fsck 1.40 (29-Jun-2007)
/dev/hda2 has gone 14817 days without being checked, check forced.
Inodes that were part of a corrupted orphan linked list found.
/dev/hda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.(i.e., without -a or
-p options)
fsck failed (exit code 4). Please repair manually and reboot.
Please note that the root file system is currently mounted read-only.
To remount it read-write:
 # mount -n -o remount,rw /
CONTROL-D will exit from this shell and REBOOT the system.
Give root password for maintenance
(or type Control-D to continue): <PASSWORD_HERE>
3. Type the main admin password to log into the wireless controller.The command prompt displays.
4. Use the fsck.ext3 command to recover the file system partition, where /dev/hda2 is a problematic partition name from the output above. 
bash-3.00# fsck.ext3 -fycv /dev/hda2
5.  After the recovery completes, use the reboot command to reboot the system.
e2fsck 1.40 (29-Jun-2007)
Checking for bad blocks (read-only test): done
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? yes
Inode 17765 was part of the orphaned inode list. FIXED.
Inode 17786 was part of the orphaned inode list. FIXED.
Inode 64432 was part of the orphaned inode list. FIXED.
Inode 64433 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda2: ***** REBOOT LINUX *****
 12087 inodes used (15.61%)
 83 non-contiguous inodes (0.7%)
 # of inodes with ind/dind/tind blocks: 636/5/0
 83316 blocks used (53.88%)
 0 bad blocks
 0 large files
 10967 regular files
 742 directories
 2 character device files
 0 block device files
 6 fifos
 1418 links
 359 symbolic links (359 fast symbolic links)
 2 sockets
--------
13496 files
bash-3.00# reboot
6. Following the reboot, the wireless controller should proceed with the normal startup.


​​​
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255