UEFI Booting on a Thinkpad Yoga 11e w/ Security Chip

[Kyle Evans]

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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI Booting on a Thinkpad Yoga 11e w/ Security Chip

[Kyle Evans]

Hi,

Sorry, I should have mentioned that-- I did actually have Secure Boot
disabled prior to all of my runs (verified, still disabled), and tried CSM
on and off both just to see if that affected it. None of this changed the
error output, with exception to the Security Chip setting. Within the
Security Chip subset of settings, there wasn't anything more fine-grained
that I could disable to try and narrow it down.
On Mar 18, 2016 6:56 PM, "Tomoaki AOKI"  wrote:

> Hi.
>
> Is there any setting about"Secure Boot"?
>   *Maybe all Windoze7 (or later) generation ThinkPads would have it.
>
> If so, disable it INSTEAD OF "Security Chip" and try.
>
>
> On Fri, 18 Mar 2016 15:54:46 -0500
> Kyle Evans  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.
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
>
> --
> Tomoaki AOKIjunch...@dec.sakura.ne.jp
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #2617 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2617 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2617/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2617/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2617/console

Change summaries:

296974 by adrian:
[net80211] Add some more missing IEs.

There are a /lot/ more missing; I'll chase these down over time.

Obtained from:  802.11-2012 standard

296973 by cem:
fail(9): Only gather/print stacks if STACK is enabled

This is a follow-up fix to the earlier r296927.

Reported by:bz
Sponsored by:   EMC / Isilon Storage Division

296970 by sjg:
We need libutil

and make it feasible to at least build the tests in situ

296968 by obrien:
Bring down 0.4.5 vendor files and other catchups with the distribution tarball.

Reviewed by:phil

296967 by phil:
Move generated file from contrib to build directory.

Reviewed by:obrien
Approved by:sjg

296966 by obrien:
Block the r296965 vendor/Juniper/libxo cleanup (to match the release tarball)
from being merged in -- backing out FreeBSD localizations.



The end of the build log:

[...truncated 118765 lines...]
--- img-63x255-512-mbr.raw ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-mbr.raw.gz.uu | gunzip 
-c > img-63x255-512-mbr.raw
--- img-63x255-512-mbr.vhd ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-mbr.vhd.gz.uu | gunzip 
-c > img-63x255-512-mbr.vhd
--- img-63x255-512-mbr.vhdf ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-mbr.vhdf.gz.uu | gunzip 
-c > img-63x255-512-mbr.vhdf
--- img-63x255-512-mbr.vmdk ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-mbr.vmdk.gz.uu | gunzip 
-c > img-63x255-512-mbr.vmdk
--- img-63x255-512-pc98.qcow ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.qcow.gz.uu | 
gunzip -c > img-63x255-512-pc98.qcow
--- all_subdir_lib ---
--- .depend.test_01 ---
echo test_01.full: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libxo.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> 
.depend.test_01
--- all_subdir_usr.bin ---
--- img-63x255-512-pc98.qcow2 ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.qcow2.gz.uu | 
gunzip -c > img-63x255-512-pc98.qcow2
--- all_subdir_lib ---
--- test_01.o ---
cc  -O2 -pipe   -I/usr/src/contrib/libxo/libxo -g -MD -MP 
-MF.depend.test_01.test_01.o -MTtest_01.o -std=gnu99 -fstack-protector-strong   
 -Qunused-arguments -c /usr/src/contrib/libxo/tests/core/test_01.c -o test_01.o
--- all_subdir_usr.bin ---
--- img-63x255-512-pc98.raw ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.raw.gz.uu | gunzip 
-c > img-63x255-512-pc98.raw
--- img-63x255-512-pc98.vhd ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.vhd.gz.uu | gunzip 
-c > img-63x255-512-pc98.vhd
--- img-63x255-512-pc98.vhdf ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.vhdf.gz.uu | 
gunzip -c > img-63x255-512-pc98.vhdf
--- img-63x255-512-pc98.vmdk ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-pc98.vmdk.gz.uu | 
gunzip -c > img-63x255-512-pc98.vmdk
--- img-63x255-512-vtoc8.qcow ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.qcow.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.qcow
--- img-63x255-512-vtoc8.qcow2 ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.qcow2.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.qcow2
--- img-63x255-512-vtoc8.raw ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.raw.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.raw
--- all_subdir_usr.sbin ---
--- aslmaputils.o ---
cc  -O2 -pipe -DACPI_ASL_COMPILER -I.   
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MP -MF.depend.aslmaputils.o 
-MTaslmaputils.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter  -Qunused-arguments -c 
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslmaputils.c
 -o aslmaputils.o
