Switch from legacy to UEFI boot??

Bob Willcox

unread,

Feb 3, 2016, 7:00:37 PM2/3/16

to

Is there a way to convert a system from legacy boot to UEFI boot? I have an
Intel NUC5i7RYH and I can get it to boot ok in legacy boot mode but only if I
go into the BIOS and manually select the partition. It (the BIOS) won't
automatically boot from it. Tells me there's no boot device.

Thanks,
Bob

--
Bob Willcox |
b...@immure.com | Entropy isn't what it used to be.
Austin, TX |
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

Trond Endrestøl

unread,

Feb 4, 2016, 2:50:05 AM2/4/16

to

On Wed, 3 Feb 2016 15:34-0600, Bob Willcox wrote:

> Is there a way to convert a system from legacy boot to UEFI boot? I have an
> Intel NUC5i7RYH and I can get it to boot ok in legacy boot mode but only if I
> go into the BIOS and manually select the partition. It (the BIOS) won't
> automatically boot from it. Tells me there's no boot device.

UEFI requires the GPT partitioning scheme and a special boot partition
on the harddrive, a EFI System Partition (ESP).

If you don't have GPT on your drive, your best option is to backup
anything precious, redo the partitioning, and reinstall your system.

If you already use the GPT partitioning scheme and can make some extra
room on your harddrive, then you'll be able to create a small ESP of
800K, and populate that partition with /boot/boot1.efifat.

E.g.:

gpart create -t efi -s 800K -l esp0 ada0
gpart bootcode -p /boot/boot1.efifat -i <index-of-efi> ada0

--
+-------------------------------+------------------------------------+
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+-------------------------------+------------------------------------+

Matthias Fechner

unread,

Feb 4, 2016, 8:37:21 AM2/4/16

to

Am 04.02.2016 um 08:49 schrieb Trond Endrestøl:
> If you already use the GPT partitioning scheme and can make some extra
> room on your harddrive, then you'll be able to create a small ESP of
> 800K, and populate that partition with /boot/boot1.efifat.
>
> E.g.:
>
> gpart create -t efi -s 800K -l esp0 ada0
> gpart bootcode -p /boot/boot1.efifat -i <index-of-efi> ada0

is it true that currently the EFI loaded cannot boot a ZFS root?

Thanks
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Trond Endrestøl

unread,

Feb 4, 2016, 9:04:07 AM2/4/16

to

On Thu, 4 Feb 2016 14:36+0100, Matthias Fechner wrote:

> Am 04.02.2016 um 08:49 schrieb Trond Endrestøl:
> > If you already use the GPT partitioning scheme and can make some extra
> > room on your harddrive, then you'll be able to create a small ESP of
> > 800K, and populate that partition with /boot/boot1.efifat.
> >
> > E.g.:
> >
> > gpart create -t efi -s 800K -l esp0 ada0
> > gpart bootcode -p /boot/boot1.efifat -i <index-of-efi> ada0
>
> is it true that currently the EFI loaded cannot boot a ZFS root?

As of r294999, stable/10's boot1.efi and loader.efi is able to boot
ZFS. Both boot1.efi and loader.efi takes the bootfs property into
consideration. Finally we can use the familiar loader menu, and not
something I last saw when I used FreeBSD 4. If you use BE's, then the
loader.efi boot menu lets you select which BE to boot from. It's a
dream come true. I was able to scrap the 4 GiB UFS partition I
previously used for storing /boot.

The laptop behind me is proof enough, although you can't see it and
thus not verify my claims. It multiboots Windows 10 and FreeBSD 10,
using rEFInd as the boot manager

rEFInd is told to load Windows' \EFI\BOOT\BOOTX64.EFI for Windows 10,
and \FreeBSD\boot1.efi for FreeBSD 10. The EFI firmware loads the
rEFInd boot loader by default, but I have also added EFI boot menu
entries for Windows 10 and FreeBSD 10, should rEFInd decide to act up.

http://www.rodsbooks.com/refind/

Maybe you should wait until the next stable/10 snapshot is available,
as the snapshot from 20150127 is one day or so behind r294999.

