Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)
On Nov 17, 2010, at 4:10 PM, Garrett Cooper wrote: 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): The syntax is $fs:$dev. For NFS $dev can be empty, leaving nfs:. The problem is with there not being a colon after nfs in your case. This could be a change in behaviour from before, which probably needs a fix. I'll look into it... 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 The filename to use is /.mount.conf. Notice the period. -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)
On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar xcl...@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 12 ] 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)
On Wed, Nov 17, 2010 at 4:10 PM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar xcl...@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 12 ] 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
