Date: Fri, 05 May 2017 23:01:03 +0300 From: Toomas Soome <tsoome@me.com> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org>, Toomas Soome <tsoome@freebsd.org> Subject: Re: bootcode capable of booting both UFS and ZFS? Message-ID: <053354DF-651F-423C-8057-494496DA3B91@me.com> In-Reply-To: <963c5c97-2f92-9983-cf90-ec9d59d87bba@freebsd.org> References: <963c5c97-2f92-9983-cf90-ec9d59d87bba@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 5. mai 2017, at 22:07, Julian Elischer <julian@freebsd.org> wrote: >=20 > Subject says it all really, is this an option at this time? >=20 > 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? >=20 > I know we could use grub but I'd prefer keep it in the family. >=20 >=20 >=20 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 =E2=80=9Cuniversal=E2=80=9D 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. So, even just with cd boot (iso), starting zfsloader (which in fbsd has = built in ufs, zfs etc), you already can get rescue capability.=20 Now, even with just adding ufs reader to gptzfsboot, we can use gpt + = freebsd-boot and ufs root but loading zfsloader on usb image, so it can = be used for both live/install and rescue, because zfsloader itself has = support for all file systems + partition types. I have kept myself a bit off from freebsd gptzfsboot because of simple = reason - the older setups have smaller size for freebsd boot, and not = everyone is necessarily happy about size changes:D also in freebsd case = there is another factor called geli - it most certainly does contribute = some bits, but also needs to be properly addressed on IO call stack (as = we have seen with zfsbootcfg bits). But then again, here also the shared = code can help to reduce the complexity. Yea, the zfsloader/loader*.efi in that listing above is actually built = with framebuffer code and compiled in 8x16 default font (lz4 compressed = ascii+boxdrawing basically - because zfs has lz4, the decompressor is = always there), and ficl 4.1, so thats a bit of difference from fbsd = loader. 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. rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?053354DF-651F-423C-8057-494496DA3B91>