http://svnweb.freebsd.org/base?view=revision&revision=294999

You can use boot1.efi and loader.efi from the latest head snapshot if
you can't wait, I did for one of my newest stable/10 VMs back home.

Brandon J. Wandersee

unread,

Feb 4, 2016, 9:51:06 AM2/4/16

to

Trond Endrestøl writes:

> On Thu, 4 Feb 2016 14:36+0100, Matthias Fechner wrote:
>>
>> is it true that currently the EFI loaded cannot boot a ZFS root?
>
> As of r294999, stable/10's boot1.efi and loader.efi is able to boot
> ZFS. Both boot1.efi and loader.efi takes the bootfs property into

> consideration... Maybe you should wait until the next stable/10
> snapshot is available...

The ZFS-compatible EFI loader is expected to be ready for 10.3-RELEASE,
which is scheduled for about six weeks from now.[1] It may be a bit more
or less time than that, depending on how things go, but the first beta
snapshot of 10.3 (which is cut from 10-STABLE) is set to be built
tomorrow. If you don't want to run a development branch, you won't have
much longer to wait. Though once that change happens, you'd have to back
up your data and reconfigure your boot scheme to make use of
ZFS-compatible UEFI booting.

[1]: https://www.freebsd.org/releases/10.3R/schedule.html

--
=================================================================
:: Brandon Wandersee ::
:: brandon....@gmail.com ::
==================================================================

krad

unread,

Feb 4, 2016, 10:34:14 AM2/4/16

to

The conversion I did was pretty easy, but then I was starting from a GPT
layout in the 1st place. I basically unmounted swap, stole 100M from the 4G
partition, remounted swap, and then dd'd the /boot/boot1.efifat file to the
new small partition. rebooted and all came up. I was doing this from the
latest stable though. Just make sure you have performed a "svnup stable"
in the last few days and done a source upgrade and you should be good.

It is possible to convert a MBR layout to GPT, but it does require downtime
and backup as if you get it wrong you could easily loose your partitions

On 3 February 2016 at 21:34, Bob Willcox <b...@immure.com> wrote:

> Is there a way to convert a system from legacy boot to UEFI boot? I have
> an
> Intel NUC5i7RYH and I can get it to boot ok in legacy boot mode but only
> if I
> go into the BIOS and manually select the partition. It (the BIOS) won't
> automatically boot from it. Tells me there's no boot device.
>

> Thanks,
> Bob
>
> --
> Bob Willcox |
> b...@immure.com | Entropy isn't what it used to be.
> Austin, TX |

Arthur Chance

unread,

Feb 4, 2016, 12:04:33 PM2/4/16

to

On 04/02/2016 14:50, Brandon J. Wandersee wrote:
>
> Trond Endrestøl writes:
>
>> On Thu, 4 Feb 2016 14:36+0100, Matthias Fechner wrote:
>>>
>>> is it true that currently the EFI loaded cannot boot a ZFS root?
>>
>> As of r294999, stable/10's boot1.efi and loader.efi is able to boot
>> ZFS. Both boot1.efi and loader.efi takes the bootfs property into
>> consideration... Maybe you should wait until the next stable/10
>> snapshot is available...
>
> The ZFS-compatible EFI loader is expected to be ready for 10.3-RELEASE,
> which is scheduled for about six weeks from now.[1] It may be a bit more
> or less time than that, depending on how things go, but the first beta
> snapshot of 10.3 (which is cut from 10-STABLE) is set to be built
> tomorrow. If you don't want to run a development branch, you won't have
> much longer to wait. Though once that change happens, you'd have to back
> up your data and reconfigure your boot scheme to make use of
> ZFS-compatible UEFI booting.
>
> [1]: https://www.freebsd.org/releases/10.3R/schedule.html
>

I currently have a pure ZFS system with boot environments which I
currently boot using BIOS compatibility mode. Will I just be able to
switch to UEFI boot under 10.3? Is the EFI loader smart enough to find
boot environments for itself, or do we have to flag them in some fashion?