--- all_subdir_usr.bin ---
--- img-63x255-512-vtoc8.vhd ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.vhd.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.vhd
--- img-63x255-512-vtoc8.vhdf ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.vhdf.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.vhdf
--- img-63x255-512-vtoc8.vmdk ---
uudecode -p /usr/src/usr.bin/mkimg/tests/img-63x255-512-vtoc8.vmdk.gz.uu | 
gunzip -c > img-63x255-512-vtoc8.vmdk
--- mkimg ---
echo '#! /usr/libexec/atf-sh' > mkimg.tmp
cat /usr/src/usr.bin/mkimg/tests/mkimg.sh >>mkimg.tmp
chmod +x mkimg.tmp
mv mkimg.tmp mkimg
--- Kyuafile ---
--- all_subdir_usr.bin/mklocale ---
===> usr.bin/mklocale (all)
--- yacc.c ---
yacc -d 

trivial freebsd 9 (and later) route patch reminder / question

[John Wehle]

Noticed in 2013 a problem with FreeBSD 9 due to a MFC which
broke my VPN.  There's a bug report with a trivial patch at:

  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179829

The problem is still present in FreeBSD 10 and the code in
HEAD also looks unchanged (meaning the problem likely still
exists).

It would nice to fix the problem before FreeBSD 11 is branched.

Does the current bug report suffice, or is it buried since it
was originally discovered on FreeBSD 9?

Basically I wasn't sure if I needed to open a new report against
HEAD.

-- John
-
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: j...@feith.com  |
|John Wehle| Fax: 1-215-540-5495  | |
-

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loaders got fatter in the last few days

[Guido Falsi]

On 03/18/16 22:41, Freddie Cash wrote:
> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer  wrote:
> 
>> On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude 
>> wrote:
>>> On 2016-03-18 12:33, Guido Falsi wrote:

 Hi,

 I have just update one of my machines and noticed the booloaders files
 got quite fat in the last few days, some by a big margin.

 on an updated machine(r296993):

 -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot

 from a machine I still have not updated(r296719):

 -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>>
>> So the loader grew 70 kB.  How big are your disks?
>>
 I noticed because mu gpt boot partition is 64K and gptzfsboot just
 passed 100K.
>>>
>>> This is a side effect of the loader gaining the ability to boot from GELI
>>> encrypted partitions.
>>>
>>> ...
>>>
>>> Maybe we should be putting the GELI enabled boot blocks in a different
>>> filename? I generally wanted to avoid creating a new version of each
>>> bootcode with GELI support.
>>
>>
>> I think we should just suggest that boot partitions be much larger
>> than 64kB (1MB is still <0.1% of any disk sold today) and not worry
>> about it too much.  Embedded applications can disable GELI loader
>> support to save a few bytes.
>>
> 
> ​The boot partition doesn't necessarily need ​
> 
> ​to be 1 MB (and can't due to some issues with the assembler used right
> now, or something like that).  We just need to make sure people have slack
> space in their partition table to expand into in the future.

My strategy, which helped me in this case, is having swap space just
after the boot partition, in this way I can just resize the swap space
and boot partition and reorganize the system.

The OS will not comply about a few hundred Kilobytes swap less :)

-- 
Guido Falsi 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 12:33, Guido Falsi wrote:

Hi,

I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.

on an updated machine(r296993):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
-r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
-r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
-r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot

from a machine I still have not updated(r296719):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
-r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
-r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
-r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot

I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.

Is this expected and I'm supposed to repartition or is this an unwanted
mistake?

Thanks in advance.



This is a side effect of the loader gaining the ability to boot from 
GELI encrypted partitions.


You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back 
to a smaller one if you need.


Maybe we should be putting the GELI enabled boot blocks in a different 
filename? I generally wanted to avoid creating a new version of each 
bootcode with GELI support.


My goal somewhere down the road is to create a single bootcode that can 
do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or something.



--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI Booting on a Thinkpad Yoga 11e w/ Security Chip

[Tomoaki AOKI]

Hi.

Is there any setting about"Secure Boot"?
  *Maybe all Windoze7 (or later) generation ThinkPads would have it.

If so, disable it INSTEAD OF "Security Chip" and try.


On Fri, 18 Mar 2016 15:54:46 -0500
Kyle Evans  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.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 13:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision=296963



I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.



Those old bits of the wiki should be burned with fire. The one you link 
to is from 2009 and is full of bad advice, and only covers how to 
install FreeBSD 8.x


--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"