Thanks for doing that it was very helpful, and I know transcribing from
video would have been quite a time consuming task.
I noticed a few interesting facts:
1. It looks like when you boot from ada0 and ada1 its still picking the
same device (according to device order).
Its not 100% clear as your devices are sata which Diff 6 didn't have
decoding for. I've added that now so hopefully we can confirm, also
added output of boot1 imgpath: so we can see what the EFI thinks the
boot device is.
2. Your usb device path has two message path entries which means
msg_paths_match would result in a false positive for usb devices, this
is now fixed by matching until we see a media path.
If you can now re-test the following two cases:
2) Boot from ada0 without USB memstick attached (2 drives).
3) Boot from ada1 without USB memstick attached (2 drives).
I'm interested to confirm two things:
1. If the boot1 imgpath lines do indeed vary
2. If the "load: '/boot/loader.efi'" line devpath matches the boot1 imgpath.
The changes from Diff 7 shouldn't effect the outcome of the other tests,
but confirming that too wouldn't hurt but no need for the output.
Regards
Steve
On 31/01/2016 11:43, Tomoaki AOKI wrote:
I found Diff6 you uploaded to PHABRICATOR. So my report below is based
on it.
The patched boot1.efi runs as expected (== as you wrote) for me.
*boot1.efi without -DEFI_DEBUG isn't tested. Needed?
As I mentioned in my previous post, I have no serial console
environment. So I took movie of limited tests and typed it.
Which of the tests are typed:
1) Boot from ada0 removing ada1, no USB memstick attached, ZFS in
ada0 has loader.efi. (Single drive config.)
2) Boot from ada0, no USB memstick attached, ZFS in ada0 has
loader.efi.
3) Boot from ada1, no USB memstick attached, ZFS in ada1 has
loader.efi.
4) Boot from ada1, no USB memstick attached, only UFS in ada0 has
loader.efi.
5) Boot from da0 (USB memstick with memstick.img of head).
UFS in da0 has loader.efi and ZFS isn't present in da0.
(3 drives [2 drives + USB memstick] config.)
Please see attached text for detail. Are more outputs needed?
Thanks in advance! I'm looking forward to see this MFC'ed before
releng/10.3 is branched. (Relies on imp@'s test?)
*Will need to be in conjunction with changes after r294265 in head, as
currently Diff6 doesn't apply to stable/10.
Regards.
On Sat, 30 Jan 2016 19:12:34 +0000
Steven Hartland <kill...@multiplay.co.uk> wrote:
I believe, based on testing, that the from Diff 5 onwards of
https://reviews.freebsd.org/D5108 this should work as you expect it i.e.
If boot1 is loaded from a device which has either a UFS or ZFS bootable
install then this is the device that will be used to boot.
If said device has both then the ZFS setup will still be tried first.
If you can test in your setup and confirm either way that would be most
appreciated.
Regards
Steve
On 30/01/2016 06:57, Tomoaki AOKI 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"
_______________________________________________
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"
_______________________________________________
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"