--
Moore's Law of Mad Science: Every eighteen months, the minimum IQ
necessary to destroy the world drops by one point.

krad

unread,

Feb 4, 2016, 4:15:05 PM2/4/16

to

*you will need a small efi partition on the b*oot drive. You should still
have the option to bios boot as well.

here is a layout from one of my systems. You can see I trimmed the space
from swap

$ gpart show ada0
=> 34 117231341 ada0 GPT (56G)
34 1024 1 freebsd-boot (512K)
1058 6 - free - (3.0K)
1064 262144 2 efi (128M)
263208 3932154 4 freebsd-swap (1.9G)
4195362 113036013 3 freebsd-zfs (54G)

Matthias Fechner

unread,

Feb 10, 2016, 3:22:18 PM2/10/16

to

Am 04.02.2016 um 15:03 schrieb Trond Endrestøl:
> As of r294999, stable/10's boot1.efi and loader.efi is able to boot
> ZFS. Both boot1.efi and loader.efi takes the bootfs property into

> consideration. Finally we can use the familiar loader menu, and not
> something I last saw when I used FreeBSD 4. If you use BE's, then the
> loader.efi boot menu lets you select which BE to boot from. It's a
> dream come true. I was able to scrap the 4 GiB UFS partition I
> previously used for storing /boot.

i just tested the loader.efi from base.txz from:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/10.3-PRERELEASE/

it does not boot. It seems that the new version is there not included.

I tried with the loader.efi from base.txz from:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/11.0-CURRENT/

it boots fine.
If I use beadm for my ZFS I expect that I have to manually edit the
loader.rc from the efi partition to load the correct environment or?

Thanks for this tip!

Gruß

Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Trond Endrestøl

unread,

Feb 11, 2016, 3:59:02 AM2/11/16

to

On Wed, 10 Feb 2016 21:21+0100, Matthias Fechner wrote:

> i just tested the loader.efi from base.txz from:
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/10.3-PRERELEASE/
> it does not boot. It seems that the new version is there not
> included.

Try the latest 10.3-BETA1 image. That one should be recent enough.

ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-BETA1/
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.3/

> If I use beadm for my ZFS I expect that I have to manually edit the
> loader.rc from the efi partition to load the correct environment or?

I don't use any loader.rc on the ESP. Just boot1.efi renamed to
/EFI/BOOT/BOOTX64.EFI. boot1.efi reads the bootfs property from the
bootpool/rootpool, and navigates to the correct /boot directory to
find everything else.

Matthias Fechner

unread,

Feb 11, 2016, 3:04:21 PM2/11/16

to

Am 11.02.2016 um 09:58 schrieb Trond Endrestøl:
> I don't use any loader.rc on the ESP. Just boot1.efi renamed to
> /EFI/BOOT/BOOTX64.EFI. boot1.efi reads the bootfs property from the
> bootpool/rootpool, and navigates to the correct /boot directory to
> find everything else.

I tried it is using the loader.efi and the boot1.efi (stored in as
efi/boot/BOOTx64.efi).
If I remove the loader.rc it will stop booting.
I get:
can't load 'kernel'

if I type:
set currdev=zfs:zroot/ROOT/default:
load boot/kernel/kernel
load boot/kernel/zfs.ko
boot

it works.
The bootfs property is set on the pool:
root@test1:~ # zpool get bootfs
NAME PROPERTY VALUE SOURCE
zroot bootfs zroot/ROOT/default local

Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

krad

unread,

Feb 11, 2016, 4:27:43 PM2/11/16

to

This is my working layout if it helps

# find /boot/efi/
/boot/efi/
/boot/efi/efi
/boot/efi/efi/boot
/boot/efi/efi/boot/bootx64.efi
# gpart show

=> 34 117231341 ada0 GPT (56G)
34 1024 1 freebsd-boot (512K)
1058 6 - free - (3.0K)
1064 262144 2 efi (128M)
263208 3932154 4 freebsd-swap (1.9G)
4195362 113036013 3 freebsd-zfs (54G)

# mount -p | grep efi
/dev/ada0p2 /boot/efi msdosfs rw 0 0

