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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"