wiki:features
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:features [2018/08/29 10:26] ghi [Instability detection] |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Recovery mode & backup features ====== | ||
| - | ===== Recovery ===== | ||
| - | ==== Instability detection ==== | ||
| - | |||
| - | An instability counter is used to detect system instability. | ||
| - | * If 16 consecutive reboots are detected due to a watchdog, a “backup restore” operation is triggered. | ||
| - | * If 32 consecutive reboots are detected due to a watchdog, a “stock restore” operation is triggered. | ||
| - | |||
| - | The counter is reset if the system is up during at least 10 minutes. | ||
| - | This feature cannot be disabled as it avoids bricking the gateway in case of software failure. | ||
| - | |||
| - | The counter ''bootfail'' is displayed at boot time only if the reboot is due to a watchdog. Bootcause information are available [[wiki:troubleshoot#bootcause|here]]. | ||
| - | |||
| - | <code> | ||
| - | U-Boot 2015.04 (Aug 21 2018 - 18:53:11) | ||
| - | |||
| - | |||
| - | CPU: Freescale i.MX6SX rev1.2 at 792 MHz | ||
| - | |||
| - | CPU: Temperature 48 C | ||
| - | |||
| - | Reset cause: WDOG | ||
| - | |||
| - | Watchdog enabled | ||
| - | |||
| - | I2C: ready | ||
| - | |||
| - | DRAM: 240 MiB | ||
| - | |||
| - | MMC: FSL_SDHC: 0 | ||
| - | |||
| - | Using default environment | ||
| - | |||
| - | |||
| - | In: serial | ||
| - | |||
| - | Out: serial | ||
| - | |||
| - | Err: serial | ||
| - | |||
| - | bootcause = SW | ||
| - | |||
| - | bootcount = 32 | ||
| - | |||
| - | bootfail = 0 | ||
| - | |||
| - | bootmode = nominal | ||
| - | |||
| - | boardconfig = 0x0 | ||
| - | |||
| - | Net: FEC0 | ||
| - | |||
| - | Normal Boot | ||
| - | </code> | ||
| - | |||
| - | \\ \\ | ||
| - | ===== Backup ===== | ||
| - | ==== Backup restore ==== | ||
| - | The updates that are being installed during an update request can make the system unstable so by default they are not included immediately in the backup.\\ | ||
| - | Before each update, a “snapshot” of the firmware is done. It contains all the previously applied updates that are considered as "stable". | ||
| - | This “snapshot” will be used if a “backup restore” is triggered. \\ | ||
| - | A “backup restore” will reinstall all the packets previously installed on the gateway except the last one. The files contained in ''/user/*'' are not removed. | ||
| - | To trigger a backup restore execute the following commands: | ||
| - | <code bash> | ||
| - | kerosd -b | ||
| - | reboot | ||
| - | </code> | ||
| - | |||
| - | \\ | ||
| - | ==== Stock restore ==== | ||
| - | The stock firmware is backuped at production time (or when updated with a KerOS liveburner.ipk file). \\ | ||
| - | A “stock restore” will factory reset the station. All data will be lost. | ||
| - | To trigger a stock restore execute the following commands: | ||
| - | <code bash> | ||
| - | kerosd -s | ||
| - | reboot | ||
| - | </code> | ||
| - | |||
| - | ===== Store & Restore configuration ===== | ||
| - | |||
| - | The goal of this feature is to provide a simple method to keep some local configuration which could be erased otherwise during some particular operations on the devices. | ||
| - | Also this configuration could be stored, retrieved on a computer and applied on other devices. | ||
| - | |||
| - | <note tip>For the sake of clarity, the configuration storing step is never done automatically, so whatever is done we must keep in mind that manual store configuration should be done. | ||
| - | </note> | ||
| - | |||
| - | ==== Store Configuration ==== | ||
| - | |||
| - | To store the global configuration use the command : | ||
| - | |||
| - | <code bash>store-config</code> | ||
| - | |||
| - | If no file list is given, then ''/user/login'' and ''/user/rootfs_rw/*'' files are stored. Help menu can be displayed with the command ''store-config -h''. | ||
| - | |||
| - | <code> | ||
| - | root@klk-lpbs-04018B:~ # store-config -h | ||
| - | |||
| - | Syntax: | ||
| - | /usr/sbin/store-config -h : this help | ||
| - | /usr/sbin/store-config -l : list of files to be stored | ||
| - | /usr/sbin/store-config -p : store the password file | ||
| - | | ||
| - | Store the files given as argument in an archive for later use. | ||
| - | If no file list is given, then automatically /user//login /user//rootfs_rw files are stored. | ||
| - | The counterpart of this command is restore_config, to restore the files. | ||
| - | root@klk-lpbs-04018B:~ # | ||
| - | </code> | ||
| - | After this, a file named ''saved-config.tar'' should be created in the directory ''/user/.backup/''. This file is just a basic tar archive without compression nor encryption. | ||
| - | |||
| - | <note important>On firmware v3.1.X it is not possible to store a list of file.</note> | ||
| - | |||
| - | Example with firmware v3.3.3: | ||
| - | <code> | ||
| - | # store-config -l /user/test1 /user/test2 | ||
| - | Archiving file : tar: removing leading '/' from member names | ||
| - | Done | ||
| - | </code> | ||
| - | |||
| - | After this, a file named ''saved-config.tar'' should be created in the directory ''/user/.backup/'' | ||
| - | This file is just a basic tar archive without compression nor encryption. | ||
| - | |||
| - | <code> | ||
| - | # ll /user/.backup/ | ||
| - | drwxr-xr-x 2 root root 4.0K Feb 21 08:54 . | ||
| - | drwxr-xr-x 7 root root 4.0K Feb 20 16:22 .. | ||
| - | -rw-r--r-- 1 root root 2.0K Feb 21 08:54 saved-config.tar | ||
| - | |||
| - | # tar -tf /user/.backup/saved-config.tar | ||
| - | user/test1 | ||
| - | user/test2 | ||
| - | |||
| - | </code> | ||
| - | |||
| - | ==== Restore Configuration ==== | ||
| - | |||
| - | To restore the global configuration please use the command : | ||
| - | <code bash>restore-config</code> | ||
| - | |||
| - | All previously stored files will be restored in their original places, and overwrite the files already in place if any. | ||
| - | |||
| - | A particular case is when we restore a configuration, but in the meanwhile an upgrade has been done and new users has been added. | ||
| - | Then in such a case, an automatic merge of the password file is applied. | ||
wiki/features.1535531165.txt.gz · Last modified: 2019/01/17 10:01 (external edit)