Brandon J. Wandersee

unread,

Feb 11, 2016, 5:06:45 PM2/11/16

to

Trond Endrestøl writes:

> On Wed, 10 Feb 2016 21:21+0100, Matthias Fechner wrote:
>
>> i just tested the loader.efi from base.txz from:
>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/10.3-PRERELEASE/
>> it does not boot. It seems that the new version is there not
>> included.
>
> Try the latest 10.3-BETA1 image. That one should be recent enough.
>
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-BETA1/
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.3/
>
>> If I use beadm for my ZFS I expect that I have to manually edit the
>> loader.rc from the efi partition to load the correct environment or?
>

> I don't use any loader.rc on the ESP. Just boot1.efi renamed to
> /EFI/BOOT/BOOTX64.EFI. boot1.efi reads the bootfs property from the
> bootpool/rootpool, and navigates to the correct /boot directory to
> find everything else.

Assuming your install is on disk ada0, and your ESP is the first
parition, you can just run:

$ dd if=/path/to/boot1.efifat of=/dev/ada0p1

You'll find boot1.efifat in /boot, relative to wherever you extracted
base.txz. As always, make sure your `dd` target is actually the one you
want before running.

--
=================================================================
:: Brandon Wandersee ::
:: brandon....@gmail.com ::
==================================================================

Trond Endrestøl

unread,

Feb 12, 2016, 2:29:25 AM2/12/16

to

On Thu, 11 Feb 2016 21:03+0100, Matthias Fechner wrote:

> Am 11.02.2016 um 09:58 schrieb Trond Endrestøl:

> > I don't use any loader.rc on the ESP. Just boot1.efi renamed to
> > /EFI/BOOT/BOOTX64.EFI. boot1.efi reads the bootfs property from the
> > bootpool/rootpool, and navigates to the correct /boot directory to
> > find everything else.
>

> I tried it is using the loader.efi and the boot1.efi (stored in as
> efi/boot/BOOTx64.efi).
> If I remove the loader.rc it will stop booting.
> I get:
> can't load 'kernel'
>
> if I type:
> set currdev=zfs:zroot/ROOT/default:
> load boot/kernel/kernel
> load boot/kernel/zfs.ko
> boot
>
> it works.
> The bootfs property is set on the pool:
> root@test1:~ # zpool get bootfs
> NAME PROPERTY VALUE SOURCE
> zroot bootfs zroot/ROOT/default local

Strange. Yesterday, I installed 10.3-BETA1 using bsdinstaller and ZFS
on a UEFI VM in VirtualBox 5.0.14. It's a simple single disk layout.

The ESP contains nothing more than the boot1.efi disquised as
/EFI/BOOT/BOOTX64.EFI, i.e. the contents of the /boot/boot1.efifat
image. The bootfs property points to zroot/ROOT/default, and
everything else resides in the zpool.

Somehow your setup is different.

Matthias Fechner

unread,

Feb 13, 2016, 3:53:19 AM2/13/16

to

Am 12.02.2016 um 08:28 schrieb Trond Endrestøl:
> The ESP contains nothing more than the boot1.efi disquised as
> /EFI/BOOT/BOOTX64.EFI, i.e. the contents of the /boot/boot1.efifat
> image. The bootfs property points to zroot/ROOT/default, and
> everything else resides in the zpool.
>
> Somehow your setup is different.

I will give you as many details as you need to find out why it does not
work.
The FreeBSD is running in an Oracle Virtualbox on windows 10 (version
5.0.14r105127). I use this version to simulate updates for my real boxes.

There is a FreeBSD 10.2-RELEASE-p9 installed that is updated using
freebsd-update.

The zpool consists of two 20GB harddisk switch together as a mirror:
pool: zroot
state: ONLINE
scan: resilvered 8.82G in 0h12m with 0 errors on Wed Feb 10 08:54:53 2016
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
gpt/disk0 ONLINE 0 0 0
gpt/disk1 ONLINE 0 0 0

