Solved Mount Gives Error After Labeling

Sevendogs

Sevendogs

I searched for my exact issue and couldn't find it so am posting. I labeled my file systems using gpart modify -i X -l LABEL DISK. All the FreeBSD disks in my machine are GPT. This worked fine. I edited /etc/fstab accordingly and the system boots fine, except right before hitting the login prompt I get a message that says:
Code: 
mount /dev/da0p1: operation not permitted
. After waiting a few seconds the system boots successfully and I can login with my normal user.

The partition in question is my user's home directory and is on a separate disk. No issues after logging in, running X, etc. Not sure what mount is erroring on. Is there a log I can look at that may show more detail?

Here is the contents of /etc/fstab:
Code: 
# Device  Mountpoint  FStype  Options Dump  Pass#
/dev/gpt/bzrootfs /  ufs  rw  1  1
/dev/gpt/bzswap none  swap  sw  0  0
/dev/gpt/bzhomefs /usr/home  ufs  rw  2  2
/dev/gpt/bzbackfs /mnt/backups  ufs  rw  2  2

#File system for tmpfs
tmpfs  /tmp  tmpfs  rw,mode=777 0  0

I can post the output of gpart list if necessary. I have matched the label names in /etc/fstab to the contents of
Code: 
/dev/gpt
and they match.

Thanks in advance.
 
I'd look for what is referring to da0p1. Due to the name, that might be a USB drive. Are you using some sort of automounter? As root, does grep -r da0p1 /etc/* find anything?

Also, the permissions on /tmp/ should be 1777.
 
Thanks for the reply - da0p1 is the drive where my user's home directory is. The command you suggested didn't find anything other than the backup of the /etc/fstab file I did prior to making the changes to labels instead of dev device references. It's odd for sure - I kept thinking automount is causing an issue because in /var/log/automount.log I see the following entries:
Code: 
2016-08-21 17:59:31 /dev/da0p1: random wait for '1.6' seconds before 'attach' action
2016-08-21 17:59:31 /dev/da0p1: attach
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** /dev/da0p1 (NO WRITE)
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Last Mounted on /usr/home
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Phase 1 - Check Blocks and Sizes
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Phase 2 - Check Pathnames
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Phase 3 - Check Connectivity
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Phase 4 - Check Reference Counts
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs ** Phase 5 - Check Cyl groups
2016-08-21 17:59:35 /dev/da0p1: fsck_ufs 64272 files, 19016319 used, 102080553 free (39249 frags, 12755163 blocks, 0.0% fragmentation)
2016-08-21 17:59:35 /dev/da0p1: mount failed (ufs) 'mount -t ufs -o noatime /dev/da0p1 /media/da0p1'

I see entries like this for the two drives on the SCSI bus of my workstation. The two drives are my user's home and my backup drive. My particular workstation has four drives: the two on the bottom bays can be set to raid but they are not. This configuration has worked fine for some time, until today when I implemented disk labels and noticed the error message. I am going to try to disable automounting and see if the errors go away. I just noticed the mount attempt is trying to mount on /media/da0p1 which is incorrect but what automount does by default. I think automount is seeing those two drives as removeables, which they are not. I wonder if it's possible to configure automount to ignore them? Back to Google :)
 
Well, I don't know if we want to call this one "solved" - the errors went away once I pulled autofs_enable="YES" from /etc/rc.conf and uninstalled automount. I don't really mount external drives very often, I was just trying to recreate the experience I had on my old Linux desktop where I could plug in a thumbdrive and it would mount automatically. In retrospect, I don't do it very often so it's not a big deal. I'll keep poking around to see if there are any options for the automount configuration that tells it to ignore entries in /etc/fstab.

Thanks all for the help!
 
There is the built-in autofs(8) and if you uninstalled something, possibly you also had an automounter from ports. Potential conflict over the same media.
 
Bingo! That's exactly the situation. I did install automounter from ports. I guess I can re-enable autofs in RC.conf. I'll give that a shot tomorrow and see what happens. Thanks :)
 
You must log in or register to reply here.
Back
Top