Mounting nullfs fails

Snurg

Snurg

I followed the instructions in the FreeBSD handbook. But I am stuck with this on a 11-RC1 machine:

Code: 
# mount -t nullfs /usr/home/j/mroot /usr/home/j/www
mount_nullfs: /usr/home/j/www: Operation not supported by device
# kldstat
<snip>
2       1 0xfffffffff80fcb000  b1a0  nullfs.ko
<snip>
# ls -ld /usr/home/j/mroot
drwxr-xr-x  14 root  wheel     20 Aug 16 19:25 /usr/home/j/mroot
# ls -ld /usr/home/j/www
drwxr-xr-x  2 root  wheel     20 Aug 16 19:27 /usr/home/j/www
#

I had nullfs_load="YES" in /boot/loader.conf. Did not work.
Adding options NULLFS to the kernel configuration didn't change anything.

Any idea what mistake could I have made?
 
As it is RC version something could be broken that will get fixed.
What are those directories ? Do df -m /usr/home/j/mroot /usr/home/j/www and share the output.
 
Code: 
# df -m /usr/home/j/mroot /usr/home/j/www
Filesystem        1M-blocks Used  Avail Capacity  Mounted on
cesspool/usr/home    268973 1783 267190     1%    /usr/home
cesspool/usr/home    268973 1783 267190     1%    /usr/home
#
ZFS pool is named "cesspool" instead of the default "ztank". Aside of that the pool configuration is just the default the installer dvd used.
 
It doesn't matter how you call your zpool. I wanted to know if you are not crossing mountpoints with something like NFS, etc. The mount you are trying to do should be working:

Code: 
# zfs list -r portal/ft
NAME  USED  AVAIL  REFER  MOUNTPOINT
portal/ft  384K  1.89T  192K  /mnt/ft
portal/ft/home  192K  1.89T  192K  /mnt/ft/home
#
# cd /mnt/ft/home/j/
# ll
total 2
drwxr-xr-x  4 root  wheel  4 Aug 28 01:59 .
drwxr-xr-x  3 root  wheel  3 Aug 28 02:00 ..
drwxr-xr-x  2 root  wheel  3 Aug 28 01:59 mroot
drwxr-xr-x  2 root  wheel  2 Aug 28 01:59 www
#
# mount -t nullfs /mnt/ft/home/j/mroot /mnt/ft/home/j/www
# mount | grep ft
portal/ft on /mnt/ft (zfs, local, noatime, nosuid, nfsv4acls)
portal/ft/home on /mnt/ft/home (zfs, local, noatime, nosuid, nfsv4acls)
/mnt/ft/home/j/mroot on /mnt/ft/home/j/www (nullfs, local)
#
It may be related to the RC version as release version of 11 is still not out yet.
 
Thank you matoatlantis for your assistance!
This is a quite fresh-installed system.
Basically I installed it from DVD, set up the basic networking to be able to connect to the internet and then attempted to set up a jail for running apache.
However I have made a custom kernel because I wanted sc (including some console color and history options) instead of vt and removed lots of unused drivers (for hardware that I do not have) from the kernel.
Maybe I should consider filing a bug report?
Anyway I guess I should retest with GENERIC kernel. Will post the results tomorrow as it is late night here now!
 
As it is RC (release candidate) I would not open PR yet.

I did download the VM image of RC1 and did the test:

Code: 
root@:~ # uname -a
FreeBSD  11.0-RC1 FreeBSD 11.0-RC1 #0 r303979: Fri Aug 12 02:28:24 UTC 2016  root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@:~ #
root@:~ # zfs list -r tpool
NAME  USED  AVAIL  REFER  MOUNTPOINT
tpool  114K  960M  19K  /tpool
tpool/usr  20.5K  960M  20.5K  /mnt/usr
root@:~ #
root@:~ # mount | grep usr
tpool/usr on /mnt/usr (zfs, local, nfsv4acls)
/mnt/usr/j/mroot on /mnt/usr/j/www (nullfs, local)
root@:~ #
Do boot to GENERIC kernel and retry.
 
With GENERIC kernel it worked.
As I wanted to know what caused the problem I did some iterative config stripdowns + kernel rebuilds and found out that apparently the ata device driver breaks things.
(The ata driver is required for cdrecord, which I intended to use to make backups)
If the ata driver is included in the kernel device options, mount_nullfs will mount the nullfs but warn with the following message:
Code: 
# mount -t nullfs /usr/home/j/mroot /usr/home/j/www
mount_nullfs: /usr/home/j/www: Resource deadlock avoided
#
If COMPAT_43 (and/or?) NULLFS are part of the kernel in addition to ata, mount_nullfs completely fails with the message "Operation not supported by device".
 
If you plan to use that server for something meaningful I'd recommend to stick with the GENERIC kernel. If it's not the embedded system you are trying to install it on you'll gain very little if anything.
 
Basically you are absolutely right to always use a generic kernel for servers.

But what if the generic kernel cannot be used right away because it lacks an essential driver for SATA burners?

The FreeBSD handbook instructs to build a kernel with the ata driver for cd/dvd burning. Doing this should not break other functionality imho.

If this is not considered as a bug, there should imho at least be some warning in the handbook about the side effects.
I guess this justifies filing a bug report.
 
Since 10.x everything is treated as SCSI now. There's no difference between ATA and SCSI anymore. The instructions for ATAPI burners is mostly for 9.x.
 
Does this mean all these instructions in the handbook and in the post-install-messages of programs like K3b about having to include the ata driver are outdated and can safely be ignored?

Would it make sense to file bug reports (in the sense of documentation update requests) so that outdated information can be updated or clarified (i.e. by mentioning that from 10.0 the ata driver is no longer needed)?
 
You must log in or register to reply here.
Back
Top