I resized the zpool to have space for the efi partition (was a little
bit of snapshoting and copying around).
The new layout of both disks is now:
$ gpart show
=> 34 41942973 ada0 GPT (20G)
34 6 - free - (3.0K)
40 262144 1 efi (128M)
262184 128 2 freebsd-boot (64K)
262312 41680688 3 freebsd-zfs (20G)
41943000 7 - free - (3.5K)

=> 34 41942973 ada1 GPT (20G)
34 6 - free - (3.0K)
40 262144 1 efi (128M)
262184 128 2 freebsd-boot (64K)
262312 41680688 3 freebsd-zfs (20G)
41943000 7 - free - (3.5K)

As you can see, I have legacy and efi partions available so I can boot
uefi and legacy.

As freebsd10.2 is not able to boot efi I copied the boot1.efi/loader.efi
and GNUSparseFile/boot1.efifat (using dd) to the efi partition.
The efi partition was filled with:
newfs_msdos ada0p1
mount -t msdosfs /dev/ada0p1 /mnt
mkdir -p /mnt/efi/boot/
cp boot1.efi /mnt/efi/boot/BOOTx64.efi
mkdir -p /mnt/boot
cat > /mnt/boot/loader.rc << EOF
unload

set currdev=zfs:zroot/ROOT/default:
load boot/kernel/kernel
load boot/kernel/zfs.ko

autoboot
EOF
(cd /mnt && find .)
.
./efi
./efi/boot
./efi/boot/BOOTx64.efi
./boot
./boot/loader.rc
umount /mnt

The same steps are performed on the second disk (but this should make
for these test not a difference I think).

I tested boot1.efi/loader.efi and the efifat with dd from 10.3-beta1 and
11, but was only able to boot with the loader.rc in place. The moment I
removed the loader.rc the systems stops on boot prompt and I have to
type the lines from the loader.rc manually to boot the system.

The bootfs flag is defined:
$ zpool get bootfs

NAME PROPERTY VALUE SOURCE
zroot bootfs zroot/ROOT/default local

$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 12.9G 6.19G 19K none
zroot/ROOT 433M 6.19G 19K none
zroot/ROOT/default 433M 6.19G 433M none
zroot/swap 4.13G 10.3G 8K -
zroot/tmp 74.5K 6.19G 74.5K /tmp
zroot/usr 5.68G 6.19G 3.42G /usr
zroot/usr/home 11.2M 6.19G 11.2M /usr/home
zroot/usr/local 895M 6.19G 895M /usr/local
zroot/usr/ports 525M 6.19G 280M /usr/ports
zroot/usr/ports/distfiles 242M 6.19G 242M /usr/ports/distfiles
zroot/usr/ports/packages 2.76M 6.19G 2.76M /usr/ports/packages
zroot/usr/src 880M 6.19G 880M /usr/src
zroot/var 2.72G 6.19G 1.18G /var
zroot/var/crash 19K 6.19G 19K /var/crash
zroot/var/db 1.54G 6.19G 1.50G /var/db
zroot/var/db/pkg 38.8M 6.19G 38.8M /var/db/pkg
zroot/var/empty 19K 6.19G 19K /var/empty
zroot/var/log 243K 6.19G 243K /var/log
zroot/var/mail 23K 6.19G 23K /var/mail
zroot/var/run 30K 6.19G 30K /var/run
zroot/var/tmp 171K 6.19G 171K /var/tmp

