Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)

From: Garrett Cooper <yanegomi_at_gmail.com>
Date: Wed, 17 Nov 2010 16:31:37 -0800
On Wed, Nov 17, 2010 at 4:10 PM, Garrett Cooper <yanegomi_at_gmail.com> wrote:
> On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar <xcllnt_at_mac.com> wrote:
>>
>> On Sep 28, 2010, at 10:27 AM, M. Warner Losh wrote:
>>
>>> Hey Marcel,
>>>
>>> haven't had a chance to look through this in detail yet.  One item
>>> that has always bugged me is why when we hit the prompt that has to be
>>> the end of discovery...  Why can't we have a method to listen to new
>>> geom providers being advertised and then 'short circuit' the ask
>>> prompt if /dev/da0s1a or /dev/ufs/rootfs or whatever it originally
>>> wanted appears.
>>>
>>> Maybe this isn't .ask, but some other verb in your language?
>>
>> Hmmm... I think we should give .ask an option so that it can be
>> made conditional upon a key press then. I don't think it's nice
>> to print all that stuff, present a prompt, wait for input and
>> then shortly after continue booting anyway because some device
>> showed up.
>>
>> Say we have ".ask on-key-press", which basically nullifies the
>> .ask directive (by implicitly failing to mount) unless a key was
>> pressed. At that time we actually print the help, show a prompt
>> and wait for input. This in combination with ".onfail retry"
>> allows us to cycle through the alternatives until 1) a key was
>> pressed and we'll drop at the interactive mount prompt or 2) a
>> device we've been waiting for appears and we can mount root.
>>
>> Would that address your case?
>>
>> Another feature we may need is the alternative: if you boot
>> with -C, we'll try cd9660:/dev/cd0 and cd9660:/dev/acd0. What
>> we really want to do is:
>>        .select /dev/cd0 /dev/acd0
>>        cd9660:%selected%
>
> Hi Marcel,
>    Do you have any examples that use nfs rootfs's out of the box that
> work with the new logic that don't involve creating an mfsroot? I keep
> on running into this error with vfs.root.mountfrom=nfs (previously on
> CURRENT it would just try to mount nfs via nfs_mount in the NFS client
> without any complaints):
>
> Root mount waiting for: usbus2
> uhid0: <Dell USB Keyboard Hub> on usbus2
> panic: mountroot: unable to (re-)mount root.
> cpuid = 10
> KDB: enter: panic
> [ thread pid 1 tid 100002 ]
> Stopped at      kdb_enter+0x3d: movq    $0,0x6e60e0(%rip)
> db> continue
> Uptime: 13s
> Cannot dump. Device not defined or unavailable.
> Automatic reboot in 15 seconds - press a key on the console to abort
>
>    I don't run into this error when I unset this variable sometimes
> (it boots up multiuser and all is happy, hunky dory when I manually
> query this variable from the pxeboot loader, but not when I don't...
> it's weird).

I would ignore this piece of information. I might have been picking up
a stale copy of pxeboot that was working by accident. I'll look into
this issue further to see whether or not that was that root cause.

>    It seems to ignore the directives in mount.conf:
>
> # cat mount.conf
> .onfail continue
> .ask
>
>    and always panics for no good reason (and gets stuck so I have to
> powercycle the machine manually, but that's a different issue
> entirely).

Thanks,
-Garrett
Received on Wed Nov 17 2010 - 23:31:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC