On Sat, 30 Jan 2016 12:53:46 +0000 Steven Hartland <ste...@multiplay.co.uk> wrote:
> I just realised an important point, does your usb disk have a UFS > root partition and your internal disk ZFS root partition? Yes. That's it, as shown in my prior post (`gpart show` output). The USB memstick is dd'ed with memstick.img of head, so UEFI-enabled root-on-UFS installation without ZFS and starts bsdinstall if booted. And internal disks are both working root-on-ZFS installation, each of which have raw UFS partition (not inside ZFS pool) for (mostly for now) testing loader. > If so then I know what the issue is, I'll have quick look now, so wait for > a diff5 to appear before testing. I'll report later in reply to your another message (stating that Diff5 is available). But unfortunately, I have only one notebook (without serial I/F) as non-dead computer. So I wouldn't be able to report boot logs. Thanks in advance! > On Saturday, 30 January 2016, Steven Hartland <ste...@multiplay.co.uk> > wrote: > > > I did some more work on the review last night, if you could apply the > > latest patch set diff4 to see if that helps. > > > > If not compile with debugging using -DEFI_DEBUG on your make line then you > > will get a lot more information about which disk is being used to load from > > as well as info about the probe order. > > > > What you should see is that the disk you boot from (where boot1 is loaded > > from) should be probed first and hence get flagged as successful > > (preferred). > > > > This also shows up as * instead of + in the non-debug boot process. > > > > If this happens you should see loader.efi loaded from this disk and then > > the kernel. > > > > The debug output is verbose so you may need a serial console to be able to > > capture the output easily. > > > > Thanks for testing so far hopefully we can nail this soon 〓 > > On Saturday, 30 January 2016, Tomoaki AOKI <junch...@dec.sakura.ne.jp > > <javascript:_e(%7B%7D,'cvml','junch...@dec.sakura.ne.jp');>> wrote: > > > >> Thanks for your quick support! > >> I tried your patch [Diff1] (built with head r295032 world/kernel) and > >> now have good and bad news. > >> > >> Good news is that without USB memstick boot1.efi runs as expected. > >> Great! > >> > >> Bad news is that when booting from USB memstick (the one I used my > >> previous test, boot1.efi [bootx64.efi] and loader.efi is replaced) and > >> whichever of internal disk (ada[01]) have loader.efi in its ZFS pool, > >> ada[01] is booted instead of da0 (USB memstick). > >> > >> *If ada0 has loader.efi, always booted from ada0 (stable/10). > >> *If ada0 doesn't have loader.efi and ada1 has, booted from ada1 > >> (head). > >> *If both ada0 and ada1 don't have loader.efi, da0 (USB memstick) is > >> booted (head, installer is invoked). > >> > >> *Whichever ada[01] has loader.efi in their UFS or not didn't matter. > >> > >> These behaviour would be because ZFS thoughout all disks is tried > >> before trying UFS throughout all disks, if I understood correctly. > >> > >> Changing boot order (ZFS to UFS per each disk, instead of each > >> ZFS to each UFS) would help. > >> But providing ZFS-disabled boot1.efi (boot1ufs.efi?) for installation > >> media (memstick, dvd, ...) helps, too. I built ZFS-disabled boot1.efi > >> and it worked fine for USB memstick for me. > >> > >> *`make clean && make -DMK_ZFS=no` in sys/boot/efi/boot1 didn't disabled > >> ZFS module, so I must edit the definition of *boot_modules[] in > >> boot1.c. I'd have been missing something. > >> > >> Regards. > >> > >> > >> On Fri, 29 Jan 2016 02:58:26 +0000 > >> Steven Hartland <kill...@multiplay.co.uk> wrote: > >> > >> > On 28/01/2016 16:22, Doug Rabson wrote: > >> > > On 28 January 2016 at 15:03, Tomoaki AOKI <junch...@dec.sakura.ne.jp> > >> wrote: > >> > > > >> > >> It's exactly the NO GOOD point. The disk where boot1 is read from > >> > >> should be where loader.efi and loader.conf are first read. > >> > >> > >> > > I just wanted to note that gptzfsboot and zfsboot behaves this way. > >> Boot1 > >> > > looks for loader in the pool which contains the disk that the BIOS > >> booted. > >> > > It passes through the ID of that pool to loader which uses that pool > >> as the > >> > > default for loading kernel and modules. I believe this is the correct > >> > > behaviour. For gptzfsboot and zfsboot, it is possible to override by > >> > > pressing space at the point where it is about to load loader. > >> > > >> > I believe I understand at least some of your issue now, could you please > >> > test the code on the following review to see if it fixes your issue > >> please: > >> > https://reviews.freebsd.org/D5108 > >> > > >> > Regards > >> > Steve > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to " > >> freebsd-current-unsubscr...@freebsd.org" > >> > > >> > >> > >> -- > >> 青木 知明 [Tomoaki AOKI] > >> junch...@dec.sakura.ne.jp > >> mxe02...@nifty.com > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > >> " > >> > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- Tomoaki AOKI junch...@dec.sakura.ne.jp _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
