Re: bootcode capable of booting both UFS and ZFS?

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 8 May 2017 13:43:31 -0600
On Mon, May 8, 2017 at 12:10 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> On Friday, May 05, 2017 11:01:03 PM Toomas Soome wrote:
>>
>> > On 5. mai 2017, at 22:07, Julian Elischer <julian_at_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.)

I think this is a good idea, but we need to make sure that we can
build a smaller bootblocks that support only UFS so we can re-install
on older installations where we have a super-small boot partition.

Having said that, I'd love for there to be just one set of boot
blocks, assuming they fit into our ~540k boot block limit. Sadly, we
can't just create a 1MB or 10MB partition due to limitations in our
current MBR boot code, though I suppose we could fix that by just
loading the first part and make that cope with the rest. Not trivial,
but not impossible.... Likely something we won't need to do for some
time though.

>> 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.

Agreed. We should also consider tossing a script into tools somewhere
to create a new slice that's bigger from the end of swap to allow
easier migrations...

Warner
Received on Mon May 08 2017 - 17:43:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC