Date: Sat, 30 Jan 2016 12:53:46 +0000 From: Steven Hartland <steven@multiplay.co.uk> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: ZFSROOT UEFI boot Message-ID: <CAHEMsqbhXuFNkWELSvHM3xk1eQ5SKZF825SPNQRfJbWNghAFpQ@mail.gmail.com> In-Reply-To: <CAHEMsqaRm_Za7T44mRNRtayBxNvAuX6LtZBwQyV_bosfuwa12g@mail.gmail.com> References: <CALfReyeY3=L9O81AX7xMKj3Ai2DTvBpXtbqepTZc2%2BGEsrT3vA@mail.gmail.com> <8991747525093115430@unknownmsgid> <20160124215300.4cd7f1207f5a4c7b28ef7ffc@dec.sakura.ne.jp> <56A51A4C.1040808@multiplay.co.uk> <20160129000344.feaf5f828e5d43d5fbbb652a@dec.sakura.ne.jp> <CACA0VUiwF=40n0TNSfTAnbHY-1xLMytOzeXjnufF%2BoPKRbvBew@mail.gmail.com> <56AAD552.9090202@multiplay.co.uk> <20160130155755.485736c8e12868663b9ccfbc@dec.sakura.ne.jp> <CAHEMsqaRm_Za7T44mRNRtayBxNvAuX6LtZBwQyV_bosfuwa12g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I just realised an important point, does your usb disk have a UFS root partition and your internal disk ZFS root partition? If so then I know what the issue is, I'll have quick look now, so wait for a diff5 to appear before testing. On Saturday, 30 January 2016, Steven Hartland <steven@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 yo= u > will get a lot more information about which disk is being used to load fr= om > 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 t= o > capture the output easily. > > Thanks for testing so far hopefully we can nail this soon =F0=9F=98=8A > On Saturday, 30 January 2016, Tomoaki AOKI <junchoon@dec.sakura.ne.jp > <javascript:_e(%7B%7D,'cvml','junchoon@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=3Dno` in sys/boot/efi/boot1 didn't disabl= ed >> 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 <killing@multiplay.co.uk> wrote: >> >> > On 28/01/2016 16:22, Doug Rabson wrote: >> > > On 28 January 2016 at 15:03, Tomoaki AOKI <junchoon@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 correc= t >> > > 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 plea= se >> > 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-unsubscribe@freebsd.org" >> > >> >> >> -- >> =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E [Tomoaki AOKI] >> junchoon@dec.sakura.ne.jp >> MXE02273@nifty.com >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHEMsqbhXuFNkWELSvHM3xk1eQ5SKZF825SPNQRfJbWNghAFpQ>