How to increase size of /dev/md3
-
Running 2.4.3_p1 on a vanilla server.
Tried to log into the firewall via web interface and was handed an error message "502 Bad Gateway".
I ssh'ed into the firewall and immediately am being bombarded with error messages complaining there is no space left in /dev/md3 as follows:
[2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg: df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufsid/594b9a4d81439600 220275784 884412 201769312 0% / devfs 1 1 0 100% /dev /dev/md0 3484 160 3048 5% /var/run devfs 1 1 0 100% /var/dhcpd/dev /dev/md1 19356 7432 11540 39% /etc /dev/md2 31260 2644 26116 9% /usr/local/etc /dev/md3 31260 31260 -624 102% /var [2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg:
My system has 8GB of RAM so would like to expand /dev/md3 from 32MB to something bigger-- like 1GB. Or do away with /dev/md3 and move contents of /var to the root partition.
I tried:
[2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg: mdconfig -r -s 1GB -u md3 mdconfig: ioctl(/dev/mdctl): Operation not supported [2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg:
It fails.
How do I modify the size of /dev/md3 using pfsense? FreeBSD has examples of resizing memory disks but these don't appear to work within pfsense. /etc/fstab doesn't contain any references to such. I.e.:
[2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg: cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ufsid/594b9a4d81439600 / ufs rw 1 1 /dev/label/swap0 none swap sw 0 0 [2.4.3-RELEASE][user@firewall.dawnsign.com]/var/cache/pkg:
Is it safe to delete or move files from /var/cache/pkg to a temporary location in order to free up working space in /var?
~Doug
-
I moved a large file from /var/cache/pkg to /root and now there's some breathing room in /var. I restarted PHP-FPM and also restarted the WebConfigurator. Each time I restarted, I received the following:
Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/pfSense.so' - Shared object "libvstr-1.0.so.0" not found, required by "libstrongswan.so.0" in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/curl.so' - Shared object "libnghttp2.so.14" not found, required by "libcurl.so.4" in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/pfSense.so' - Shared object "libvstr-1.0.so.0" not found, required by "libstrongswan.so.0" in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/rrd.so' - Shared object "libiconv.so.2" not found, required by "libglib-2.0.so.0" in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/zmq.so' - Shared object "libnorm.so.1" not found, required by "libzmq.so.5" in Unknown on line 0
What steps are recommended in order to resolve the missing dynamic libraries?
~Doug
-
If you are now able to use the web GUI, System/Advanced/Miscellaneous will let you size /var and /tmp. There is a note about not making /var smaller than 60 (MiB).
From SSH, /conf/config.xml is where that size is held. Edit at your own risk (i.e. back the file up externally first and be prepared to do a complete reinstall if things go sour).
I believe <use_mfs_var_size> is the element you seek. You probably have a value near 32 there. If so, just delete the 32, leave the element empty and that will get you the default of 60. If you don't have a 32 there, then something else is going on and I'd back out any change.
I expect you'll need to reboot to pick up the changes.
-
It looks you have done some customising on the filesystem there so pretty much anything could happen.
If you move /var and /tmp to RAM via the GUI you would not have /var/run as a separate ram drive.
Why do you have /etc as a ram drive? I can only imagine bad things happening doing that.
I would suggest re-installing, enabling the RAM drives through the GUI and going from there unless you have something in your config that cannot be easily re-created. If you restore your current config with the RAM drives set they will be re-created as intended but obviously without /var/ram and /etc as separate drives.
Steve
-
I examined the /conf/config.xml and found no instance of <use_mfs_var_size> or anything remotely like that.
I cannot access the webGUI so am at loss as to what to do here. Is there another XML file that deals with the filesystems and/or hardware?
~Doug
-
They would be in the config file if they had been set in gui. In the <system> section at the top:
<use_mfs_tmp_size>80</use_mfs_tmp_size> <use_mfs_var_size>120</use_mfs_var_size> <use_mfs_tmpvar></use_mfs_tmpvar>
Given that you have 4 ramdrives there anyway those have been added some other way. We can only guess.
You can check /etc/fstab but that is usually overwritten at some point so if all 4 drives are shown there they are probably being set somehow.Steve
-
Well, well, it turns out after I decided to back up the config.xml file and to reboot, I asked that a file system check be performed. During the boot, I noticed a few filesystem errors that appeared to have been corrected. The firewall appears to have booted up normally and I am only seeing one md device titled md0.
[2.4.3-RELEASE][user@firewall.dawnsign.com]/root: mdconfig -l md0 [2.4.3-RELEASE][user@firewall.dawnsign.com]/root: df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufsid/594b9a4d81439600 220275784 895712 201758012 0% / devfs 1 1 0 100% /dev /dev/md0 3484 148 3060 5% /var/run devfs 1 1 0 100% /var/dhcpd/dev [2.4.3-RELEASE][user@firewall.dawnsign.com]/root:
I now could get into the webConfigurator. I no longer am seeing any PHP related errors nor any missing libraries errors.
I went to system-> advanced -> miscellaneous and checked out the values for var and tmp ramdisks. There were none inputed. The "Use RAM disk" checkbox was unchecked.
Honestly I don't know what to say at this point. Is it entirely possible that filesystem errors would cause the system to created three additional memory devices and assign certain file systems to each???
I couldn't find the output of the filesystem checks in either dmesg.boot nor in the system.log. I assume it is because the filesystem checks were performed prior to the system booting up normally.
Oh, it was about a week or two weeks ago when I applied the 2.4.3_p1 patch to this firewall. Are there any reports on this particular patch?
I will keep an eye on this and report if anything unusual comes up over the next few weeks.
~Doug
-
Hmm, weird. I've never seen that before.
Hard to imagine filesystem corruption causing that directly. Perhaps you had an unapplied change there?
It seems more likely it got part way through a boot at some point but I still can't see how it would have ended up with those ram drives. Another admin attempting to recover the firewall?
Steve