Remounting embedded filesystem

stephenw10

As I understand it the correct way to remount the file system of a NanoBSD install in order to add packages or edit a file from the CLI is to use.

/etc/rc.conf_mount_rw
then
/etc/rc.conf_mount_ro

That has worked for me fine. However I, and many others, have run into a problem.
I'm running a Watchguard Firebox and in order to use the LCD there is a tar ball consisting of a special driver and an install script. The script works like so:

mount -u -w /

Copy the stuff across and fix the permissions.

mount -u -r /

This was all fine upto Beta4. However recent snapshots have a problem. It seems that having run the mount command, via the script, rc.conf_mount_rw (or ro) is no longer able to function.


[2.0-BETA5][root@pfSense.localdomain]/lib(48): mount -u -r /
[2.0-BETA5][root@pfSense.localdomain]/lib(49): mount -p
/dev/ufs/pfsense0       /                       ufs     ro              1 1
devfs                   /dev                    devfs   rw              0 0
/dev/md0                /tmp                    ufs     rw              2 2
/dev/md1                /var                    ufs     rw              2 2
/dev/ufs/cf             /cf                     ufs     rw              1 1
devfs                   /var/dhcpd/dev          devfs   rw              0 0
[2.0-BETA5][root@pfSense.localdomain]/lib(50): /etc/rc.conf_mount_rw
[2.0-BETA5][root@pfSense.localdomain]/lib(51): mount -p
/dev/ufs/pfsense0       /                       ufs     ro              1 1
devfs                   /dev                    devfs   rw              0 0
/dev/md0                /tmp                    ufs     rw              2 2
/dev/md1                /var                    ufs     rw              2 2
/dev/ufs/cf             /cf                     ufs     rw              1 1
devfs                   /var/dhcpd/dev          devfs   rw              0 0
[2.0-BETA5][root@pfSense.localdomain]/lib(52):

Any thoughts? Is this the expected behavior?

At the moment I'm reworking the script but I'd love to know why it suddenly became broken.

Steve

stephenw10

I reflashed my CF card with pfSense-2.0-BETA5-1g-i386-20110209-1815-nanobsd.img.gz.

Having done nothing but setup my interfaces I am seeing this:

[2.0-BETA5][root@pfSense.localdomain]/root(1): mount -p
/dev/ufs/pfsense0       /                       ufs     rw              1 1
devfs                   /dev                    devfs   rw              0 0
/dev/md0                /tmp                    ufs     rw              2 2
/dev/md1                /var                    ufs     rw              2 2
/dev/ufs/cf             /cf                     ufs     rw              1 1
devfs                   /var/dhcpd/dev          devfs   rw              0 0

Is this right? Everything is mounted R/W by default. I thought that the flash card was supposed to be R/O to prevent excessive writes. ???

Steve

jimp

Hmm, it should be r/o. Not sure what might be leaving it r/w.

stephenw10

This is defininately broken.


[2.0-BETA5][root@pfSense.localdomain]/tmp(24): mount -p
/dev/ufs/pfsense0       /                       ufs     rw              1 1
devfs                   /dev                    devfs   rw              0 0
/dev/md0                /tmp                    ufs     rw              2 2
/dev/md1                /var                    ufs     rw              2 2
/dev/ufs/cf             /cf                     ufs     rw              1 1
devfs                   /var/dhcpd/dev          devfs   rw              0 0
[2.0-BETA5][root@pfSense.localdomain]/tmp(25): /etc/rc.conf
rc.conf_mount_ro* rc.conf_mount_rw*
[2.0-BETA5][root@pfSense.localdomain]/tmp(25): /etc/rc.conf_mount_ro
[2.0-BETA5][root@pfSense.localdomain]/tmp(26): mount -p
/dev/ufs/pfsense0       /                       ufs     rw              1 1
devfs                   /dev                    devfs   rw              0 0
/dev/md0                /tmp                    ufs     rw              2 2
/dev/md1                /var                    ufs     rw              2 2
/dev/ufs/cf             /cf                     ufs     rw              1 1
devfs                   /var/dhcpd/dev          devfs   rw              0 0

The Dec 17th Beta4 snapshot was fine. By Jan 13th Beta5 rc.conf_mount had stopped working.
I guess there isn't anything writing to the cf card anyway but still.

Steve

jimp

I opened a ticket for this:
http://redmine.pfsense.org/issues/1279

Though honestly in the grand scheme of things there really isn't much risk here unless it's self-inflicted. :-)

The system itself doesn't try to write without first doing the rw switch anyhow, any processes that try to write out data constantly are using /tmp and/or /var which are RAM disks. There aren't any system processes that are really held at bay by the ro/rw switch. Not sure 100% about all the packages but the base system itself should be fine.

stephenw10

Good to know I'm not toasting my CF card(s).
Self inflicted damage does seems to be a reoccurring problem for me. ::) I doubt this will help though!

Steve

jdamnation

Can I just add a note here?

I loaded the pfSense-2.0-RC1-1g-i386-20110226-1633-nanobsd.img.gz to a 1GB flash and it seems that the file system for this was r/w after boot.

I then proceeded to upgrade, which went OK and loaded the latest update.

However, after rebooting with the latest update the file system is still r/w.

When I loaded a latest base image from snapshots, then the file system was r/o.

Can someone explain why my updated 1GB nano build is still r/w - it's essentially the same build at the latest base version.

Cheers,

JD