Date: Fri, 15 Jan 2016 14:48:01 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: krad <kraduk@gmail.com>, Eric McCorkle <eric@metricspace.net> Cc: Renato Botelho <garga@freebsd.org>, freebsd-hackers@freebsd.org, Gabor Radnai <gabor.radnai@gmail.com> Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs Message-ID: <569906A1.8040700@multiplay.co.uk> In-Reply-To: <CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q@mail.gmail.com> References: <CABnVG=dbUQF_9-0FGj6hjNKPoRP-YekZfCEYfEb5DgcWK30BCA@mail.gmail.com> <9418E44F-114E-4ABA-A32D-416297BCDA9F@metricspace.net> <56985C6A.6040209@multiplay.co.uk> <EB1FB298-78BA-43C5-B5CF-C615D3D93570@FreeBSD.org> <569900CD.2040003@metricspace.net> <CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ZFS Boot Environments (BE) support was also wired up to Beastie last
night by Allan for those interested in that :)
On 15/01/2016 14:42, krad wrote:
> Thanks this is useful information. I did have a look at the way pc bsd
> was using grub to boot rootonzfs systems, and they used the Kfreebsd
> options. This looked kind of handy as you might have been able to
> specify the zfs file system to boot off. This would be a real boost
> the boot environments as you could easily choose which one to boot
> into, making upgrade recovery far easier.
>
> Presumably the freebsd@ part in your setup refers to the zfs file
> system? In which case you could have multiple menu entries with
> different file systems specified, this is assuming the grub config is
> on the efi disk though?
>
> I'm also curious how this would his work when the are multiple pools
> on the same disk for some reason.
>
>
>
> On 15 January 2016 at 14:23, Eric McCorkle <eric@metricspace.net
> <mailto:eric@metricspace.net>> wrote:
>
> On 01/15/16 06:51, Renato Botelho wrote:
>
> On Jan 15, 2016, at 00:41, Steven Hartland
> <killing@multiplay.co.uk <mailto:killing@multiplay.co.uk>>
> wrote:
>
> Just wanted to let everyone know that I just finished
> committing these changes to the tree.
>
> Huge thanks to Eric's for his work on this, as well as
> everyone else who contributed.
>
> I've set the target for MFC of 2 weeks, so I hope to be
> able to get this into stable/10 before the 10.3 slush, so
> if you're interested in this change please test a head
> build > r294068 ASAP.
>
>
> Great work, thanks!
>
> Is there a way to move a installed ZFS system to EFI?
>
>
> (Refer to Steven's guide for the simple case where you can create
> an EFI partition)
>
>
> == Using GRUB ==
>
> GRUB can be used with loader.efi on a ZFS system (I use this
> myself, as I have a Gentoo install in the same ZFS volume)
>
> Make sure you install GRUB with EFI support (the ports collection
> will handle this). The grub port comes with a script that
> auto-detects filesystems and sets up a grub.cfg in /boot/grub/.
> However, that script won't properly detect ZFS partitions, so
> you'll need to add it manually. The entry is simple.
>
> I have a zfs volume called "data", which has the freebsd system
> root on the filesystem data/freebsd. The GRUB entry then is:
>
> menuentry "FreeBSD" {
> search.fs_label data ZFS_PART
> chainloader ($ZFS_PART)/freebsd@/boot/loader.efi
> }
>
> The first line searches for the volume "data" and binds its device
> to the variable ZFS_PART. The second specifies that the chained
> bootloader is under the filesystem "freebsd" (the @ at the end of
> the name denotes a filesystem, not a path), with the path
> /boot/loader.efi
>
>
> == Disks without enough space to make the GPT or EFI partition ==
>
> If you have a ZFS filesystem on an MBR disk, or on a GPT disk
> without enough space to create a workable EFI partition, you can
> use one of ZFS's lesser-known features: zfs send/recv.
>
> ZFS send and recv allow an entire filesystem to be serialized out
> to a stream, and then read back in. You can use this to dump the
> entire filesystem out to a removable storage or an NFS mount.
> Then, use an install disk or memstick and repartition your drive,
> using zfs recv to recreate the filesystem.
>
>
> == On a Mac ==
>
> (Note: this is based on research that is several years old at this
> point. Also, I never actually field tested this myself.)
>
> Macs are wierd, due to their non-standard EFI. The Mac EFI
> implementation looks for an HFS+ partition, and loads the
> "blessed" file as the EFI bootloader (this is a special
> filesystem-level metadata unique to HFS+ filesystems).
>
> In order to do an EFI boot on a mac, you'd need some way of
> manufacturing an HFS+ partition containing only your bootloader,
> with that file being "blessed". The easiest way to do this would
> be to use a Mac OS install to create an empty HFS+ filesystem, add
> your boot loader, then use a shell command to "bless" it (this
> command exists, but I don't remember what it is offhand). It also
> wouldn't be too hard to write a tool to create an HFS+ image from
> a file (I have a half-written implementation of that lying around
> somewhere).
>
> Also note that Macs expect a 200MB EFI partition (which isn't
> actually used for anything), and I've heard reports of the
> firmware flaking out if it's not there.
>
> I believe there are also GRUB and rEFIt options for Mac, if you
> don't want to go to these lengths.
>
> _______________________________________________
> freebsd-hackers@freebsd.org <mailto:freebsd-hackers@freebsd.org>
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe@freebsd.org
> <mailto:freebsd-hackers-unsubscribe@freebsd.org>"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569906A1.8040700>