Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Background

Recently I have run into a bit of a snag on my home FreeBSD server. I recently upgraded it to the latest stable release, and I have noticed some strange behavior with the /var partition. Originally, I had the system configured such that /var had its own partition with /var/run and /var/log in memory disks (/tmp, too).

After the upgrade, I notice there is a new, fourth memory disk mounting directly to /var that I had not set up manually and is not in my fstab. It is only 28 megs or so in size and is causing problems when trying to update my ports collection. The ramdisk mounts atuomagically at boot and cannot be unmounted while in multi-user mode. If I drop to single user mode, I am able to unmount it without issue, however rebooting causes it to pop right back up.

System specifications have been included at the end of the post.

Question

Is there any way to determine exactly what is mounting a given memory disk (or any filesystem, for that matter) after it has been mounted?

Alternately, does anybody have any ideas what might have caused the new /var ramdisk to pop up?

System Specification

# uname -a

FreeBSD sarge 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Thu Nov 22 14:02:13 PST 2012     donut@sarge:/usr/obj/usr/src/sys/GENERIC  i386

# df

Filesystem   1K-blocks      Used     Avail Capacity  Mounted on
/dev/da0s1a     515612    410728     63636    87%    /
devfs                1         1         0   100%    /dev
/dev/da0s1d     515612    287616    186748    61%    /var
/dev/da0s1e    6667808   2292824   3841560    37%    /usr
/dev/md0         63004        32     57932     0%    /tmp
/dev/md1          3484         8      3200     0%    /var/run
/dev/md2         31260         8     28752     0%    /var/log
/dev/md3         31260       512     28248     2%    /var       <-- This

# cat /etc/fstab

# Device    Mountpoint  FStype  Options         Dump    Pass#
/dev/da0s1a /       ufs rw,noatime      1   1
/dev/da0s1d /var        ufs rw,noatime      2   2
/dev/da0s1e /usr        ufs rw,noatime      2   2
md      /tmp        mfs rw,-s64M,noatime    0   0
md      /var/run    mfs rw,-s4M,noatime     0   0
md      /var/log    mfs rw,-s32M,noatime    0   0   

Thank you in advance for any assistance.

share|improve this question

migrated from serverfault.com Nov 25 '12 at 20:50

This question came from our site for professional system and network administrators.

    
This is weird. Did the permissions on /var get mangled during the upgrade? Any settings in /etc/rc.conf that might affect /var? –  D_Bye Nov 26 '12 at 16:09
    
My rc.conf is pretty bare bones. I am at work, other wise I would post it directly. Long story short: it enables ZFS, sets the host name, and a few other items (Mostly related to jails). All configurations were present before the upgrade, and I verified that rc.conf was not altered. I even tried commenting out almost everything but ssh_enable, zfs_enable (note: the system root is NOT zfs), and setting the host name with no change. Can you explain a bit more on the permissions on /var and how that might cause it to be mounted to a memory disk? –  phobos51594 Nov 27 '12 at 21:12

1 Answer 1

up vote 1 down vote accepted

So, I appear to have fixed the problem. If anyone has anything to add as to the why / how, I am all ears.

Suspected Cause

From what I can tell, the cause of this behavior was corruption in the /var directory itself. The main drive that the operating system is installed on is a thumb drive (an old one, at that, but with precautions taken to prevent flash abuse). It would appear that a bad sector(s) was causing certain activities within /var to fail in a number of ways (the two most common were 'failed to create symlink' and outright kernel panics in /var/lost+found but there were others observed, too, depending on the exact activity).

The Fix

Once I fixed the corrupted inodes via a combination of single user mode, repeated fsck executions, and manual intervention the mystery /var memdisk stopped mounting at boot. For more information, see: http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/

The system is able to boot without the /var memdisk now, but a new thumb drive is in order, without a doubt.

Conjecture - Please correct or add to this if you possess any insight

This is where my knowledge about Unix behavior with bad filesystems gets fuzzy. My guess as to why the memdisk popped up is that FreeBSD was able to mount the /var partition itself but access to certain items failed. In order to keep the system up and running, my suspicion is that the operating system created the memdisk out of necessity (hence the two mounts under /var). This was not apparent before because most of the corruption was in a non-critical directory. Perhaps the update shifted the files around on the physical disk itself, thereby putting another, more important, file in the failing sector(s)?

Again, any further insight into how the corruption lead to a mystery memdisk is greatly appreciated. Thanks again.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.