EFI/ZFS Update: successful tests, need more complex vdevs

[Outback Dingo]

On Thu, Dec 10, 2015 at 7:26 PM, Steven Hartland <killing at multiplay.co.uk>
wrote:

> We've used Eric's hard work which is currently under review here:
> https://reviews.freebsd.org/D4104
>
> I'm pleased to report we can now successfully EFI boot root ZFS from a
> raidz2 pool on Intel P3700 NVMe drives :)
>
> Here's a guide for those interested:
> http://blog.multiplay.co.uk/2015/12/freebsd-10-2-release-efi-zfs-root-boot/
>


What exactly did you diff this from, i pull a clean release/10.2.0 and
applied the patches from the site which resulted
in 68 rejects.

 find . -name "*.rej" -print | wc -l
     68


find . -name "*.rej" -print
./sys/boot/usb/Makefile.rej
./sys/boot/forth/loader.rc.rej
./sys/boot/forth/menu.rc.rej
./sys/boot/ficl/ia64/sysdep.c.rej
./sys/boot/ficl/ia64/sysdep.h.rej
./sys/boot/ia64/common/exec.c.rej
./sys/boot/ia64/common/libia64.h.rej
./sys/boot/ia64/common/autoload.c.rej
./sys/boot/ia64/common/copy.c.rej
./sys/boot/ia64/common/bootinfo.c.rej
./sys/boot/ia64/common/devicename.c.rej
./sys/boot/ia64/common/icache.c.rej
./sys/boot/ia64/ski/delay.c.rej
./sys/boot/ia64/ski/libski.h.rej
./sys/boot/ia64/ski/efi_stub.c.rej
./sys/boot/ia64/ski/acpi_stub.c.rej
./sys/boot/ia64/ski/sal_stub.c.rej
./sys/boot/ia64/ski/exit.c.rej
./sys/boot/ia64/ski/pal_stub.S.rej
./sys/boot/ia64/ski/ssc.c.rej
./sys/boot/ia64/ski/skiconsole.c.rej
./sys/boot/ia64/ski/main.c.rej
./sys/boot/ia64/ski/start.S.rej
./sys/boot/ia64/ski/time.c.rej
./sys/boot/ia64/ski/skimd.c.rej
./sys/boot/ia64/ski/skifs.c.rej
./sys/boot/ia64/ski/conf.c.rej
./sys/boot/ia64/efi/efimd.c.rej
./sys/boot/ia64/efi/main.c.rej
./sys/boot/ia64/efi/start.S.rej
./sys/boot/ia64/efi/conf.c.rej
./sys/boot/i386/boot0/boot0ext.S.rej
./sys/boot/i386/efi/elf32_freebsd.c.rej
./sys/boot/i386/efi/reloc.c.rej
./sys/boot/i386/efi/start.S.rej
./sys/boot/i386/efi/efimd.c.rej
./sys/boot/i386/efi/i386_copy.c.rej
./sys/boot/i386/efi/bootinfo.c.rej
./sys/boot/i386/efi/exec.c.rej
./sys/boot/fdt/dts/arm/p2041rdb.dts.rej
./sys/boot/fdt/dts/arm/p5020ds.dts.rej
./sys/boot/fdt/dts/arm/pandaboard.dts.rej
./sys/boot/fdt/dts/arm/beaglebone-black.dts.rej
./sys/boot/fdt/dts/arm/exynos5250-chromebook.dts.rej
./sys/boot/fdt/dts/arm/p3041ds.dts.rej
./sys/boot/fdt/dts/arm/am335x.dtsi.rej
./sys/boot/fdt/dts/arm/am335x-evm.dts.rej
./sys/boot/fdt/dts/arm/beaglebone.dts.rej
./sys/boot/amd64/Makefile.inc.rej
./sys/boot/amd64/efi/framebuffer.c.rej
./sys/boot/amd64/efi/autoload.c.rej
./sys/boot/amd64/efi/devicename.c.rej
./sys/boot/amd64/efi/conf.c.rej
./sys/boot/amd64/efi/amd64_tramp.S.rej
./sys/boot/amd64/efi/start.S.rej
./sys/boot/amd64/efi/reloc.c.rej
./sys/boot/amd64/efi/framebuffer.h.rej
./sys/boot/amd64/efi/x86_efi.h.rej
./sys/boot/amd64/efi/elf64_freebsd.c.rej
./sys/boot/amd64/efi/main.c.rej
./sys/boot/amd64/efi/copy.c.rej
./sys/boot/amd64/efi/bootinfo.c.rej
./sys/boot/amd64/boot1.efi/Makefile.fat.rej
./sys/boot/amd64/boot1.efi/boot1.c.rej
./sys/boot/amd64/boot1.efi/generate-fat.sh.rej
./sys/boot/amd64/boot1.efi/fat.tmpl.bz2.uu.rej
./sys/boot/common/loader.8.rej
./sys/boot/common/md.c.rej




>
> On 04/11/2015 12:35, krad wrote:
>
>> is there not anyway freebsd could provide patched signed binaries outside
>> the main distros for testing purposes, as it should be fairly straight
>> forward to drop them in? I think you might be a much bigger audience for
>> testing then?
>>
>> On 2 November 2015 at 19:16, Gabor Radnai <gabor.radnai at gmail.com> wrote:
>>
>> Appreciate, thank you very much. I think my confusion is because the
>>> latest
>>> patch you provided on the list
>>> on *Fri Oct 23 11:19:07 UTC 2015*
>>>
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20151023/db1ac571/attachment.bin
>>>
>>> is not a full patch but a diff to your original patch. Anyhow, I'm ok now
>>> applying original patch and this latest diff everything seems fine
>>> (apart that for some reason my server dislikes booting automatically from
>>> the EFI partition, manually loading bootx64.efi works like charm.
>>> but that's definitely nothing to do with your great work).
>>>
>>> Thanks.
>>> _______________________________________________
>>> freebsd-hackers at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "
>>> freebsd-hackers-unsubscribe at freebsd.org"
>>>
>>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org
>> "
>>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>