ZFS: deferring automounts/mounting root without bootfs
[9.0-BETA2]
Andriy Gapon
avg at FreeBSD.org
Mon Sep 19 20:43:57 UTC 2011
on 19/09/2011 19:15 Rotate 13 said the following:
> On Mon, 19 Sep 2011 11:44:18 -0400, Andriy Gapon <avg at freebsd.org> wrote:
>
>> on 19/09/2011 18:29 Rotate 13 said the following:
>>> 9.0-BETA2 system is booted off removable UFS volume, but root is
>>> mounted from ZFS. I try to meet the following two goals:
>>>
>>> 1. Not use bootfs property (too many limitations mentioned in docs)
>>
>>> 2. Use ZFS inheritable mountpoints and management (not clutter up
>>> /etc/fstab... and not set mountpoint= on each child dataset!)
>>>
>>> Config info is below. Result: System boots, but hangs with
>>>
>>> init: can't exec getty '/usr/libexec/getty' for port /dev/ttyv0: No
>>> such file or directory
>>
>> This looks like devfs (/dev) is either not mounted or something is
>> mounted over
>> it. I think that you should check if any other auto-mountable dataset
>> in your
>> pool has a mountpoint of '/'. Or the root dataset of tank is till
>> mounted for
>> some reason or something like that.
>
> Thanks for quick reply. No /dev was my first thought too. But I also
> saw other messages scroll by of unable to write in /var, which is on
> ZFS itself. So I think the "No such file or directory" probably for
> /usr/libexec/getty (cannot read /usr). Note also, root dataset is
> canmount=off - should not be ever mounted to begin with - and nothing
> except root dataset and tank/root have / mountpoint.
>
> I will see what I can do to verify devfs is being mounted, but
> definitely at least some ZFS dataset(s) are problem. Which brings me
> back my original question. Difficult to diagnose when system won't
> write logs to /var - could be very simple misconfiguration, could be
> bug. Manuals don't say a lot about mount order on boot, and that
> remains my suspicion due to behavior when zpool import -f from rescue
> shell: Can't mount /usr, /var, etc. until after tank/root is manually
> mounted, but after, zfs mount -a is magic.
You can try to enter ddb (if you have that in your kernel and also have the
magic ddb key enabled) and issue 'show mount' command to see some details.
--
Andriy Gapon
More information about the freebsd-fs
mailing list