tristangrimaux wrote:In a wrt54g installing openvpn and almost anything else fills the entire filesystem and there is no other solution than reflashing.
You may always compile your own frimware from the OpenWRT sources and include in it the packages you _really_ need pre-installed on the squashfs.
You may always use the image builder to build up the firmware image with all the packages you _really_ need pre-installed on the squashfs.
You may always try to use extroot package on top of SD mod or USB stick (in case your router have got USB ports) to avoid the jffs2 usage.
tristangrimaux wrote:Right now I filled a router 200 miles away. So I have no choice of reflashing, not from here. Reflashing over the Internet, yeah! sure! NO WAY!
Just the same applies to any system administration task that may bring the device/server down. Reconfiguring network interfaces, changing firewall rules, restarting the device, installing new packages - any operations of such kind should only be done when you've got immediate physical access to the box in case something went wrong. Ignoring this rule will put you at risk of sitting 200 miles away from device moaning loudly "Ups, I bricked it again!".
tristangrimaux wrote:And everyone points to the user: you should check always first! C'MON!!! ITS A BUG!!! It's RIDICULOUS to have this kind of behavior on an OS used so WIDELY ON SMALL DEVICES!!!! PLEASE!!!
OpenWRT is not an "end-user" friendly OS. It require a lot of knowledge and *nix system administration skills in order to be used properly. Feel free to use more user-friendly firmwares like DD-WRT or even original vendor-supplied firmwares and you will be free from obeying the rule "triple check anything you type as root". Don't blame OS for it's extreme flexibility, blame yourself for not being able to use the system wisely.
tristangrimaux wrote:Every time I install something I have to make calculations and start to wonder if I'm doing things right.
By the way, opkg should refuse to install any package if it would not fit within free space on the root filesystem. At least it used to do so on the firmwares I recently compiled for the D-Link DIR-320 using the latest sources from SVN trunk. If it didn't warn you and then stalled/failed during the untaring of the package due to the lack of free space feel free to fire the bugreport to the openwrt bugtracker.
Another thing to note is that I've been able to recover from the fully filled jffs2 filesystem on one of the OpenWRT boxes by the simple deletion of files using "rm", but the minimal required amount of "free" space for filesystem to become writeable again was about 256Kb. Of course, YMMW.
Last but not least. If you feel yourself adventurous and lucky and you have got enough knowledge not to make any errors you may always proceed with backing up most essential configuration files, pivot_rooting back to the read only squashfs, creating tmpfs, populating it with minimal subset of files from "stucked" jffs2 partition, pivoting_root to mini_fo with the prepared tmpfs overlaid over the read only squashfs, using mtd to erase the contents of the jffs2 mtd partition (usually called rootfs_data), formating it back to jffs2, re-mounting and re-populating with the essential configuration files you had backed up earlier and finishing by pivot_rooting back to the mini_fo with newly formated jffs2 partition overlaid over the read only squashfs. It is very hard to do it successfully on a production system especially when you're far away from the box and use VPN link over internet to get into shell. But it is possible for sure: I had just given this procedure a try on one of the DIR-320 boxes I use for experiments with the openwrt.
(Last edited by lexa2 on 19 May 2010, 03:57)