Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jul 2016 18:15:38 -0500
From:      Kyle Evans <kevans91@ksu.edu>
To:        <freebsd-current@freebsd.org>
Subject:   Re: UEFI Booting on a Thinkpad Yoga 11e w/ Security Chip
Message-ID:  <CACNAnaEt0eLeC-wsjQbUw1zri_DFn1aF=VM0aVOGXr%2Bnr5r6SA@mail.gmail.com>
In-Reply-To: <CACNAnaHSKnfDyAJUEJZ=uAv1Q67yAC3Zqiu0w4i7xV=sV4bToQ@mail.gmail.com>
References:  <CACNAnaHSKnfDyAJUEJZ=uAv1Q67yAC3Zqiu0w4i7xV=sV4bToQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 18, 2016 at 3:54 PM, Kyle Evans <kevans91@ksu.edu> wrote:
> Hello!
>
> I recently purchased an older Thinkpad Yoga 11e and now I've installed
> 10.3RC2 to it. It appears that the Security Chip feature causes
> problems in attempting to boot 10.3RC2 (and a slightly older -CURRENT,
> as well, but re-tested with 10.3RC2 just for the sake of
> verification). The following output is written when attempting to boot
> from the `amd64-uefi-memstick.img`:
>
> ==
>
>>> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
>  LoadImage failed with error 2
>  HandleProtocol failed with error 2
>  StartImage failed with error 2
>  panic: Load failed
>
> ==
>
> Rebooting and disabling the security chip fixes this, and everything
> runs along nicely. Re-enabling the Security Chip after 10.3RC2 is
> installed and attempting a boot yields the slightly different (while
> slightly expected, given the above, but I'm adding this anyways):
>
> ==
>
>>> FreeBSD EFI boot block
>     Loader Path: /boot/loader.efi
>
>     Initializing modules: ZFS UFS
>     Probing 4 block devices. . . . . .* done
>         ZFS found the following pools: zroot
>         UFS found no partitions
> Failed to load image provided by ZFS, size: 2033504512, (2)
> panic: No bootable partitions found!
>
> ==
>
> Is this expected behavior? I was under the impression that the
> "Security Chip" was largely unrelated to anything in the boot process.

Hi,

This might be unlikely, but what are the odds that devpath_last
(sys/boot/efi/boot1/boot1.c:135) isn't quite returning the correct
device path to be passed to bs->LoadImage()
(sys/boot/efi/boot1/boot1.c:405) in the case that a TPM chip is
present? This would seem to line up with the EFI_INVALID_PARAMETER
error that LoadImage is returning -- especially given that the ZFS
bits here are correctly enumerating my device's pool.

Thanks,

Kyle Evans



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEt0eLeC-wsjQbUw1zri_DFn1aF=VM0aVOGXr%2Bnr5r6SA>