Yep, I can confirm that r326772 introduced the bug, and it is fixed by r326784. Thanks for the quick turnaround. -Alan On Mon, Dec 11, 2017 at 4:16 PM, Warner Losh <imp_at_bsdimp.com> wrote: > Ooops I lied. r326784 should fix it. Now I have flight attendants yelling > at me to put this computer away.... > > Warner > > On Mon, Dec 11, 2017 at 4:06 PM, Warner Losh <imp_at_bsdimp.com> wrote: > >> I'm seeing the same bug in my qemu VM setup. I'm about to land, so won't >> likely be able to fix this until I get to the hotel, but I'm pretty sure >> that I know what caused it. I didn't notice it before the commit (I gotta >> get a better regression suite in place for this stuff, rather than the >> ad-hoc testing I've been able to do). >> >> Warner >> >> On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers <asomers_at_freebsd.org> wrote: >> >>> On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh <imp_at_bsdimp.com> wrote: >>> >>>> >>>> >>>> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers <asomers_at_freebsd.org> >>>> wrote: >>>> >>>>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh <imp_at_bsdimp.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers <asomers_at_freebsd.org> >>>>>> wrote: >>>>>> >>>>>>> I just upgraded my head machine to r326772. Now, boot2 can't find >>>>>>> the >>>>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>>>> because >>>>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>>>> /boot/loader" I get the error "don't know how to load module >>>>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>>>> introduced since then. Any ideas? >>>>>>> >>>>>>> BTW, I can successfully boot with the following commands: >>>>>>> unload >>>>>>> load /boot/kernel/kernel >>>>>>> load zfs >>>>>>> boot >>>>>>> >>>>>>> http://bayimg.com/iAKmFaAgl >>>>>> >>>>>> >>>>>> I'd bisect :) >>>>>> >>>>>> However, try to update to just before this commit: >>>>>> >>>>>> Author: imp <imp_at_ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f> >>>>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>>>> >>>>>> Create interp class. >>>>>> >>>>>> Create an interp class. Use it to separate out the different >>>>>> types of >>>>>> interpreters: forth and simple with function pointers rather than >>>>>> via #ifdefs. >>>>>> >>>>>> Obtained from: lua boot loader project >>>>>> (via https://bsdimp_at_github.com/bsdimp/freebsd.git >>>>>> lua-bootloader) >>>>>> Sponsored by: Netflix >>>>>> >>>>>> >>>>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head_at_326712 >>>>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>>> >>>>>> would be a good place to start. >>>>>> >>>>>> It's a shame we can't create zpool images with an unpriv'd user >>>>>> command. Would help out the ZFS testing of the boot loader refinement. >>>>>> >>>>>> Warner >>>>>> >>>>> >>>>> If I bisect this, what parts do I need to reinstall each time? A full >>>>> buildworld would be too slow. Is it sufficient to reinstall stand? >>>>> >>>> >>>> Just rebuild stand, reinstall it and reboot. >>>> >>>> Also, why are you trying to load /boot/loader from /boot/zfsloader? >>>> That has me confused. The screen shot looks like it found the kernel OK and >>>> was going to boot it, but then you interrupted it, unloaded it and tried to >>>> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >>>> something like that? >>>> >>>> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the >>>> real bug here is that the menu has stopped working leading to your >>>> confusion... >>>> >>> >>>> Warner >>>> >>> >>> It certainly could be a bug in the menu. I'm definitely confused, >>> because this is a domain I've seldom dealt with, since it usually just >>> works. If I'm actually in /boot/loader, then there are two problems: >>> 1) The menu isn't working >>> 2) The loader isn't reading /boot/loader.conf. >>> >> >> >Received on Mon Dec 11 2017 - 22:33:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC