svn commit: r304321 - in head/sys: boot/efi/boot1 boot/efi/loader boot/i386/boot2 boot/i386/gptboot boot/i386/gptzfsboot boot/i386/zfsboot boot/userboot/ficl boot/userboot/userboot boot/userboot/zf...

[Andriy Gapon]

On 18/08/2016 03:37, Toomas Soome wrote:
> Author: tsoome
> Date: Thu Aug 18 00:37:07 2016
> New Revision: 304321
> URL: https://svnweb.freebsd.org/changeset/base/304321
> 
> Log:
>   Add SHA512, skein, large blocks support for loader zfs.
>   
>   Updated sha512 from illumos.
>   Using skein from freebsd crypto tree.
>   Since loader itself is using 64MB memory for heap, updated zfsboot to
>   use same, and this also allows to support zfs large blocks.
>   
>   Note, adding additional features does increate zfsboot code, therefore
>   this update does increase zfsboot code to 128k, also I have ported gptldr.S
>   update to zfsldr.S to support 64k+ code.


This commit breaks boot process for me and in a quite weird way.
I don't have a serial console, so a couple of screenshots.
This is what happens with this change:
https://people.freebsd.org/~avg/boot-fail-1024x768.jpg
This is what I have with the previous loader:
https://people.freebsd.org/~avg/boot-success-1024x768.jpg

As you can see somehow the HDD gets misdetected as a floppy, BIOS disk ID is 0x0
as opposed to 0x80.  Also, the disk size is incorrect too.  Additionally the
firewire is not detected.

I suspect that the problem may have to do with the increased loader size.
I must add that I have these in src.conf:
LOADER_BZIP2_SUPPORT=yes
LOADER_FIREWIRE_SUPPORT=yes

My memory of loader's memory placement and layout has faded, so I can't
elaborate further on my guess.

Also, there is this report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212038
That problem could have a different cause.  It should be easier to analyze as
the it happens with bhyveload, i.e., in userland.

-- 
Andriy Gapon