[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: EFI ZFS loader successful load and boot
From:       Eric McCorkle <eric () metricspace ! net>
Date:       2015-07-10 4:12:45
Message-ID: 559F463D.8020402 () metricspace ! net
[Download RAW message or body]


On 07/09/2015 11:48 PM, Andrey Fesenko wrote:
> On Sun, Jun 28, 2015 at 5:19 PM, Eric McCorkle <eric@metricspace.net> wrote:
>> On 06/28/2015 01:39 AM, Andrey Fesenko wrote:
>>
>>> Unable to load the kernel, i'm make simple gpart structure
>>>
>>> GPT
>>> efi part  <- write /boot/loader.efi as efi/boot/bootx64.efi
>>> ZFS root pool
>>
>> Just saw this part.  You want to write /boot/boot1.efi to
>> efi/boot/bootx64.efi, not loader.
>>
> 
> I tried to try a new boot loader again, unfortunately, once again
> failed to load, but it turned out a few facts:
> loader start with clear environment (loader device efi, not zfs env),
> https://bsdnir.info/files/efi/ screenshot lszfs - efi-zfs-notenv.jpg,
> zfs_get.txt and zpool_get.txt contain zfs/zpool get all list's
> 
> If possible, put the master image of the for recording to the flash
> that we could rely on him.
> 

Definitely something weird going on.  The most obvious next step as far
as I can tell would be to actually look at the partition type GUID's.

Here's a theory as to what might be going on:

1) Trying to load a filesystem that isn't actually that FS type somehow
messes up the state of the fs loader code in ways that break future attempts

2) Doing legacy first causes the BIOS to order the partitions
differently than it would if you do UEFI only

3) Because the current boot1 blindly tries to probe everything, it gums
up the FS code, but switch the order around and it works (because it
didn't probe a wrong partition first).

I'll try and get the partition type GUID check done this weekend.


As for loader, it reminds me of issues I had to fix to get loader
working in the first place (which suggests I missed an edge case).

Basically, loader has a device info struct (I forget the exact name) for
describing devices.  But ZFS devices need additional info, so I did a
quick fix of re-allocating the struct with the additional space if it's
a ZFS device.

A better solution would be to add padding space to the device info
struct, similar to what's done with struct sockaddr.  Then specific
subclasses could store their data in the padding (like struct
sockaddr_un and struct sockaddr_in), but you could still refer to it by
the more general type.

It seemed like a bit too progressive of a change, but in light of this,
it might be the way to go.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]