Date: Wed, 17 Nov 2010 16:31:37 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement) Message-ID: <AANLkTi=EJ1n_-c2OknHWUVOJSDHicuVOGYPNChwJ1-4x@mail.gmail.com> In-Reply-To: <AANLkTi=cZL5Sqr-tHcP-sh6URL2QHB41JkFxvJM_uK0A@mail.gmail.com> References: <AANLkTi=cZL5Sqr-tHcP-sh6URL2QHB41JkFxvJM_uK0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 17, 2010 at 4:10 PM, Garrett Cooper <yanegomi@gmail.com> wrote: > 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, > =A0 =A0Do 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 =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$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 > > =A0 =A0I 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. > =A0 =A0It seems to ignore the directives in mount.conf: > > # cat mount.conf > .onfail continue > .ask > > =A0 =A0and 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=EJ1n_-c2OknHWUVOJSDHicuVOGYPNChwJ1-4x>