Re: ZFSROOT UEFI boot

Confirmed MFC'ed to stable/10 as r295550. Thanks to Steven for your great work! Thanks to RE for approving before releng/10.3 branch! Regards. On Sat, 6 Feb 2016 15:34:40 +0900 Tomoaki AOKI wrote: > Confirmed. Thanks for your great work, Steven! > > I tried Diff9

Re: ZFSROOT UEFI boot

Confirmed. Thanks for your great work, Steven! I tried Diff9 on stable/10 r295289, with locally MFC'ing r294765, r294768 and r294769. Not shure r294769 is really needed or not, but without r294765 and r294768, Diff9 wasn't applicable. *sys/boot/mips/beri/boot2/boot2.c portion of r294765 must be

Re: ZFSROOT UEFI boot

I got a feedback from Yuichiro NAITO at freebsd-users-jp ML. Boots fine using memstick created using release/release.sh on patched head. (Diff9) Properly shows up installer screen. The system is Macbook Air 2012 having root-on-UFS 10.2-RELEASE without ZFS. I think feedbacks using different

Re: ZFSROOT UEFI boot

Yep thanks, I committed this to head today, after Warner confirmed it was good in his env too. It will sit there for 1 week before I request permission to MFC to stable/10. On 05/02/2016 17:24, Tomoaki AOKI wrote: > I got a feedback from Yuichiro NAITO at freebsd-users-jp ML. > > Boots fine

Re: ZFSROOT UEFI boot

Performed remaining tests below using "without -DEFI_DEBUG" binary and confirmed all boots as expected. Also tested already-reported tests with the binary and confirmed that boot just as EFI_DEBUG binary did. *Boot from ada0, ZFS doesn't have /boot/loader.efi, while UFS has. -> Loads

Re: ZFSROOT UEFI boot

Thanks! The behavior is fixed and now boots as expected. :-) Please see attached. What's not tested yet is: *Fallback to UFS from ZFS in the same disk works or not. *Without -DEFI_DEBUG binary. Regards. On Mon, 1 Feb 2016 18:06:14 + Steven Hartland wrote: >

Re: ZFSROOT UEFI boot

Hmm, this doesn't look right:- 1) Boot from ada0 WITHOUT USB memstick and ada1 attached (single drive). boot1 imagepath: pciroot(0x0):pci(0x1f,0x02):sata(0x1,0x0,0x0):hd(1) probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0) probe: . not supported probing:

Re: ZFSROOT UEFI boot

Thanks in advance. But unfortunately, the boot behavior of Diff7 and Diff8 are changed from Diff6. Back to old problematic behavior. FYI, I re-tested Diff6 (previously built binary) and reproduced the behavior I already reported. (So no new logs for it.) Please see attached 2 files (for Diff7

Re: ZFSROOT UEFI boot

Ok thanks, I hoped as much, otherwise we where looking a very broken EFI firmware ;-) I've found and fixed the match issue, so if you could re-test 2 and 3 we should be able confirm all is good. If all is good a confirmation that there's no issues with the rest, but no need for output,

Re: ZFSROOT UEFI boot

Woops! Found mistype in Diff8 report. Sorry. :-( Attached is the fixed one. [imagepath line of 1) is fixed.] On Mon, 1 Feb 2016 23:36:27 +0900 Tomoaki AOKI wrote: > Thanks in advance. > But unfortunately, the boot behavior of Diff7 and Diff8 are changed > from Diff6.

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

Sorry. I just noticed this mail is not a duplicate of which I just responded to. :-( I built boot1.efi that is applied Diff6 with -DEFI_DEBUG, but not with -DDEBUG. Was it sufficient? Or does some info be missed with above option I set? On Sat, 30 Jan 2016 12:43:31 + Steven Hartland

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

On Sat, 30 Jan 2016 12:53:46 + Steven Hartland 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

Re: ZFSROOT UEFI boot

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

Re: ZFSROOT UEFI boot

On 28 January 2016 at 15:03, Tomoaki AOKI 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

Re: ZFSROOT UEFI boot

On 28/01/2016 16:22, Doug Rabson wrote: On 28 January 2016 at 15:03, Tomoaki AOKI 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

Re: ZFSROOT UEFI boot

On Sun, 24 Jan 2016 18:39:08 + Steven Hartland wrote: > On 24/01/2016 12:53, Tomoaki AOKI wrote: > > Unfortunately, this (and its committed successor and original for UFS) > > fails to boot in some situation, like below. OTOH, gptzfsboot (and > > maybe gptboot for

Re: ZFSROOT UEFI boot

Unfortunately, this (and its committed successor and original for UFS) fails to boot in some situation, like below. OTOH, gptzfsboot (and maybe gptboot for UFS, too) is OK. When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI partition is used and it searches /boot/loader.efi from

Re: ZFSROOT UEFI boot

On 2016-01-24 07:53, Tomoaki AOKI wrote: > Unfortunately, this (and its committed successor and original for UFS) > fails to boot in some situation, like below. OTOH, gptzfsboot (and > maybe gptboot for UFS, too) is OK. > > When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI >

Re: ZFSROOT UEFI boot

On 24/01/2016 12:53, Tomoaki AOKI wrote: Unfortunately, this (and its committed successor and original for UFS) fails to boot in some situation, like below. OTOH, gptzfsboot (and maybe gptboot for UFS, too) is OK. When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI partition is

ZFSROOT UEFI boot

Hi, I need to get one of my machines converted over from bios GPT zfsroot boot to efi. I know you can boot freebsd under EFI with a ufs kernel but this isnt the route i want. There are patches under test for EFI zfs root. However when I read the thread it was unclear which version of these patches

Re: ZFSROOT UEFI boot

Ive literally just got this working on 10.2 after working on the code posted on the review which you can find here: https://reviews.freebsd.org/D4104 If you're happy running current then the patch file I linked in my comment should apply cleanly and just work. If you want 10.x then there's quite