On Friday, May 05, 2017 11:01:03 PM Toomas Soome wrote:
> > On 5. mai 2017, at 22:07, Julian Elischer <jul...@freebsd.org> wrote:
> > 
> > Subject says it all really, is this an option at this time?
> > 
> > we'd like to try boot the main zfs root partition and then fall back to a 
> > small UFS based recovery partition.. is that possible?
> > 
> > I know we could use grub but I'd prefer keep it in the family.
> > 
> > 
> > 
> it is, sure. but there is an compromise to be made for it.
> Lets start with what I have done in illumos port, as the idea there is 
> exactly about having as “universal” binaries as possible (just the binaries 
> are listed below to get the size):
> -r-xr-xr-x   1 root     sys       171008 apr 30 19:55 bootia32.efi
> -r-xr-xr-x   1 root     sys       148992 apr 30 19:55 bootx64.efi
> -r--r--r--   1 root     sys         1255 okt 25  2015 cdboot
> -r--r--r--   1 root     sys       154112 apr 30 19:55 gptzfsboot
> -r-xr-xr-x   1 root     sys       482293 mai  2 21:10 loader32.efi
> -r-xr-xr-x   1 root     sys       499218 mai  2 21:10 loader64.efi
> -r--r--r--   1 root     sys          512 okt 15  2015 pmbr
> -r--r--r--   1 root     sys       377344 mai  2 21:10 pxeboot
> -r--r--r--   1 root     sys       376832 mai  2 21:10 zfsloader
> the loader (bios/efi) is built with full complement - zfs, ufs, dosfs, 
> cd9660, nfs, tftp + gzipfs. The cdboot is starting zfsloader (thats trivial 
> string change).
> The gptzfsboot in illumos case is only built with zfs, dosfs and ufs - as it 
> has to support only disk based media to read out the loader. Also I am 
> building gptzfsboot with libstand and libi386 to get as much shared code as 
> possible - which has both good and bad sides, as usual;)
> The gptzfsboot size means that with ufs the dedicated boot partition is 
> needed (freebsd-boot), with zfs the illumos port is always using the 3.5MB 
> boot area after first 2 labels (as there is no geli, the illumos does not 
> need dedicated boot partition with zfs).
> As the freebsd-boot is currently created 512k, the size is not an issue. Also 
> using common code does allow the generic partition code to be used, so 
> GPT/MBR/BSD (VTOC in illumos case) labels are not problem.

The intention btw of the larger size for gptboot is so we could have a merged
gptboot / gptzfsboot.  I don't think ZFS was in FreeBSD when gptboot was first
written, but I would much rather have a merged gptboot binary that supports
both.  It just needs some logic for what to pick if it sees both.  (It would
also be nice to axe zfsloader and just pass a different KARGS_FLAG_FOO in to
select ZFS as the default boot device to /boot/loader, but zfsloader is probably
too baked into the system at this point.)

> Also note that we can still build the smaller dedicated blocks like boot2, 
> just that we can not use those blocks for more universal cases and eventually 
> those special cases will diminish.

Yes, the BSD label stuff is stuck with a smaller size, but GPT should support
unified bootstraps.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to