> $ zfs get mountpoint
> NAME PROPERTY VALUE SOURCE
> zroot mountpoint none received
> zroot/ROOT mountpoint none inherited from zroot
> zroot/ROOT/default mountpoint none inherited from zroot
> zroot/swap mountpoint - -
> zroot/tmp mountpoint /tmp received
> zroot/usr mountpoint /usr received
> zroot/usr/home mountpoint /usr/home inherited from zroot/usr
> zroot/usr/local mountpoint /usr/local inherited from zroot/usr
> zroot/usr/ports mountpoint /usr/ports inherited from zroot/usr
> zroot/usr/ports/distfiles mountpoint /usr/ports/distfiles inherited from zroot/usr
> zroot/usr/ports/packages mountpoint /usr/ports/packages inherited from zroot/usr
> zroot/usr/src mountpoint /usr/src inherited from zroot/usr
> zroot/var mountpoint /var received
> zroot/var/crash mountpoint /var/crash inherited from zroot/var
> zroot/var/db mountpoint /var/db inherited from zroot/var
> zroot/var/db/pkg mountpoint /var/db/pkg inherited from zroot/var
> zroot/var/empty mountpoint /var/empty inherited from zroot/var
> zroot/var/log mountpoint /var/log inherited from zroot/var
> zroot/var/mail mountpoint /var/mail inherited from zroot/var
> zroot/var/run mountpoint /var/run inherited from zroot/var
> zroot/var/tmp mountpoint /var/tmp inherited from zroot/var

The boot environments are managed using beadm:
$ beadm list
BE Active Mountpoint Space Created
default NR / 433.0M 2016-02-10 08:10

I hope the post is not to long ;)

Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

krad

unread,

Feb 13, 2016, 5:22:26 PM2/13/16

to

is the OS you are trying to boot a 10.3 snapshot or stable, or is it 10.2?

If 10.2 this maybe the problem as there are other bits in the bootstrap
process that need to be updated I think. Try building stable, and put it
into a new bootenv, activate it and reboot. Then from beastie select your
10.2 be and see if that works.

Trond Endrestøl

unread,

Feb 15, 2016, 4:06:07 AM2/15/16

to

I tried to recreate your setup using
FreeBSD-10.3-BETA1-amd64-uefi-dvd1.iso.

It booted just fine without any loader.rc stored in the ESP.

To recap:

gpart create -s gpt ada0
gpart create -s gpt ada1

gpart add -a 4K -t efi -s 128M ada0
gpart add -a 4K -t efi -s 128M ada1

gpart add -a 4K -t freebsd-boot -s 64K ada0
gpart add -a 4K -t freebsd-boot -s 64K ada1

gpart add -a 4K -t freebsd-zfs ada0
gpart add -a 4K -t freebsd-zfs ada1

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1

newfs_msdos ada0p1
newfs_msdos ada1p1

mount -t msdosfs /dev/ada0p1 /mnt

mkdir -p /mnt/EFI/BOOT
cp -p /boot/boot1.efi /mnt/EFI/BOOT/BOOTX64.EFI
umount /mnt

mount -t msdosfs /dev/ada1p1 /mnt
mkdir -p /mnt/EFI/BOOT
cp -p /boot/boot1.efi /mnt/EFI/BOOT/BOOTX64.EFI
umount /mnt

kldload zfs

sysctl vfs.zfs.min_auto_ashift=12

hostname matthias.example.org

zpool create -o autoreplace=on -o cachefile=/tmp/zpool.cache -o failmode=continue -O mountpoint=legacy zroot mirror ada0p3 ada1p3

I used my own recipe for crafting the ZFS pool, you'll find the recipe
as the files matching 0* at
http://ximalas.info/~trond/create-zfs/canmount/

The two .vdi files (2x 1,065,353,216 bytes) can be downloaded for
comparison from http://ximalas.info/~trond/matthias/

Matthias Fechner

unread,

Feb 15, 2016, 4:22:56 AM2/15/16

to

Am 13.02.2016 um 23:22 schrieb krad:
> is the OS you are trying to boot a 10.3 snapshot or stable, or is it 10.2?

I'm booting a FreeBSD 10.2 kernel with a new boot1.efi bootloader.
Maybe there is really something in the kernel that is required.

> If 10.2 this maybe the problem as there are other bits in the bootstrap
> process that need to be updated I think. Try building stable, and put it
> into a new bootenv, activate it and reboot. Then from beastie select your
> 10.2 be and see if that works.

I tested it now with a completely fresh installed 10.3-beta2 image and
there it works.
So I will wait till 10.3 is available via freebsd-update to test it with
my setup.

The only difference I saw was that my efi partion has 128MB and the
standard efi partition the installer created 800KB.
Could this be a problem of disk-size (FAT12, FAT16, FAT32...)?

Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook