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 on stable/10 r295289, with l
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
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 using
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 firmwa
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 /boot/loa
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:
> Ok thanks, I hoped as much,
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, neede
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. Back to old problematic beh
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: pciroot(0x0):pci(0x1f,0x02):sata(0x1,
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 and
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 yo
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 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 limite
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 dd'ed with memstick.img o
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
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
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
wrote:
> I did so
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
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 [b
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 behaves this way. Boot1
look
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 loader in the pool which contain
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 UFS, too) is OK.
> >
> > Whe
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 used
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
> partiti
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 Disk
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
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
27 matches
Mail list logo
