Date: Wed, 17 Nov 2010 16:10:35 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement) Message-ID: <AANLkTi=cZL5Sqr-tHcP-sh6URL2QHB41JkFxvJM_uK0A@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar <xcllnt@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. =A0One item
>> that has always bugged me is why when we hit the prompt that has to be
>> the end of discovery... =A0Why 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:
> =A0 =A0 =A0 =A0.select /dev/cd0 /dev/acd0
> =A0 =A0 =A0 =A0cd9660:%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=3Dnfs (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 =3D 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).
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=cZL5Sqr-tHcP-sh6URL2QHB41JkFxvJM_uK0A>