
If the files /data/rcS.local or /data/rc.local exists, they will be called early (rcS) and late (rc) during startup. Therefore, the trick to make changes & modifications survive an update, is to put your (patch)files on /data, make them be (re-)installed automatically on startup. Some examples:Įverything, except for information on /data, will be wiped after an update. This will recover from issues caused by problems on the data partition, such as it being full or invalid settings or custom scripts.īut it will not recover from all possible mistakes that can be made. The factory reset procedure, as documented in the normal user manuals of the GX devices, removes everything from the data partition, except for the factory installed files.

And the other is that it (the pi) is a low cost device.

The advantage of a raspberrypi is that you can always start from scratch, by re-imaging the sdcard. Note that a solution to this is to do Venus OS experiments on a RaspberryPi rather than a real GX device.
#WINSCP ELEVATE TO ROOT HOW TO#
And if not fully bricked, then at least in a state from which there is no documentation nor support on how to recover. Chances of this are small (depending on what you do), but its certainly possible. It is possible to brick your GX deviceįor those unfamiliar with the term: Bricking means rendering it useless and unrecoverable.

Also there is a data partition (/data), which will be left alone in the image updates, and as such can be used to, upon boot, (re-)install certain changes onto the active rootfs. Of course it is always possible to disable automatic firmware updates. The complete rootfs is overwitten during an update. Your changes can be lost during a firmware updateĬhanges made to the rootfs will be lost in case of a firmware update.
